IBM построит самый быстрый суперкомпьютер в мире на процессорах Cell

For floating point issue rate, you can get it from CPU vendors according to its model. For example, Xeon 50xx (Dempsey) is 2, Xeon 51xx (Woodcrest) is 4, Itanium 2 is 4 and Opteron is 2. As a result, below is an example of existing system.

>Она как раз позволяет при проектировании системы оценивать её реальную производительность.

Давай немножко разберемся.
Rpeak - это Linpack с маленькими (100x100) матрицами.
Rmax - это Linpack с большими (10000x10000 и более) матрицами.

Получается, что при тесте Rpeak вычисляемые матрицы попросту умещаются в кеше процессора. Из-за того, что кеш намного быстрее оперативки, мы и получаем почти в 2 раза разницу между Rpeak и Rmax.

У AMDшек контроллер оперативки выполнен на том же кристалле, что и проц и потому обмен данными с оперативкой более эффективен (что твои вычисления и показали). В чем причина эффективности Cray и NEC - ХЗ.

Однако тот факт, что по параметру MF на проц AMD даже в пике лишь ненамного опережает INTEL в нормальном режиме говорит о том, что AMD есть над чем работать.

И оценить реальную производительность системы по Ueff ты все-равно не сможешь. Хотя у Интелов менее эффективный обмен данными с оперативкой, общая производительность получается все-равно выше, чем у AMD.

>Само собой. Только не пиковых а реальных.

Я бы сказал, что "и тех, и других". Если ты собираешься делать большое количество вычислений над относительно малым объемом данных, то ориентироваться тебе лучше на Rpeak, а не на Rmax.

> Получается, AMD сосет у всех... Ну кроме SPARCов. :-)

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

> что и требовалось доказать.

Ктулху аж нервно ворочается ;) Может в пересчете на МГц/Tflops(Rpeak), как все люди с нехохаванным моском делают, все-же посчитаете? ;)

> > Единица измерения длины пиписьки в мире суперкомпьютеров.

> Главное не путать длину с диаметром ;)

Та тут деятели не то что длину с диаметром - по косвенным признакам еще и количество волосин на заднице посчитают ;) Нужно только не забыть обеспечить достаточное количество луж и газоуловителей =)

> Полезно только знание MF на 1 процессор.

Полезно знание Rmax/Rpeak на 1 процессоре - эффективность 1 проца, и то же самое для всего парка машин - показатель масштабируемости. Еще полезно Rmax/Cost оценивать.

>Rmax/Rpeak на 1 процессоре - эффективность 1 проца

Читай выше.

>Rmax/Cost оценивать

Этой информации не дано. Однако могу предположить, что самый низкий параметр будет у Cray, NEC, SPARC.

>зберемся. >Rpeak - это Linpack с маленькими (100x100) матрицами. >Rmax - это Linpack с большими (10000x10000 и более) матрицами.

Ты всё спутал ;)

Rpeak ~= Number of Processors * Clock Speed * FLOPS/Cycle Rmax это то что показывает HPL. Размер матрицы в общем случае не оговаривается. Но чем он больше тем результат будет в общем случае ближе к Rmax

К примеру на моих 2xOpteron-ах (по 4 гига в ноде) Ueff для одной ноды выходит на уровне 97%. При переносе всего этого дела на кластер падает примерно до 60%

Ueff это функция как архитектуры так и интерконнекта. Зная типичное значение Ueff для определённой связки я могу примерно прикинуть производительность проектируемой железяки (производитель обычно указывает пиковую, что неудивительно ;))

> Давай немножко разберемся. > Rpeak - это Linpack с маленькими (100x100) матрицами.

Чиво-чиво? 8[ ] Сцылку читали?

> Rmax - это Linpack с большими (10000x10000 и более) матрицами.

Грибы нового урожая? :) А почему не 150к-х-150к? Вона Интель обещает выдать проц о 20 с копейками кэша на проц + внутриядерный несколькиметровый кэш

> Получается, что при тесте Rpeak вычисляемые матрицы попросту умещаются в кеше процессора. Из-за того, что кеш намного быстрее оперативки, мы и получаем почти в 2 раза разницу между Rpeak и Rmax.

