Компания «Т-Платформы» начинает разработку собственных решений на базе процессоров IBM Cell

>Мою судьбу теперь тоже отслеживают?

За вами уже выехали. Ждите ;)

Ахтунг - анонимус детекдет унд расшифровен ! :)

>А если я у них купил _железо_ в софт сам пишу это как ? ;) Короче это
>всё софистика. Кто то у них покупает железо, кто то _решения_ (видел и
>таких). По факту же счёт я выписываю на _железо_ (если исключить
>пуско-наладочные работы).

Если это софистика зачем про железную фирму втирал ? :) Они в чем то типичный "русский бизнес" - "делают бабло" в той области которую понимают:)


>В курсе, но к компании "Т-платформы" в разрезе новости оно имеет
>опосредованное отношение.

У вас есть сведения что именно они _конкретно_ будут делать ?

>Т-система это детище ИСП АН СССР если мне склероз не изменяет (язык
>TC и прочая лабуда по автоматическому распараллеливанию которая AFAIK >до продакшена ни разу не дошла)

Ну это смотря что считать продакшеном. В области HPC расчетов самописный софт на кривых самописных библиотеках - норма :) посчитать на этой T-системе можно ? Можно ! Ну так в чем дело ? Их идея Т-систем прекрасно ложится на Селлы, если что.

В общем мое предположение такое - на базе T-систем они будут писать матобес под кластер с Cellами с их интерконнектом, все это перевязывать ленточкой и называть "Новый атечественнй суперкампутер Х#й^WСкиф-0010-01". Чем и будут торговать (если конечно ктото купит).

>Возможно и компания и энто самое детищи и имели когда то какие то
>общие корни в персоналиях или еще как (я не в курсе ихнего
>междусобойчика) но сейчас по факту это просто созвучное название, не
>более ;)

Ну когда то это были одни и те же люди ;) насколько я понимаю :)

>Если это софистика зачем про железную фирму втирал ? :)

Что значит "втирал" ?

Еще раз по пунктам:

1) Они делают _железо_ (в прямом смысле этого слова) То есть кремний китайско/амерекано/корейско/еврейский(как и везде) а железо (у меня к примеру это шасси и корпуса блейдов) их + сборка всего этого в кучу.

2)Они не занимаются софтом кроме как "предустановить готовый" На всякий случай: http://www.astera.ru/catalog/company/index.php?search_letter=%D0%A2&id=11...

3)Только сегодня подписывал акты. "Нежелезного" там 3.5% от стоимости.

>У вас есть сведения что именно они _конкретно_ будут делать ?

Зная что они сейчас делаю - с вероятностью в 90%. Остальные 10% можно поинтересоваться (хотя лично мне этот прожект абсолютно не интересен с профессиональной точки зрения) >посчитать на этой T-системе можно ?

Вот это по вашему продакшен ????

http://parallel.ru/russia/map/data/project15.html

> 32К узлов - кластер ?

У нас было 24 узла. Это уже кластер.

Да, с Linux on Cell уже все в порядке - система готова.

http://www.bsc.es/projects/deepcomputing/linuxoncell/

Что будут делать Т-Платформы - действительно непонятно. Видимо, и вправду тратить бюджетные (наши с вами) деньги.

> Мою судьбу теперь тоже отслеживают?

А у Вас внутри 128-разрядный плавающий сумматор, выпущенный в США? Тогда отслеживают с тем, чтобы Вас утилизировать в США после окончания срока службы. Таковы условия экспорта.

> QD (C++/Fortran-90 double-double and quad double package)

> This package supports both a double-double datatype (approx. 32 decimal digits) and a quad-double datatype (approx. 64 decimal digits). The computational library is written in C++. Both C++ and Fortran-90 high-level language interfaces are provided to permit one to use convert an existing C++ or Fortran-90 program to use the library with only minor changes to the source code. In most cases only a few type statements and (for Fortran-90 programs) read/write statements need to be changed. PSLQ and numerical quadrature programs are included.

REAL*32 здесь как раз программный, я так понимаю (есть версия для винды, которая не работает на машинах со 128-разрядной аппаратной плавающей арифметикой). Это для Ирана и прочих врагов.

>> 32К узлов - кластер ? >У нас было 24 узла. Это уже кластер.

Просто видимо имелось ввиду что это уже GRID ;)

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

>Что будут делать Т-Платформы - действительно непонятно.

Ну тут фантазировать особо не надо ;)

Слепят и продадут вам поделие на целах ;))

>Видимо, и вправду тратить бюджетные (наши с вами) деньги.

Открою вам секрет (полишинеля), они этим с 2002 года занимаются (см. список их заказчиков). Или вы предпочитаете чтобы наши с вами деньги тратили IBM и HP ?

