О вычислениях

lexa - 23/Дек/2011 22:49
Понастраивал тут кластер, добился для 12 нодов эффективности около 70%, на чем (заказчик) и успокоился.

Но все эти дни не отпускала такая вот простая мысль:

  • Вот значит кластер, в нем 7U Blade-серверов (набивка неполная, мест на шасси 10) плюс еще 1U "управляющего фронтенда", OpenMPI, подбор топологии и размеров задачи, чтобы коммуникации и вычислительная моща были сбалнсированы (а уже для 12 нод, без опыта - пришлось повозиться, хотя конечно можно было бы просто оставить подбираться на месяц и помешивать).

    Ну и стоит - не знаю сколько, но так подозреваю, что заметно за $100k.

  • Но те же 1.7 терафлопса получаются на половинке юнита (а добив памяти и увеличив задачу - на той машине уже за 2 Tflop/s получили). Ну ладно, на целом юните, если не увлекаться и просто пихнуть две HD6990 в подходящий корпус. И, по ощущениям, гемороя с отладкой какбэ не меньше. Стоить будет - ну скажем $10k за сервер и еще $2k за две видеокарты.

    Ну хорошо, пусть даже mainstream-решение: 4-GPU-Tesla (1U) и два 1U-сервера. И даже IB (на две ноды - можно без свитча - будет несколько сотен за 40Gbit порт). Но сбалансировать две ноды сильно проще чем 12, я проверял.

    Такой мейнстрим стоить будет тоже не $100k+, а 30-40. Электричества жрать не 6 киловатт, а два. А на 4xTesla те же 1.7 GF

Ну то есть понятно, GPGPU еще не везде мейнстрим, особенно на AMD. Но посмотрев на все это вживую - никакой идеи считать что-то научное на "обычных компьютерах" - у меня больше не возникает.

P.S. С удовольствием приму участие в настройке какого-то кластера с теслами. Чисто за интерес.

Comments

Bushman (not verified) - 23/Дек/2011 22:56

Традиции и очевидность решений есть враг прогресса :)

mrshurik (not verified) - 23/Дек/2011 23:03

если код это 90% BLAS и FFT, то согласен, перенести на GPU не так сложно и значительный выигрыш по производительности.
а если код использует хитрые списки, всякие сложные деревья и т.п., то уже не так просто его перенести, точнее можно, но ускорения не будет, а может и наоборот.
плюс, есть ряд HPC задач, которым нужно много-много памяти (как на ноде вообще, так и на всех нодах суммарно), такие тоже сложно перенести.

lexa - 23/Дек/2011 23:13

Да, память - аргумент. Потому что на этих 12 нодах+центральный - ее больше терабайта (две ноды - толстые, по 256G). И столько в 1-2 сервера не набить за приемлемые деньги.

А списки/деревья - не обязательно аргумент. То есть я бы сказал так: если код SIMD-изуется, то от GPU будет счастье более-менее. Если не SIMD-изуется (вроде гистограммы) - то тоже может быть счастье хоть и меньшее.

Зато если в коде есть синус (косинус, логарифм, экспонента), то счастье от GPU возникает просто невероятное!

mrshurik (not verified) - 23/Дек/2011 23:48

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

lexa - 24/Дек/2011 07:28

Я понимаю, что бывает и такое и от этого - никуда не деться.

С другой стороны, в моей практике случались (и не раз) случаи, когда такая развесистая структура, после обдумывания реальной задачи, вдруг чудесным образом становилась плоской, линейной и все такое. И два порядка ускорения в этом случае - обычное дело.

Беда, как мне кажется, в том, что структурам данных (списки, массивы, деревья, строки, hash-map) еще как-то учат (или сами учатся), а вот их эффективной реализации и замене одного другим (сортированный массив - это же дерево) - уже совсем не учат. Соответственно, и мозги в эту сторону не повернуты.

mrshurik (not verified) - 24/Дек/2011 16:25

согласен с вами, часто сложные структуры можно упростить до массива, особенно если структура read-only. для динамических структур это не всегда возможно.
вообще, я бы сильно упростил и сказал так, если код это большая числодробилка, то он хорош для GPU, а если код это "логика" (проверки, переходы), то он хорош для CPU.

lexa - 24/Дек/2011 16:54

Если это "логика" (в том смысле, что один поток, параллельного исполнения не получается, а в этом потоке - сплошные ветвления), то код не "хорош" для CPU, а тоже отвратителен. Просто на GPU - еще хуже.

mrshurik (not verified) - 24/Дек/2011 23:03

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

lexa - 24/Дек/2011 23:14

По мне, так лучше бы транзисторы на AVX-регистры потратили бы :)

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

lexa - 23/Дек/2011 23:17