Бред, соотношение пиковой и реальной зависит от сбалансированности конструкции, тот же Earth Simulator выдавал на-гора Rmax в 95% от Rpeak. Толку от мегапроца, если ему вовремя не подсунуть данные?

> Однако тот факт, что по параметру MF на проц AMD даже в пике лишь ненамного опережает INTEL в нормальном режиме говорит о том, что AMD есть над чем работать.

Это если считать на проц, забывая о том, что процы АМД изначально более низкочастотные и холодные (до топ-500 конро еще не дополз).

> Этой информации не дано. Однако могу предположить, что самый низкий параметр будет у Cray, NEC, SPARC

Я не знаю, что такое "процессоры крей/нек", но самый низкий - у х86, а еще более низкий - у амд64.

s/97%/87%/g

А то совсем круто выходит ;)

Кстати может еще разок HPL пустить ;) Чё то я уже стал забывать скоко там у меня Rmax ;)

>Rpeak ~= Number of Processors * Clock Speed * FLOPS/Cycle

Это теоретический подсчет. Самое смешное, что практический (при матрицах 100х100) почти совпадет :-). По 2-м причинам:
1. Clock Speed на практике несколько отличатеся от "2.66GHz".
2. Из-за отсутствия задержек на обмен с памятью.

>Размер матрицы в общем случае не оговаривается. Но чем он больше тем результат будет в общем случае ближе к Rmax

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

Так что нет нигде противоречия. И ничего я не перепутал. :-)

>При переносе всего этого дела на кластер падает примерно до 60%

1. Сеть побыстрее сделай... Гигабит 20. :-)
2. Чем больше будет объем вычислений, тем выше будет эта цифра (падает-то в первую очередь потому, что время передачи данных сравнимо с временем расчетов)

> Это теоретический подсчет. Самое смешное, что практический (при матрицах 100х100) почти совпадет :-). По 2-м причинам:

Не волнует. Партия сказала как считать - так и считать. А то начинается, "а вот поскольку в законе тяготения 9.8 и 10 - это почти одно и то же, то можно на парить калькулятер, а считать все конструкции на пальцах, ошибка не велика, а запас в 1.5 раза уже принят и все покроет".

> 1. Clock Speed на практике несколько отличатеся от "2.66GHz".

Раза в 3-4? Хотя один фиг, если не на 30 порядков - это никому не интересно ;)

> 2. Из-за отсутствия задержек на обмен с памятью.

Т.е. в реальном мире память работает без задержек? =)

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

В кластере на задержки от памяти - плевать, если гигабитный канал поставляет 125Мб/с, то можно ставить хоть sdram, оной хватит, главное - чтобы память работала стабильно и имела средства для проверки корректности содержимого самой себя, точно так же как и в серверах.

> 1. Сеть побыстрее сделай... Гигабит 20. :-)

После чего процам будет не до вычислений, вся моща уйдет на обработку трафика от NIC... ну-ну :)

>Это теоретический подсчет. Самое смешное, что практический (при матрицах >100х100) почти совпадет :-). По 2-м причинам: >1. Clock Speed на практике несколько отличатеся от "2.66GHz". >2. Из-за отсутствия задержек на обмен с памятью.

Ты опять всё спутал ;)

Запусти HPL на матрице 100x100 и посмотри.

>1. Сеть побыстрее сделай... Гигабит 20. :-)

Дык это старый кластер с 2x1Gbit

В новом уже будет IB там 20 в одну 10 в обе с минимальными латенциями.

>2. Чем больше будет объем вычислений, тем выше будет эта цифра

Это верно не для всех классов задач. Строго говоря существует оптимум.

К примеру мой текущая задача при размере образа в 1 гиг требует обмена данными примерно каждые 3-4 секунды а пересылает эти данные раз в 10-20 быстрее. А есть задачи которые тонут в пересылках тысяч мелких пакетов и там обратное соотношение. Опять же от размера пакета зависит и много от чего еще. Например дешёвые sk98 на совсем мелких пакетах как ни странно заруливают broadcom-ы Всё это можно проверить и оттюнить.

>В кластере на задержки от памяти - плевать, если гигабитный канал поставляет 125Мб/с,

Ну 125 это ты хватил ;) Я в _голом_ виде больше 120 не получал