> Да, с Linux on Cell уже все в порядке - система готова.

Yellowdog на PS3 ставят давно и официально. А толку? В таком виде он может загрузить только основное ядро PPC, а cell-ы недоступны.

>Да, с Linux on Cell уже все в порядке - система готова.

Шо серьёзно ? ;))))

Повторю вопрос. Где можно посмотреть результат для HPL хотя бы на одном целе. А к примеру OpenFOAM там соберётся ?

Я вот такую статью почитал:

http://www.lbl.gov/Science-Articles/Archive/sabl/2006/Jul/CellProcessorPotent...

Вполне приличное западное НИИ протестировало на вполне жизненных задачах. (Перемножение плотных матриц, преобразование Фурье, решение систем дифференциальных уравнений методом конечных разностей). Я не за Cell, но статью прочитал внимательно, и остальным советую.

Просто надо правильно программировать под Cell, чтобы рабочий набор программы умещался в Local store - быстрой памяти вычислительного ядра.

Из статьи не следует вывод, что все остальные процессоры плохи, но следует вывод, что всему свое место.

В статье сказано, что производительность 1 SPE (synergestic processor element, того самого 1 из 8 ядер) на операциях двойной точности в 14 раз меньше, чем на одинарной точности (и объясняется почему - особенности микроархитектуры), но путем небольших доработок чипа можно будет ее повысить.

В основном в статье Cell выезжает за счет минимального энергопотребления в расчете на гигафлопс.

Вот эту статью советую глянуть:

http://www-128.ibm.com/developerworks/power/library/pa-cellperf/

Производительность на операциях с двойной точностью при задействовании 8 SPE и 1 PPE (ядра Power) составляет 21 GFLOPS. Это уже вполне реальные цифры.

Подсчитавается это так: производительность 1 SPE на одинарной точности при 3,2 ГГц составляет 25,6 ГФлопс, на двойной точности она будет в 14 раз меньше: 1,82 ГФлопс. В процессоре 8 SPE, поэтому пиковая производительность всех SPE составит 1,82*8=14,6 ГФлопс.

Кроме того, PPE (ядро Power) также способно заниматься вычислениями с двойной точностью, и даст еще 2 операции с плавающей точкой за такт, что эквивалентно 6,4 ГФлопс при 3,2 ГГц.

Складываем пиковую производительность 8 SPE и 1 PPE на операциях с двойной точностью и получаем 14,6 + 6,4 = 21 ГФлопс.

Посмотрим таблицу 9 в этой статье:

Производительность 8 SPE процессора Cell на тесте Linpack double precision в сравнении с другими процессорами.

Для того, чтобы дать фору, задействовали только SPE, а ядро Power в расчетах не использовали. Получается, что при этом пиковая производительность 8 SPE составляет 14,6 ГФлопс (мы это подсчитали выше)

При этом реальная производительность на Linpack составила 9,46 ГФлопс, то есть эффективность равна 64,66%. Взгляните на реальную производительность Pentium4 + SSE3, 3.6GHz (7,2 ГФлопс) или Itanium, 1.6GHz (5,95 ГФлопс).

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

И еще: я совершенно согласен с теми, кто в этой ветке утверждал, что переписывать ПО будет дорого. Так что это пока что довольно нишевое решение.

На последок: довольно значительная часть научного ПО использует одни и те же процедуры типа линейной алгебры. Поэтому надо использовать библиотеки, оптимизированные под Cell. Об этом пишет Jack Dongarra, который разрабатывал тест Linpack:

http://www.hpcwire.com/hpc/692906.html

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

За сим прощаюсь.

Вот Вы всё время про свою (единственную?) задачу. И что теперь все суперкомпьютеры должны иметь минимуи гиг на гигагерц только потому, что Ваша задача будет работать оптимально? Сами же говорите:

> Ну и потом есть задачи где ...

Вот именно, есть другие задачи!

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

Да, для одного процессора программировать легче, чем для двух.Для двух - легче, чем для четырёх. Дальше - индукция.

Да, лучше иметь 1GB на узел, чем 512K. Но ещё лучше 2GB.

Вот только сложность архитектуры растёт, а значит и стоимость.

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

несколько ... лет... знакомый кто-то где-то...

Это даже не смешно. Вы вообще представляете себе скорость жизни здесь в США? А ведь в Европе я тоже пожил достаточно, могу сравнивать.

> Задачи по моделированию ядерных взрывов, решаемые ASC, требуют большего объёма расчётов и меньшей точности, чем реакторные и другие некорректные (см. другие посты).