Я даже больше скажу - если алгоритм не SIMD-изуется, то надо попробовать поискать других алгоритмов. Потому что жопа иначе, вместо 4(8) op/clock сплошное огорчение.

thenexus6 (not verified) - 23/Дек/2011 23:17

Большую часть научного и прикладного считают на стандартных сторонних приложениях (мы тут как раз занимаемся раздачей учёным вычислительных ресурсов, и некоторая статистика есть), а они на GPU считай что и не переводились в своей массе. Да и не все задачи можно утоптать в GPGPU так, чтобы соотношение flops/ватт было лучше.

В общем, оно всё ещё сильно зависит от конкретной задачи.

P.S. У нас на CPU кластере на 28 узлах 87% эффективность. На кластере с теслами со старым linpack - 45%, новым - 55% (прогресс в оптимизации виден :) )

lexa - 24/Дек/2011 07:19

Да, про задачи я понимаю, разветвись - и на CPU будет хоть как-то считать, а на GPU - ваще труба. Но реально - и на CPU тогда не работа, а слезы.

Что же до эффективности, да там есть куда стремиться. На поминавшемся в посте Multi-AMD первые цифры были заметно меньше 500 GFlops. Причем, за 2GPU (из 4-х на машине) оно не масштабировалось сначала. Упражнениями (включающими сложное программирование) дотянули до 2007, больше чем в 4 раза. Rpeak там ~2600, т.е. больше 75% получили.

dmarck (not verified) - 24/Дек/2011 00:28

http://www.supermicro.com/servers/blade/module/SBI-7126TG.cfm

20 GPU на те же 7U, и как ни смешно, не суперденег стоит.

net_easy (not verified) - 24/Дек/2011 00:41

Алексей, а на кой собственно, этот кластер заказчику. Что он с ним делать то собрался?

neuda4nik (not verified) - 24/Дек/2011 05:28

сдаётся мне предновогодний попил бюджета
дали денег - надо освоить

lexa - 24/Дек/2011 07:04

Да не похоже на то - там конфигурация придумана не от фонаря (иначе все ноды были бы одинаковы).

net_easy (not verified) - 24/Дек/2011 11:32

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

lexa - 24/Дек/2011 07:03

Это биологи-медики какие-то.

Т.е. типичные для них задачи - это или расчет пространственной конфигурации молекулы (спросонья забыл как оно правильно называется, молекулярное моделирование что-ли), которое на GPU летает просто мухой (за счет аппаратной реализации экспоненты), или матчинг длинных (генных) паттернов.

net_easy (not verified) - 24/Дек/2011 11:41

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

lexa - 24/Дек/2011 11:51

Ну я вот не удержался и купили Infiniband-а домой :)

net_easy (not verified) - 24/Дек/2011 14:04

А где же фотки и рассказ? Интересно жеж.
Почём сделать себе кластер?

lexa - 24/Дек/2011 14:23

Так только купил.

С учетом новогодних праздников - недели через 2-3 доедет. Тогда все будет, и фотки и рассказ

Lev Serebryakov (not verified) - 24/Дек/2011 16:25

История которая, кажется, релевантна: когда работал в Sun Microsystems к нам заездом читала обзорную лекцию про HPC какая-то французская звезда этого дела, работавшая на тамошний R&D-центр Сана.
И он рассказывал, что вот тут они поставили кластер и вот там поставили кластер (под лейблом Sun'а).
А я знал, что в одной английской биг-фарма-фирме только что поставили адский зал с лейблом Sun'а, который по количеству стоек, узлов, кросс-конектов и прочего превосходит все его примеры раз в 5. И я спросил: ``А что же вы молчите вот про такую инсталляцию -- она же круто-круто!''.
Ответ был: ``Это не HPC.''
-- Но почему?
-- Потому что там целочисленные вычисления, комбинаторика. Вообще нет плавучки. И, кстати, в CERN стоит тоже наш кластер среди прочих, но тоже не HPC. Не считается и не рассматривается как HPC.

Я к тому, что в мире дофига вот такого формально-не-HPC. Как с ним на GPU?

lexa - 24/Дек/2011 16:47

С целыми там странно, но они есть. Там проблема в том, что на некоторых архитектурах 24-битные целые эффективны, а 32-битные - нет, а других архитектурах - наоборот.

Ну и SIMD (можно как угодно называть, но по смыслу - так), дорогие ветвления, дорогой произвольный доступ к памяти.

На мой взгляд, если получается эффективно (т.е. SIMD) спрограммировать на CPU, то на GPU сделать эффективно будет еще проще т.к. нет жесткого требования на загрузку-запись в последовательные адреса (это не обязательно будет эффективно, но добиться можно).

Плюс, на GPU сильно больше реально быстрой (единицы тактов) памяти и она доступна явно (а не "кэш"), что тоже полезно