А MPI<->TCP<->GigE<->TCP<->MPI это хорошо если 70 Когда транком то оно да, за 100 регулярно.

>После чего процам будет не до вычислений, вся моща уйдет на обработку трафика от NIC... ну-ну :)

IB это пофиг. Они данные забрасывают практически не нагружая проц прямо в память.

>Партия сказала как считать - так и считать.

Так и считают. Сначала высчитывают теоретические Rmax и Rpeak, а потом на тестах Linpack их подтверждают.

>Раза в 3-4? Хотя один фиг, если не на 30 порядков - это никому не интересно ;)

Где там разница больше 1%??? Вы хоть понимаете о чем речь идет?

>Т.е. в реальном мире память работает без задержек? =)

При тестировании на Rpeak вся дата будет умещаться в кеше процессора.

>В кластере на задержки от памяти - плевать, если гигабитный канал поставляет 125Мб/с, то можно ставить хоть sdram

Ну-ну. Проведите эксперимент. Найдите тест Linpack и выполните его на своей машине... Скажем, 10'000x10'000. Размер данных ~96 Мб, то есть они теоретически за секунду по гигабитному каналу передадутся. А считать будет десятки минут. Ну а уж если вы sdram поставите (а почему не SIMM тогда уж? :-) ), то к вашей пенсии тест закончится.

>После чего процам будет не до вычислений, вся моща уйдет на обработку трафика от NIC

Мне жаль, что у вас нет денег на сетевую карточку с Bus Master и поллингом.

>10'000x10'000. Размер данных ~96 Мб

Щаз ;) У тебя double 1 байт ;) ?

Сории. :-) Стормозил. :-)

Ну, в общем, секунд за 10 скачается. :-)

На вот почитай насчёт этих тестов научно популярную статейку.

http://www.osp.ru/text/302/380430/

Должно помочь поправить представление о том чего в top500 меряют и как.

Sorry za oftop, no Wi mpich na Opteronax ne sobirali ?
Esli kompillirovali sami, ne mogli bi wi kljuchi dlja configure skinut` ?
Zaranee blagodaren,
Vic.
P.s. Nashi admini tol`ko IA-32 dergit libmpich.a ... Mne nugen d&#246;ja 64-x bit. Tak poluchilos, chto tol`ko mne nugen takoy mpich i mpi voobshe)

>Sorry za oftop, no Wi mpich na Opteronax ne sobirali ? >Esli kompillirovali sami, ne mogli bi wi kljuchi dlja configure skinut` ?

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

У меня только тот почтовый ящик на хотмыле с которым мы с вами переписывались умер вместе с вашим адресом.

>P.s. Nashi admini tol`ko IA-32 dergit libmpich.a ... Mne nugen d&#246;ja 64-x bit. Tak poluchilos, chto tol`ko mne nugen takoy mpich i mpi voobshe)

А система сама под 64-бита ? /lib64 есть ?

А не напомните, сколько mpich весит и где его взять?

Если до 10 мегов, могу попробовать выкачать и подобрать конфиги (у меня Celeron EM64T и Slamd64)

MPICH2 http://www-unix.mcs.anl.gov/mpi/mpich2/ (13 мегов)

MPICH-G2 (для grid) http://www.hpclab.niu.edu/mpi/

Нужен именно MPICH или lam тоже пойдёт ?

> Ну 125 это ты хватил ;) Я в _голом_ виде больше 120 не получал

Ладно, ладно, выкинем служебку от TCP и ethernet и получим 120 гиг :)

> А MPI<->TCP<->GigE<->TCP<->MPI это хорошо если 70 Когда транком то оно да, за 100 регулярно.

Угу, чем дерганнее обмен и больше мелких пакетиков - тем хужее скорость, все как полагается.

> IB это пофиг. Они данные забрасывают практически не нагружая проц прямо в память.

Тогда -1.

А это как ему надо. :-) Мне пофиг, в общем-то... :-)

Разве что интересно проверить, правда ли что MPICH может в кластере на смешанных платформах работать (на 2-й машине Celeron+Slackware).

> Так и считают. Сначала высчитывают теоретические Rmax и Rpeak, а потом на тестах Linpack их подтверждают.

Бррр...

> Где там разница больше 1%??? Вы хоть понимаете о чем речь идет?