Что такое реакторные расчёты? Моделирование свойств топлива? Разбухание? Формирование газов? Повреждение твеллов? Расчет износа? Аварии (LOCA, RIA)? Термогидравлика? Расчет потока нейтронов? Перспективные методы охлаждения (расплав соли, жидкий натрий)?

Вы уверены, что готовы квалифицированно об этом говорить? В каком из этих направлений Вам позараз нужны честные 128 bit? Какое направление решается в рамках "некорректной постановки"? Некорректной - это по Годунову - нет единственности?

Про моделирование в рамках ASCI как-нибудь в другой раз.

> У нас было 24 узла. Это уже кластер.

У нас 128K. Это "всё-ещё" кластер.

> Вы всё время про свою (единственную?) задачу.

Она (точнее это класс задач) одна из самых распространённых.

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

Это как бы 2 разные задачи: "считать быстрее" это одно а "представить данные в виде единого образа" это чуть другое, хотя они и тесно связаны.

>Для двух - легче, чем для четырёх.

Чёт вы не так делаете ;)

от 2 до 50-100 разницы нет никакой ... дальше просто более другие методы эффективны ....

>>Для двух - легче, чем для четырёх.

>Чёт вы не так делаете ;)

Ну не нужно так со мной. Вы прекрасно поняли, что имелось в виду.

Я бы назвал совсем другие этапы. Например, переходы 2 - 8, 8 - 128, 128 - 512 узлов часто очень нетривиальны.

p.s. Это достаточно смелое утверждение - CFD - один из самых распространённых классов задач. Из моего опыта - 15-20%. Конечно, и это ОЧЕНЬ субъективно.

>Просто надо правильно программировать под Cell, чтобы рабочий набор программы умещался в Local store - быстрой памяти вычислительного ядра.

:)))))

Там локальной памяти кот наплакал. Сколько целлов нужно чтобы запихнуть крошечный блочок данных в 1 млн узлов (100x100x100) для решения системы FNS уравнений в курсе ? Там всё на обменах умрёт.

>Взгляните на реальную производительность Pentium4 + SSE3, 3.6GHz (7,2 ГФлопс)

А чо не 8086 взяли ?

>Складываем пиковую производительность 8 SPE и 1 PPE на операциях с двойной точностью и получаем 14,6 + 6,4 = 21 ГФлопс.

_Реальную_ (а не целловскую - бумажную) производительность Xeon 5482 в HPL напомнить ?

>Например, переходы 2 - 8, 8 - 128

Разницы не вижу (по большому счёту)

Если уж подходить формально то ряд такой:

1 2 (1D decomposition) 4 (2D decomposition) 8 (3D decomposition) Далее идут уже аппаратные особенности построения Разумеется 2 и 3 случай могут перекрывать и большее количество узлов.

Оптимум это минимальное отношение счётного (в узлах) "объёма" блока к его поверхности (то чем блок обменивается с соседними) с учётом того что время обмена "поверхности" и время прохода "объёма" примерно известны.

>Это достаточно смелое утверждение - CFD - один из самых распространённых классов задач

см.

http://www.cfd-online.com

Тематические форумы на ЛОР (разве что кроме толкс ;)) куда более мёртвые.

> Разницы не вижу (по большому счёту)

Я всё-время пытаюсь Вам "намекнуть" (зачем?), что есть масса задач кроме CFD. Вы потому сей разницы и не видете - опыт узкий. А у меня набор задач уже наверное приближается к сотне. Разных.

>см.

>http://www.cfd-online.com

>Тематические форумы на ЛОР (разве что кроме толкс ;)) куда более мёртвые.

Спасибо. Я и так чего-то растрещался в последнее время. Праздники целых ДВЕ недели! Обычно времени нет.

>Вы потому сей разницы и не видете - опыт узкий

Ну на самом деле я утрирую разумеется. У меня скорее ведь не одна задача а набор _связанных_ задач. Какие-то параллелятся хорошо какие-то плохо.

Хотя если брать именно разные классы оно конечно не сотня но где-то десяток.

>Спасибо. Я и так чего-то растрещался в последнее время. Праздники целых ДВЕ недели! Обычно времени нет.

А там в основном студенты. Я туда раз в полгода заглядываю...

>>Вы потому сей разницы и не видете - опыт узкий

>Ну на самом деле я утрирую разумеется. У меня скорее ведь не одна задача а набор _связанных_ задач. Какие-то параллелятся хорошо какие-то плохо.

Я всё понял. Прошу прощения.

