Новая технология межпроцессорной связи, разработанная IBM

Вот кое какие цифры по скоростям и латентностям для разных современных
интерконнектов:

Technology    Vendor   Latency      Bandwidth per link(unidirectional)
NUMAlink      SGI      1.5 – 3 µsec 1500 MB/s
QsNet II      Quadrics 1.6 µsec     900 MB/s
ServerNet     HP       3 µsec       125 MB/s
Sun Fire Link Sun      3 – 5 µsec   792 MB/s
Myrinet XP2   Myricom  5.5 µsec     495 MB/s
Myrinet XP    Myricom  7 – 9 µsec   230 MB/s
SCI           Sun      10 µsec      1 Gb/s
GNS           SGI      13 – 30 µsec 800 MB/s
SP Switch 2   IBM      18 µsec      500 MB/s
HyperFabric2  HP       22 µsec      320 MB/s

Самый популярный (IB) забыл ;)

Technology    Vendor   Latency      Bandwidth per link(unidirectional)
InfiniBand Multiple 3-20 msec 785 MB/s

Это для 12x

>Вот кое какие цифры по скоростям и латентностям для разных современных интерконнектов:

ну то есть новый интерконнект их теоретически бьет, и если поставить эти модуляторы на 256битную шину получим 10GB/s x 256 = 2,5TB/s

что утопия, конечно, но приятно :)

>ну то есть новый интерконнект их теоретически бьет

Дык пока сделают рабочую железяку старые в продакшене ускорятся еще раз в 10.

> Дык пока сделают рабочую железяку старые в продакшене ускорятся еще раз в 10.

навряд ли в современых интерконнектах тоже fiber optic так что ускоряться вместе будут

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

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

> Ибо зачем мучаться с интерконнектом вообще, если будут сняты факторы, сдерживающие производительность одного нода?

Главная проблема -- как обеспечить коннект КАЖДОГО ядра к КАЖДОЙ ячейке памяти (если мы про СМП), да еще так, чтобы они все друг другу не мешали. И никакие сколь угодно быстрые и маленькие соединения тут сильно не помогут.

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

И еще проблема -- масштабируемость операционки.

> И еще проблема -- масштабируемость операционки.

Операционки чего?

> Операционки чего?

Чего -- "чего"?

В современном суперкомпьютере (особенно производства IBM) много операционок. Масштабирование которой из них тебя больше всего не устраивает?

> В современном суперкомпьютере (особенно производства IBM) много операционок.

Любой!

Я говорил про трудности, возникающие при попытке построить один, но ОЧЕНЬ большой СМП нод. Подразумевается, очевидно, что этот нод работает под единым образом операционки.

Мне известно максимум 1024 ядер (то был SGI Altix 4700 под Сюзей), и то, оно -- отнюдь не СМП, кирпичики там проводочками соединяются.

> Я говорил про трудности, возникающие при попытке построить один, но ОЧЕНЬ большой СМП нод.

Альтернативный подход как раз и продвигает IBM - производство очень большого количества относительно простых узлов (nodes). Каждый из узлов работает под управлением своей OS. Пример - архитектура Blue Gene.

> Альтернативный подход как раз и продвигает IBM...

Да, все именно так; не только бимеры, почти все так делают.

Я просто пояснял, почему НЕЛЬЗЯ сделать "один ОЧЕНЬ большой узел".

>Альтернативный подход как раз и продвигает IBM - производство очень большого количества относительно простых узлов (nodes). Каждый из узлов работает под управлением своей OS. Пример - архитектура Blue Gene.

Там как раз довольно сложная иерархия узлов, есть счётные под CNK, есть I/O-ноды под зюзей, в результате это выливается в очень дорогую цену масштабирования, если мне не изменяет память - один воркерер на счётный узел причём счётные узлы не так уж и быстры (PPC 700-850-MHz)

В современных беовульфах (где тоже каждый узел работает под управлением своей ОС а интеграция осуществляется за счёт общей системы управления очередями задач и общей ФС) этот показатель _в_среднем_ 4-8 на ноду а частоты в районе 3GHz

