Мощный комп для расчетов

Бери топовый Xeon тогда, чего уж мелочиться.

//http://www.cpubenchmark.net/high_end_cpus.html

Бюджет в студию, может на серьёзное решение денег хватит.
Вдруг протратишь кучу денег, а выяснится, что памяти ECC не помешало бы.

над хардварным адаптером для рейдов, как уже неоднократно говорили, стоит много раз подумать, прежде чем брать его.
огласите бюджет и специфику задачи: вдруг там рамы немного нужно или хдд не важен.

Не забудьте предусмотреть расходы на уборщицу бабу Машу, ведра с жидким гелием менять :)

Не бери асус. Нагребёшься с ним. Анонимус это гарантирует.

П.С. И да, Xeon предпочтительней.

Cтранно, что для расчетов, но без использования opencl

Имеется в виду псевдо-декстоп решение...

Это называется workstation (рабочая станция).

На Украине уже более 15 лет есть интересная фирма, продающая высокопроизводительные компы. Гарантия - 3 года, ориентация в основном на платформы фирмы Супермикро http://www.supermicro.ru/ (специализация - матплаты для серверов и рабочих станций).

Если мне понадобится числодробилка, буду ориентироваться на её железо. http://onix.kiev.ua/, собственно рабочие станции вот тут: http://onix.kiev.ua/servers/workstation

В РФ нечто похожее делает Т-Платформы http://www.t-platforms.ru/products.html

Но у неё дороже. Наверное, лучше или купить у украинцев готовые компы, или сделать самосборку из того железа, которое они пихают в свои станции. В чём цимус? У них железо сертифицированное на совместную работу. Не будет нестыковок и неожиданных «бутылочных горлышек» в производительности.

PS И да, рабочие станции на десктопных процах обычно не делают. Intel Xeon более традиционное решение.

Бюджет примерно 75 т.р.

Xeon обязателен для двухпроцессорных мамок, а по тестам того же cpubenchmark 3930K незначительно уступает 3960X, и стоит сильно дешевле. Поэтому подумал, что однопроцессорное топовое может быть и лучше.

RAM 64 гектара, распределяться будет гибко между нуждающимися пользователями, которые в основном будут работать в виртуальных машинах.

Данных много, поэтому скорость дисковой подсистемы важна.

Дело не только в тестах на производительность, но и в приспособленности к непрерывной бессбойной работе. А это уж точно не десктопные процы. Какой смысл в недельном расчёте, если на четвёртые сутки будет трабл в вычислениях? Не зря в вёркстейшены ставят Xeon и профессиональные графические платы. :)

Впрочем, бюджет в 2,5 килобаксов - маловат для хорошей машинки :)

Какой может быть трабл в вычислениях? если декстопный проц будет давать сбои, система рано или поздно будет наворачиваться. Однако, как правило, этого не наблюдается.

мощный комп для расчетов для научного проекта

Графическое ядро в любом случае не важно.

Пора вылезать из криокамеры. Сейчас в може гетерогенные вычисления и хорошо параллелящийся алгоритм на сравнительно недорогой видяхе может выполнится в разы быстрее, чем на топовом CPU.

Уговорил. Какой комп посоветуешь? Вопрос, в целом, об этом был.

А что считать собираетесь? Программисты толковые у вас есть?

Сначала определяемся с задачами, потом с алгоритмами, потом прикидываем, что должно считаться на CPU, а что - на GPU. Исходя из расчётов выбираем железо.

а Вам не кажется что в этот бюджет уже может лечь 16-ядерный оптерон?

по поводу расчетов на видяхе быстрее это Вы сами придумали или Вам добрые дяди сказали?

в реальности чтобы на видеокарте считало быстрее необходимо софт переписывать с 0.

в реальности попытки параллелить на видеокарту что-либосерьезное приводят к тому что весь прирост производительности видеокарты съедается на конвертировании формата матриц и обмене.

виртуальные машины и расчеты совместимы слабо.