Когда-то давно всё было примерно также. Одна тематика, одна задача - копаешь, улучшаешь, лепота! Да и суперов доступных немного, значит и портировать не часто приходится. А потом стал заниматься "Application performance and data analytics". Задач посыпалось много, cистем доступных штук 20 тоже очень разных, и требование - самая дурная задача "должна работать эффективно" на самой не подходящей архитектуре :). Вот и приходится крутиться - а это статистика для обобщений.

> Там локальной памяти кот наплакал. Сколько целлов нужно чтобы запихнуть крошечный блочок данных в 1 млн узлов (100x100x100)

Вы статью-то читали? Так куда же Вы лезете в калашный ряд?

Вот посмотрите тогда эти две статьи:

1. http://en.wikipedia.org/wiki/Strassen_algorithm

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

2. http://bebop.cs.berkeley.edu/pubs/williams2007-scicomp-cell.pdf

И вот эту ссылочку почитайте, если сможете. Страничку 24 посмотрите, как там трехмерный объем делится на части, которые помещаются в Local store - локальную память SPE.

А затем гляньте на страничку 26, там в таблице показано, как горячо любимая Вами архитектура x86 безнадежно отстает от Cell.

Или вот страничка 29. Быстрое двумерное преобразование Фурье 2000x2000 точек. Тоже в локальную память не очень помещается. Однако же у Cell производительность в 40 ГФлопс на одинарной точности, у Cray X1E - 8,3 ГФлопс, а у AMD64 и Itanium2 - всего по 0,34 и 0,15 ГФлопс соответственно.

Почитайте, в конце концов, как программировать для Cell:

http://www.power.org/resources/devcorner/cellcorner/cellsdk

Кстати, в январе 2008 будет проходить конференция "Параллельные вычислительные технологии - 2008", и Т-Платформы собираются провести семинар по программированию на Cell. Сайт конференции:

http://agora.guru.ru/display.php?conf=pavt2008

В общем, зачем Вам шокировать людей своими высказываниями, когда можно ознакомиться с материалом и сделать содержательные выводы. :)

> Что такое реакторные расчёты?

Из приведённого списка -- моделирование свойств топлива и расчёт потока нейтронов (надкритичность), в частности, в зависимости от времени.

"Некорректность" -- это не отсутствие единственности (и Сергей Константинович, по-моеиму, это никогда таким образом не формулировал), а неограниченность обратного оператора в окрестности решения (т.е. неустойчивость решения при возмущениях правой части уравнения). В первую очередь некорректны задачи восстановления картины происходящих в реакторе (или другой похожей системе) по данным, снятым со внешних датчиков.

Крайне неустойчивы по начальным и граничным условиям задачи метеорологии (вид уравнений другой).

> Из приведённого списка -- моделирование свойств топлива и расчёт потока нейтронов (надкритичность), в частности, в зависимости от времени.

И что, моделирование свойств требует честных 128 бит и можно выполнять только на Sparc? Или молекулярная динамика попала в разряд некорректных? Или neutronix? Бред какой-то.

Вы контекст-то почитайте перед тем как комментировать.

>"Некорректность" -- это не отсутствие единственности ... а неограниченность обратного оператора в окрестности решения

Вы не путаете некорректность с нестабильностью?

Пардон, зарапортовался, с неустойчивостью.

>Yellowdog на PS3 ставят давно и официально. А толку? В таком виде он может загрузить только основное ядро PPC, а cell-ы недоступны.

Прекрасно доступны. А то, что основной Linux-софт не умеет им пользоваться - так это уже другая история.

>Вы статью-то читали? Так куда же Вы лезете в калашный ряд?

Да куда уж мне.

>Страничку 24 посмотрите, как там трехмерный объем делится на части, которые помещаются в Local store - локальную память SPE.

Ога. Ананимуc открыл domain decomposition ... как же я без странички 24 обошолся бы ...

Но вы таки не ответили на мои вопросы

> Прекрасно доступны. А то, что основной Linux-софт не умеет им пользоваться - так это уже другая история.

А, это имеет разницу?

>> Прекрасно доступны. А то, что основной Linux-софт не умеет им пользоваться - так это уже другая история.

>А, это имеет разницу?

А кто будет платить за порт BLAS/LAPACK/PBLAS/ScaLAPACK/ и ещё сотню пакетов ... ?

>В общем, зачем Вам шокировать людей своими высказываниями, когда можно ознакомиться с материалом и сделать содержательные выводы. :)

Затем что вы вообще не представляете масштаб задачи которую нужно решить и при этом _эффективно_

Читайте конкретику:

http://www-128.ibm.com/developerworks/ru/library/pa-linuxps3-1/

http://www.ibm.com/developerworks/ru/library/pa-linuxps3-2/index.html

А не комиксы с картинками (мы еще и не такие писали ;))