Вы читали мануал "физики шутят"? ;) В реальном мире, разговора нет, даже 1% для колебаний частоты - это уже много.

> При тестировании на Rpeak вся дата будет умещаться в кеше процессора.

Какое еще тестирование? Rpeak - это аппаратно обусловленная пиковая производительность. А Rmax - максимальная реальная по линпаку, зависит от дофига чего и считаться может исключительно "в таких-то условиях мы насчитали".

> Ну-ну. Проведите эксперимент. Найдите тест Linpack и выполните его на своей машине... Скажем, 10'000x10'000. Размер данных ~96 Мб, то есть они теоретически за секунду по гигабитному каналу передадутся. А считать будет десятки минут. Ну а уж если вы sdram поставите (а почему не SIMM тогда уж? :-) ), то к вашей пенсии тест закончится.

Передергивать не нужно, считаем что обмен данными идет исключительно через сеть мелкими порциями, посему процы всяко успевают считать а данные влазят к кеши, т.е. ограничением является пропускная способность канала (как я сказал - 1Гбит).

> Мне жаль, что у вас нет денег на сетевую карточку с Bus Master и поллингом.

На святое дало деньги всегда найдутся ;) Но 2х10Гбит и 1 Гбит - таки две большие разницы, и хорошо если обмен большими кусками и задействование поллинга вполне допустимо.

Seychas poshel administratorov pomuchal. Chudniy reprozitariy pokazali, tam est` takie mpich: mpich-gcc64 mpich-icc64 mpich-pathscale Vzjali pod moim rukovodstvom gcc-64. Polet normal`niy. Ja toge v svjazi s pereezdami uterjal chast`kontaktov-( moy email quantch at gorodok.net Da, tut interesnaja situacija s OS. Ona v kakom-to gibridnom regime, no /lib64 est`, a mne integer8 nugen po structure zadachi (adressacii massivov > 2**31-1). P.s. Seychas v BW zemle. Bayern na ljubitelja)

Spasibo, no uge sdelali. Eto ja prosto dikiy takoy-). Civilizacija.

> И кто сосет?

Это всего лишь говорит о том, что КОГДА-ТО интел был лучше, и люди по старой памяти всё ещё покупают его. Но ситуация меняется :)

> или я туплю может? или прогресс какой проявился в линупсе ?

Судя по http://www.top500.org/stats/27/os/ , среди них 498 идиотов и ровно два таких же умных, как ты :)

> и толку?

Это была шутка. mosix официально только x86. (кажется). У них пока нет в stable даже x86_64. С другой стороны в виде сторонних патчей есть очень много фишек, в том числе и миграция потоков. Вероятно, неплохой интерес может быть когда (если) выйдет очередной stable.

> да и опять же какая там fs?

Своя. Ещё всякие сторонние можно использовать, типа GFS.

> которая на себе умеет хранить объекты IPC?

Смотря какие. sharedmemory - часть решения по вытеснению потоков, другие компоненты я не проверял, но сетевые библиотеки ipc тоже не редкость.

> не говоря уже о стоимость миграции процессов и так далее.

А вот это уже чисто от задачи зависит. Долгоиграющие процессы/потоми вполне могут окупить затраты на вытеснение.

На самом деле есть и решения, более проверенные. Весь вопрос в том, что считать на такой системе. А способ найдётся...

Судя по тексту новости IBM собирается ставить туда обычные Cell'ы, в которых, как известно, медленно работают вычисления с двойной точностью, обычные для HPC. Честно говоря, меня это удивляет. Как можно ставить плохо заточенные под HPC камни в суперкомпьютер ?

>а какой дистр в основном ставят на такие компы? RHEL?

Red Hat Linux Version 4.3 http://today.reuters.com/news/articlenews.aspx?type=technologyNews&storyI...

> Угу. Почитай в предыдущих новостях про LHC - там обещали гигабайт в секунду получать инфы. Так что...

гигабайт в секунду может и восьми процессорный Altix сделать.

и интел опять лучше, конро вне конкуренции.

У IBM есть свой процессор PowerPC - почему его не используют и свой любимый AIX?

если интел лучше, почему тогда решили использовать Оптероны???

> Куплю пару секунд для пересбоки мира.