надо настраивать систему очередей.

64 Gb RAM вполне может оказаться мало.

а не проще ли и не дешевле заказать родную SUPERMICRO без посредников через любой приличный компьютерный магазин поблизости?

XEON в 75к не влезет, автору стоит выплавить мозг бюджетодателю т.к. мне кажется что тот не понимает специфику.

В реальности конечно это будет сборная солянка, в которой будет не много эффективных вычислений. Часть кода написана в рамках опенсорсных проектов. Поэтому нужен мощный процессор общего назначения. GPUнекуда пришить.

Можно попросить объяснить каждый пункт? Почему слабо совместимы вирт машины и расчеты. Что такое система очередей (возможно имеется в виду очередь запросов к данным, так это не мой случай. Вычисления не эффективны. Программы написаны в том числе на интерпретируемых ЯП )

система очередей - проект TORQUE , MAUI итп. позволяет запускать наборы задач несколькими юзерами без особых проблем.

слабо совместимы с виртуальными машинами потому что виртуалка будет жрать производительность, память итп.

если вычисления не эффективны и используется одно ядро на задачу то что мешает в 70к взять 2-3 машины на AMD-FX по 8 ядер и соединить в сеть?

1) Наборы задач можно запускать при помощи ssh. 2) В моих наблюдениях, KVM не жрет больше 20 процентов CPU и эффективно работает с дисками. 3) Ничто не мешает.

ECC для расчетов не нужен, так как немного медленее, а данные в памяти не так уж ценны (это тебе не бизнес)

CUDA
</thread>

Наборы задач можно запускать при помощи ssh

ну ты сравнил х с пальцем

CUDA

Туда!

1) а Вы уверены что у Вас при запуске по SSH пользователи к примеру не займут к примеру 8 задач при 4 ядрах на компе?:)

2) а 20% это мало?

сбой в данных памяти - развалившаяся задача с 90% вероятностью

и + не ECC модулями много памяти не наберешь.

по поводу расчетов на видяхе быстрее это Вы сами придумали или Вам добрые дяди сказали?

Это жестокая реальность, сильно зависящая от алгоритмов

в реальности чтобы на видеокарте считало быстрее необходимо софт переписывать с 0

Если научные расчёты действительно важны - то переписывание будет вполне оправданным,

в реальности попытки параллелить на видеокарту что-либосерьезное приводят к тому что весь прирост производительности видеокарты съедается на конвертировании формата матриц и обмене.

ты сам лично писал под OpenCL/CUDA?

данные в памяти не так уж ценны

Правильно, если чо — потужится ещё недельку-другую, пересчитает.

писал солвер на OpenCL для OpenFOAM, прирост по сравнению с одним ядром бял гдето 15%, если параллелить на все ядра и сравнивать с 1 ядро + гпу то разница была в 15 раз в пользу 8 ядер.

т.е. переписывать надо МНОГО, одного солвера явно не достаточно, схемы дискретизации я не трогал, возможно что если б их поправил было бы лучше.

з.ы. да, кстати если солвер был бы только для стационарных задач то прирост был бы в разы.

Она может развалиться еще из-за кучи причин, не связанных с обородуованием

это зависит от сложности задачи.

у меня расчеты по аэродинамике чаще всего сыпятся из-за железа( сетевухи, память)

Смотря что считать. Ясен пень, если вычисления выполняются быстрее, чем копирование из оперативки в память видеокарты и обратно, смысла использовать GPU нет. Но есть задачи, в которых расчеты очень тяжелые + легко параллелятся. Вот их-то на GPU можно вынести. Правда, проблема еще в том, что у видеокарт обычно очень мало памяти.

ну вобщем можно пока смело утверждать что расчеты по прочности видеокартой ускоряются.

с аэродинамикой очень сложно реализовать.