А потом попытайтесь чего нибудь осмысленное написать для cell чтобы было по скорости хотя бы немного похоже ну хотя бы на Xeon 5160

> Читайте конкретику: > > http://www-128.ibm.com/developerworks/ru/library/pa-linuxps3-1/ > http://www.ibm.com/developerworks/ru/library/pa-linuxps3-2/index.html

Вы мне даете ссылки на написание программ типа "Hello, World".

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

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

Просто признайте свое интеллектуальное поражение, и закончим на этом.

> А потом попытайтесь чего нибудь осмысленное написать для cell чтобы было по скорости хотя бы немного похоже ну хотя бы на Xeon 5160

Надоело мне искать за Вас результаты тестов.

Библиотека для преобразования Фурье (www.fftw.org) уже портирована под Cell и есть результаты тестирования.

Cell CPU (8 SPE): http://www.fftw.org/cell/cellblade/

3.0 GHz Intel Xeon Core Duo (Woodcrest), 4MB L2 cache, 64-bit mode. http://www.fftw.org/speed/CoreDuo-3.0GHz-icc64/

Читайте, сравнивайте, высказывайтесь.

Статейку еще почитайте:

http://www-static.cc.gatech.edu/~bader/papers/FFTC-HiPC2007.pdf

Да, и еще с сайта http://www.fftw.org/cell/

The Cell code in the FFTW was written and graciously donated to the FFTW project by the IBM Austin Research Laboratory. We are grateful to Pat Bohrer and Lorraine Herger of IBM for this generous contribution.

Это на вопрос о том, кто будет переписывать библиотеки. Ответ в таком стиле: тот, кому это выгодно. Сейчас IBM выгодно это раскрутить, вот они и переписывают. BLAS вроде уже тоже портировали:

http://www.bsc.es/plantillaH.php?cat_id=458&pdf=1

http://www-01.ibm.com/common/ssi/rep_ca/3/897/ENUS207-193/index.html

Денег только стоит. Ну что уж делать... :) Кому будет надо - тот и портирует.

Упоминавшиеся в ветке пакеты аэрогидродинамики CFX и Fluent есть в версиях для процессора Power. Эти пакеты поддерживают такую кучу далеко не новых платформ, что проклятые капиталисты в погоне за прибылью рано или поздно перестанут их поддерживать и переключатся на что-нибудь новое. Может, и на Cell, если будет спрос.

Конечно, надо подсчитывать и общую стоимость системы. Сейчас 1 лезвие на 2-way Quad Core Intel Xeon Processor E5345 стоит около $4000 за 8 ядер, а 1 лезвие с 2 Cell стоит, как тут говорили, около $10000.

http://www-132.ibm.com/webapp/wcs/stores/servlet/CategoryDisplay?categoryId=4... http://www-132.ibm.com/webapp/wcs/stores/servlet/CategoryDisplay?categoryId=4...

Да, Cell ужасно дорогой. Но Вы-то пытались сказать, что он неработоспособен, не может ничего нормального вычислить - а это не так.

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

Телепат ? ;)))

>Просто признайте свое интеллектуальное поражение, и закончим на этом.

Ды куда уж мне сравнится с такими "интелеХтуалами-тыорЭтикам" которые не написали ни одной параллельной программы но уже "эКспЭрты". Разумеется в демагогии я вам уступаю ;)

>Библиотека для преобразования Фурье (www.fftw.org) уже портирована под Cell и есть результаты тестирования.

Малацца. FFT конечно много где применяется (в CFD в частности тоже в ... короче название метода сам найдёш, я тут ликбезом заниматься не нанимался ;))

Только вы похоже результаты плохо смотрели по собственной же ссылке, посмотрите еще ;)

>Упоминавшиеся в ветке пакеты аэрогидродинамики CFX и Fluent есть в версиях для процессора Power.

PPC и Cell это не одно и то же. Если вы не поняли еще то Целл это Несимметричный многоядерник с L2 кешем - управляемым вручную (LS SPE-шек ) этакий апофеоз мелкозернистого параллелизма. Не будут прикладники в этой мелочи ковыряться. Беда цела не в том что он медленный (реально он нормальный середнячок в даблах) а то что его тяжело программить _эффективно_ из за его парадигмы параллельности. Почитайте про концепцию MPI microtask для целов, хотя вы скорее всего не поймёте проблем, которые возникают при программировании цела потому как видимо не имеете опыта написания параллельных кодов. Если бы вы внимательно читали (если вы вообще понимаете о чём идёт речь, в чём у меня о-о-очень большие сомнения) вы бы хотя бы правильно квотили мои сообщения не отрезая _главное_