Уточнение. IO-nodes не работают под Suse.

Что такое воркерер? Если речь о количестве IO-узлов на compute node, то их один на от 32 до 128 выч. узлов. OS опять везде своя.

Насчёт не так уж быстры: для P 850MHz * 4 cores * 4 flop = 13.6 GFlops, что inline с другими производителями. А потребление поменьше.

>IO-nodes не работают под Suse.

В той pdf-ке где я читал про архитектуру BG указано что они под SLES9 И на top500 аналогичная информация http://top500.org/system/8968

>Что такое воркерер?

Единичный поток/процесс исполнения. Он один на счётную ноду если я правильно понял архитектуру

>Насчёт не так уж быстры: для P 850MHz * 4 cores * 4 flop = 13.6 GFlops,

Только вы забыли помножить на коэффициент масштабирования который для BG позорно низок (даже для HPL) а для плохо масштабирующихся задач он будет ещ позорнее.

> В той pdf-ке где я читал про архитектуру BG указано что они под SLES9 И на top500 аналогичная информация http://top500.org/system/8968

Про pdf-ку не знаю, но на top500 я не нашёл указаний, что IO-nodes работают под SLES9. Просто указано CNK/SLES9.

В L и P системах под SLES работают только login-nodes, которые к суперкомпьютеру вообще говоря отношения не имеют. На вычислительных узлах - так называемая CNK (k от слова kernel), на IO-nodes работает другая OS.

> Единичный поток/процесс исполнения. Он один на счётную ноду если я правильно понял архитектуру

Нет. L поддерживет два режима исполнения: сопроцессорный с одним потоком на узел, и виртуальный - с двумя. P поддерживает три режима, с одним, двумя, и четырьмя потоками на узел. При использовании разных режимов по разному проводится обращение у памяти.

> помножить на коэффициент масштабирования

поясните, что такое коэффициент масштабирования.

> поясните, что такое коэффициент масштабирования.

Отношение максимальной (померянной) к пиковой производительности как функция от числа воркеров

Для HPL (практически идеальная задача) Rmax/Rpeak как частный пример.

А есть _задачи_ в которых это коэффициент:

1) весьма низок (по фундаментальным причинам)

2) быстро падает с ростом числа воркеров (по фундаментальным причинам)

То есть 100 ядер по 3000 MHz это далеко не эквивалент 500 ядер по 600 MHz

> Отношение максимальной (померянной) к пиковой производительности как функция от числа воркеров

> То есть 100 ядер по 3000 MHz это далеко не эквивалент 500 ядер по 600 MHz

Всё понятно.

Можно бесконечно долго спорить, что лучше -- 100 cores по 3GHz с очень хорошим коэффициентом масштабирования для одной и плохим для другой задачи, или 500 cores по 600 MHz с теми же проблемами. Вы же понимаете, что BG, а мы вроде-как про него сейчас говорим, да и топик про IBM, не создавался как универсальное решение для всех задач. Это система для конкретных проектов, на которых масштабирование определено и гарантированно будет удовлетворительным. Да и вообще то или иное решение диктуется требованиями рынка. Сейчас BG - одно решение в своей нише, Cray XT4 - альтернативное в другой и для других задач.

>Сейчас BG - одно решение в своей нише, Cray XT4 - альтернативное в другой и для других задач.

Ну тут само собой консенсус ;)

PS: Мои задачи как раз из "других" ;)

> Мои задачи как раз из "других" ;)

Ну тогда вперёд с SGI в Oak Ridge. А у меня и из одних и из других ;)

>Ну тогда вперёд с SGI в Oak Ridge.

Ну не настолько чтобы был альтикс нужОн ;)

У меня как раз как в крее ХТ4 потроха только масштабы сильно поскромнее ;)

Я вот тут подумал в пятницу в конец рабочего дня, интересно получается, что DOE кормит и тех и других. Ничего не напоминает?

Ну это так, лирика...