Под "железо" затачивать будешь?

>У IBM есть свой процессор PowerPC

Так а Cell - это тот же Power, только с добавлеными 8-ю SPE.

AIX - фиг знает. Может, просто пеар линукса. Может, AIX хуже заточена для SPE. А может софт, который будет крутиться, для Linux написан.

А может, просто NNSA бабло на AIX пожалело... Типа сам посчитай:
если ноды будут 4-х процессорные, то понадобится (16'000*2)/4==8'000 лицензий на AIX. К тому же, бимеры вроде бы как продавали лицензии на AIX в расчете "на ядро"... Оптероны 2-х ядерные и Cell с 9-ю ядрами. Эм. Получится 2*16'000+9*16'000==176'000 лицензий. Сколько это в убитых енотах - ХЗ.

после сосбсвенно PowerPC у IBM проскочили ещё G3-G4-G5
Cell достойный продолжатель линейки, не пойдя на поводу у Apple сероголубые таки не стали снижать вычислительную мощность проца в угоду теплообмену.... Вот тут как чёрт из табакерки и вспплыл(все мы знаем что оно не тонет) DualCore.
AIX - немного не для тех задач, вообще у IBM это не единственаая ОС OS/2 , OS-9 , OS 360/390 и что они там сейчас пользуют на своей z-Series?

> Судя по тексту новости IBM собирается ставить туда обычные Cell'ы, в
> которых, как известно, медленно работают вычисления с двойной
> точностью, обычные для HPC. Честно говоря, меня это удивляет. Как
> можно ставить плохо заточенные под HPC камни в суперкомпьютер ?

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

>Это была шутка. mosix официально только x86. (кажется). У них пока нет в stable даже x86_64. С другой стороны в виде сторонних патчей есть очень много фишек, в том числе и миграция потоков. Вероятно, неплохой интерес может быть когда (если) выйдет очередной stable.

так а ссылки ? ;)

>Своя. Ещё всякие сторонние можно использовать, типа GFS.

понятно ...

>Смотря какие. sharedmemory - часть решения по вытеснению потоков, другие компоненты я не проверял, но сетевые библиотеки ipc тоже не редкость.

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

>А вот это уже чисто от задачи зависит. Долгоиграющие процессы/потоми вполне могут окупить затраты на вытеснение.

ну тут, да , я погарячился ...

Typical compute processes, file IO, and communication activity will be handled by AMD Opteron processors while more complex and repetitive elements -- ones that traditionally consume the majority of supercomputer resources -- will be directed to the more than 16,000 Cell B.E. processors

так что все таки будет делать целл ? что это за более сложные и повторяющиеся элементы чем "Typical compute processes, file IO, and communication activity"

Вероятно просто не подходит по скорости или дороже получается

>Судя по http://www.top500.org/stats/27/os/ , среди них 498 идиотов и ровно два таких же умных, как ты :)
Это называется Windows 2003 уверенно выходит на рынок кластерных систем, обойдя RHEL4 с втрое большим количеством процессоров :-)

> если интел лучше, почему тогда решили использовать Оптероны???

Потому что головой люди думают и строят систему на процах от компании, которая реально умеет их делать, а не на камнях от рассадника маркетоидного бреда, который только год назад кое-как очухался =)

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

> Это называется Windows 2003 уверенно выходит на рынок кластерных систем, обойдя RHEL4 с втрое большим количеством процессоров :-)

Судя по единичному количеству этой шняги, общее TCO небось в 9 раз выше, чем у редхэта, обо согласно давней традиции основное бабло уходит на "лицензирование" и "оплату труда инженеров", мастдаившихся с ее настройкой, а не на само железо ;)

>Da, tut interesnaja situacija s OS. Ona v kakom-to gibridnom regime, no /lib64 est`

Скорее всго в x86_64 + 32 битный режим совместимости

>P.s. Seychas v BW zemle. Bayern na ljubitelja)

M&#252;nchen ?

Каких то 6 часов на поезде от меня ;)

>так а ссылки ? ;)

По x86_64 http://freshmeat.net/projects/openmosix/?branch_id=21918&release_id=193392

По миграции тредов http://freshmeat.net/projects/migshm/

Первое сильно в альфе второе вроде работало, но на 2.4.x