>Да, Cell ужасно дорогой. Но Вы-то пытались сказать, что он неработоспособен, не может ничего нормального вычислить - а это не так.

Что оно может реально вычислить кроме уже приводившихся примеров обсчёта сферических коней в вакууме ?

Даже CUDA уже имеет некое (узкое) множество _реальных_ HPC задач "на показать".

> Это на вопрос о том, кто будет переписывать библиотеки. Ответ в таком стиле: тот, кому это выгодно. Сейчас IBM выгодно это раскрутить, вот они и переписывают. BLAS вроде уже тоже портировали:

>http://www.bsc.es/plantillaH.php?cat_id=458&pdf=1

>http://www-01.ibm.com/common/ssi/rep_ca/3/897/ENUS207-193/index.html

>Денег только стоит. Ну что уж делать... :) Кому будет надо - тот и портирует.

Это, надо понимать, ответ мне в контексте "какая разница как работает, главное что запускается"?

То что IBM занимается продвижением Cell - не секрет. То что Cell рассматривается как серьёзная вычислительная платформа - тоже (не думаете же Вы, что high-tech фирма со 120-летней историей будет вкладывать ТАКИЕ деньги только в игровую приставку!) То что sS мягко говоря недолюбливает "мелкозернистые архитектуры" IBM на lor неизвестно только слепому. То что программировать такие системы ЗНАЧИТЕЛЬНО сложнее, чем commodity кластеры - очевидно. То что CFD уже мало кто пишет сам, тем более здесь, на западе, и потому не будут использовать на Cell - более менее понятно и прогнозируется. А вот то, что fftw спортировали я не знал, спасибо за информацию. Вот это о многом говорит!

>А, это имеет разницу?

Огромную.

> Если вы не поняли еще то Целл это Несимметричный многоядерник с L2 кешем

Нет, я не знал. Извините. Мне очень стыдно. Я больше так не буду.

> если вы вообще понимаете о чём идёт речь, в чём у меня о-о-очень большие сомнения

Прости меня, великий и ужасный.

> Огромную.

С точки зрения разработчика - да. С точки зрения пользователя - нет.

> То что CFD уже мало кто пишет сам, тем более здесь, на западе, и потому не будут использовать на Cell - более менее понятно и прогнозируется.

CFD для нужд DCC уже есть. И для нужд DCC-же его пишут сами.

>> Если вы не поняли еще то Целл это Несимметричный многоядерник с L2 кешем > Нет, я не знал.Мне очень стыдно. Я больше так не буду.

Вот собственно о чём я и говорю ... говоришь что "не будешь" а отквотил опять соответствующим образом ...

мне повторить не тяжело.

"LOCAL STORE в SPE это L2 КЕШ С РУЧНЫМ УПРАВЛЕНИЕМ" и вместо того чтобы программить целевую задачу ты будешь убивать время на программинг логики кеша ... а это уже переход программинга в КРАСНОГЛАЗИНГ.

Ну что-ж - желаю успеха ;)))

> В Ливерморе стоят спарки со 128-разрядной АППАРАТНОЙ ПЛАВАЮЩЕЙ АРИФМЕТИКОЙ. Всё остальное там 64-разрядное. Плюс сановский фортран. На этом железе науку и двигают. 64 разрядов (и даже интеловских 80) для расчёта ядерных задач элементарно мало, у программной 128-разрядной арифметики производительность неудовлетворительная

> В службе погоды США стоят тоже спарки с тем же фортраном.

> В Натанзе, я так понимаю, стоит примерно такое же железо, подаренное Саудовской Аравией, и софт похожий (с точностью до замены солярки на убунту или сусю). :)))

> Есть положение КОКОМ, запрещающее продавать за пределы США процессоры с разрядностью плавающей арифметики свыше 80 бит. Исключение делается только для спарков, но при этом власти США стараются отследить судьбу каждого процессора, покинувшего пределы США, чтобы он не попал к "врагам". Получается не всегда :)))

> Насколько я понимаю, никакая другая компания в мире, кроме Сана, более или менее крупной серией процы со 128-разрядной плавающей арифметикой не производит. Производятся только клоны ниагары-1 где-то на Тайване. ТО же самое относится и к компиляторам, поддерживающим REAL*32: только сан и крей (машины последнего серийными назвать нельзя :) ).

> И наконец, об SSE3. Читайте интеловские доки, господа коллеги. В 128-разрядный регистр SSE3 помещается ДВА (!!!) 64-разрядных операнда плавающей арифметики, а возвращается один или два результата.

Должен ли я считать, что Саном, Ливермором и Натанзой и ограничивается продвижение науки? :))) Или все-таки в науке очень много разных отраслей и железо используется самое разнообразное? ;)