Кое-что из обработки изображений тоже быстрей на видюшке считать. Реальный прирост идет на ресурсоемких распараллеливаемых задачах, скажем, если простая фильтрация изображения (4000х4000, 16 бит) занимает на 4 ядрах CPU (openmp) 120 секунд, а без openmp — 300 секунд, то на 128 ядрах GPU она явно секунд за 10..20 посчитается. Главное — чтобы оперативки хватило у видеокарты.

обработка изображений - это из-за того что в опенцл есть функции для работы с OpenGL

???

из-за наличия функций для прямой работы с изображениями нет необходимости перпекидывать данные - вся работа проводится в оперативке видеокарты.

Только элементарнейшая (средствами OpenGL). И вообще, кто сказал, что изображение надо будет показывать?

1) Я почитал доку по TORQUE, которую вы советуете. Показалось, что проще самому мониторить процессы, заниматься посевом и сбором уро^W данных. Пользователи конечно могут все, но скрипт, запускающий расчет, будет настроен на оптимальное кол-во процессов.

2) 20% это мало. Есть готовые проги на перле, которые если их переписать на православном языке, будет рвать перл. Это значит, что если когда-либо возникнет нужда делать тоже самое в 10 раз быстрее, то перенос фреймфорка на реальное железо - не первое, что надо будет сделать.

О графических картах и расчетах на них. 1) Просто, некому в ближайшее время будет на них расчеты организовывать. 2) Больше всего времени будет занимать прочитывание данных с дисков и запись результатов обратно.

если простая фильтрация изображения (4000х4000, 16 бит)
Главное — чтобы оперативки хватило у видеокарты.

Если даже при 32 мегов такой прирост ожидается, то не страшно, если придётся задачу кусками по... 2-3 гига грузить, к тому же интел в отличие от АМД уже имеет на материнках PCIe 3.

Это преимущество не для класса обычных вычислительных задач, а для задач визуализации.

2) Больше всего времени будет занимать прочитывание данных с дисков и запись результатов обратно.

А в других научных проектах данные берутся не с диска и сохраняются не на нём? Ведь тогда и проц-то быстрый не нужен. Просто взять и прикинуть: диск даёт данные со скоростью 200 МБ/с, а записывает и того медленнее - авось тут и двумя обычными ядрами можно обойтись?

писал солвер на OpenCL для OpenFOAM
т.е. переписывать надо МНОГО

Что-то не пойму: так если параллелил только солвер как на ГПУ, так и на ЦПУ, а всё остальное инвариантно, и такая разница, причём тут остальная часть фреймворка? По такому краткому описанию могу только предположить, что размерности задачи не хватало, чтобы компенсировать оверхед перекачки данных (предположив, что алгоритм был качественно реализован).

Похоже, просто человек не сталкивался ни разу с задачами, имеющими высокую вычислительную сложность.

остальная часть при том что при дискретизации уравнений матрицы в OpenFOAM записываются в специфическом формате.

поэтому для решения их на GPU их надо конвертировать.

размерности задачи пробовал до гдето 1млн узлов.

чем больше задача тем больше была просадка т.к. матрица была больше.

на CPU оно уже распараллелено.

причем не только солвер.

но чтоб параллелить так на видеокарте надо несколько видеокарт.

и + не ECC модулями много памяти не наберешь.

fb-dimm, а не ECC.

Бред. Десктопные процы прекрасно молотят в 24/7 годами. На десктопных же мамках.

Единственное, что очень важно для workstation/любой другой критичной машины - память с ECC, и поддержка оной платой/процом. Хотя да, некоторые «мегопроизводители мегосерверов» типа СМТ ложат болт на ЕСС, а «надежность» обеспечивается регулярными ребутами (со слов производителя) - но такой подход правильным я бы не назвал.

И да, в 2.5 килобакса можно купить штук 5-6 серверов на зионах позапрошлого поколения (2 головы по 4 ядра, с 16 гигами памяти на борту) и собрать из них некислый SSI кластер... Ну либо новую платформу на паре интерлагосов собрать.