>CFD для нужд DCC уже есть. И для нужд DCC-же его пишут сами.

DCC - Digital Content Creation ?

> DCC - Digital Content Creation ?

Оно самое.

>С точки зрения пользователя - нет.

Далеко не всякого. А только живущего сегодняшним днём и пользующегося только тем, что дают.

> Если вы не поняли еще то Целл это Несимметричный многоядерник с L2 кешем

Убей меня и съешь мое сердце. Я не буду сопротивляться.

>>Денег только стоит. Ну что уж делать... :) Кому будет надо - тот и портирует.

> Это, надо понимать, ответ мне в контексте "какая разница как работает, главное что запускается"?

Да, это ответ Вам, Виталий, - но совсем в другом контексте. Мне кажется, что звериный оскал капитализма издевается то над теми, то над другими. Сейчас IBM надо раскрутить Cell - вот они и вынуждены тратить деньги. Не задаром же они портировали FFTW - ведь эта работа стоит приличных денег. Они надеются, что затраты потом окупятся.

Но это сейчас IBM тратит деньги. Потом тратить их будут все остальные. Т-Платформы продадут российским бюджетным учреждениям свои серверы на Cell, и портировать все "недопортированные" библиотеки и самописный софт придется уже российским учреждениям. Хотелось бы верить, что это будет делать ИПС РАН во главе с чл.-корром С.М.Абрамовым, которые так активно продвигали коммерческую компанию Т-Платформы в программу СКИФ и СКИФ-ГРИД. Но это из области несбыточных мечтаний.

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

Интересно бы узнать, у кого недавно покупали свои кластеры на Blade-системах от IBM два российских университета (системы вошли в список Top-500). У IBM напрямую? У реселлеров IBM? Или у Т-Платформ с наценкой?

Т-Платформы утверждают, что лучше покупать у них - деньги останутся в России. Так ли это? Т-Платформы продают кластеры на платформе Tyan, которые не делаются в России. Какая разница, у кого купить железо, сделанное на Тайване - у Т-Платформ или у IBM? Деньги и так, и так не останутся в России. Единственное, что может остаться в России - это прибыль: средства на R&D и зарплата их сотрудников. Причем есть подозрение, что на R&D много не пустят: что они собираются делать с почти 300 млн рублей государственных денег, ведь серверы на Cell давно существуют?

Как-то мне довелось задать довольно некорректный вопрос чл.-корру С.М.Абрамову, руководителю ИПС РАН и программ СКИФ и СКИФ-ГРИД.

- У нас в России есть много поставщиков кластерных решений, в том числе государственная компания XYZ. Но в программу СКИФ попала только чисто коммерческая компания Т-Платформы. Как это произошло?

- Перед программой СКИФ мы связывались с XYZ и просили от них технические предложения. Они не смогли дать ничего конкурентоспособного.

Быть может, так и было. Вопросы денег в этой отрасли очень непрозрачны. Леонид Стависский создал профсоюз и предлагал организовать контроль за расходованием бюджетных средств. С.М.Абрамов обвинил его в непрофессионализме и в попытках помешать работе.

Так и живем, и "несть конца мучениям".

Как оно на западе, получше?

Я вот думал, если lbl.gov хвалит в своей статье Cell, не может ли так случиться, что они его купили, а теперь просто вынуждены хвалить? Или на западе так не бывает? Каково Ваше мнение?

Еще момент. IBM собирается сделать компьютер Roadrunner, где будут работать совместно 16000 AMD Opteron и 16000 IBM Cell. Если США сделали такой госзаказ, значит, они готовы к тому, что придется научиться его программировать? Или там та же история, что с нашими Т-Платформами?

Я не могу ответить на все вопросы, отвечу на те, про что знаю.

С моей точки зрения сравнивать фирму производитель суперЭВМ (IBM, Cray-SGI, HP) и Т-Платформы никак нельзя (мне показалось, Вы пытаетесь это делать).

Производитель суперЭВМ содержит в своём арсенале все решения, начиная от опытного производства образцов узлов, исследовательскую разработку прототипа системы, серийное производство отлаженных блоков готовых систем, серийное производство готовых систем, и масштабирование готовых систем. Вы можете участвовать в разработке на первых двух этапах, заказать готовые блоки из этапов 3-4 или полное решение из этапов 4-5. Производителей всего порядка 5-10 компаний. Сегодня я сходу не могу назвать ни одной неамериканской компании-производителя (ну может быть кроме Nec, хотя насколько она осталась неамериканской можно дискутировать долго).

Интегратор, а Т-Платформы по-видимому являются интегратором, занимаются сборкой готовых систем из доступных на рынке компонент и доводкой системы до нужд заказчика. Этот бизнес без сомнения включает в себя массу исследовательской работы, но ограничен по сути - интегратор не может кардинально менять компоненты, у него просто нет на это средств (я не имею ввиду только финансы, это и производственные линии, и квалифицированные кадры и много чего.) Когда говорят, что Германия, Великобритания, Россия, Индия, Франция -- назовите свою любимую страну -- запустила новый супер, почти всегда имеют ввиду систему, созданную интегратором. Мне этот (кстати, хотя и самый распространённый тип бизнеса) не интересен.

Говоря про опытное производство фирм-производителей, нельзя не заметить очень интересную деталь: все опытные образцы, естественно не случайно демонстрирующие рекордные показатели, разработаны не одной компанией, а альянсом из фирмы-производителя и одной (иногда двх-трёх) из национальных лабораторий США (а значит частично на деньги DOE). Наиболее яркий пример, конечно же серия ASCI (IBM совместно с LLNL, LANL, SNL, и ANL), серия BlueGene (L,P,W,Q, IBM с тем же набором кроме SNL), серия XT (Cray совместно с SNL и ORNL), Altix (SGI совместно с Ames Labs и BNL), названный Вами проект Roadrunner (IBM совместно с LANL, SNL) и другие. Понятно что вложения такого масштаба выполняются не разово и в течение длительного срока, разработка (исследование) никогда не является гарантированно успешной и государство покрывает большую часть рисков. Если проект не демонстрирует заявленные темпы, он изменяется, в худшем случае - закрывается: государство не может себе позволить, как Вы сказали "купить, а теперь вынуждены хвалить". Американское государство всегда получит отдачу за каждый вложеный доллар!

Набор приложений, которые гарантированно должны исполняться на новом супере эффективно, оговоривается в самом начале проекта и всегда включает в себя проекты лаборатории-участника, конечно же по-профилю лаборатории. При этом набор должен обязательно включать по одному-двум проектам из двух-трёх разных направлений, и два-три проекта с комбинированной тематикой. Каждое приложение (мы из называем early application) должно гарантированно масштабироваться на всю систему и достигать определённого уровня производительности от пиковой (очень важное условие!) Поэтому вопрос не ставится так "мы тут новый комп сбацали, как бы нам теперь туда CFD впихнуть?", а так "если первоначально проект включал в себя early application Fluent, он должен демонстировать строгое масштабирование при переходе от 64K к 128K узлов 99.8% и достигать на полной системе уверенную производительность в 270TF". Если один из этапов недостижим, то скорее всего компьютер будет значительно модифицирован.

Поскольку приложения изначально написаны грамотно, они зависят от небольшого набора стандартизованных библиотек, обычно все от низкоуровневых типа BLAS/LAPACK, и некоторые от высокоуровневых типа Petsc, fftw. Портирование этих библиотек и исследование достигнутой производительности - неотъемлемый этап разработки. А ведь я не слова ещё ни сказал про компиляторы, системные библиотеки, библиотеки ввода-вывода... Кстати, Вы представляете себе сложность программирования гибридной архитектуры с узлами из процессоров разного набора команд (Roadrunner ?)

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

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

> Говоря коротко, в современном производстве суперЭВМ вопрос портирования приложений ставится не после того, как ЭВМ разработана и собрана, а до того, как начинает разрабатываться прототип. При этом прототип разрабатывается под приложения для гарантированного достижения заявленной производительности.

Как это согласуется с тем, что (по словам sS) перенос программ на Cell должен быть довольно труден? Или Cell изначально не предназначался для суперкомпьютеров и IBM сейчас просто нашла для него побочный заработок?

> Как это согласуется с тем, что (по словам sS) перенос программ на Cell должен быть довольно труден?

Так это у него и нужно спрашивать ;).

Что Вы называете "перенос программ на Cell?" Про PS3 мы сейчас не говорим, а в магазине компютер на Cell не купишь.

Если речь идёт у супере на базе Cell, то всё остальное в точности так, как по тексту. И, кстати сказать, никто не говорил что писать что-то новое будет легко. Судя, например, по списку "early applications for Roadrunner", проект hydra, производительность будет хорошая. Anonimous много интересного приводил вверху о портах.

> Или Cell изначально не предназначался для суперкомпьютеров и IBM сейчас просто нашла для него побочный заработок?

Я не знаю. А под побочным Вы несомненно имеете в виду PS3 ;)?

Назвать суперкомпьютерный бизнес IBM "побочным заработком" у меня язык никак не повернётся. А потому, мне думается, что решения в этом направлении принимаются очень взвешенные и обдуманные. Впрочем, если Sony хочет заплатить за разработку ...