Интересно, а бинарное зеркало генту, которое под всевозможные процы скомпилено, - оно вот на таком вот сервере компилится?

...

>На какой архитектуре построенны процессоры и сколько стоит - не сообщают...

MIPS64 по 500MHz на ядро.

В результате заявляные 648 Гигафлопсов это ... для 648 ядер

То есть оверхед будет мама не горюй. Вообще не представляю что можно будет эффективно решать при такой архитектуре. Разве что рендеринг или Монте-Карло какие несильносвязанные. 80% ресурсов уйдёт на синхронизацию этого ужаса.

...

>И это всего-навсего 1 проц, уже пара таких влегкую порвет младший, а десяток - старший "суперкомпьютер".

Ты лучше не мурзилку а спеку в pdf-ке почитай. Это поделие разве что само себя порвёт ;)

>http://www.ixbt.com/news/all/index.shtml?07/17/22
Где купить?

> То есть оверхед будет мама не горюй. Вообще не представляю что можно будет эффективно решать при такой архитектуре. Разве что рендеринг или Монте-Карло какие несильносвязанные.

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

даешь каждому процессу по процессору! :)))))

...

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

Это не НPC задача ;) У нас с такой сейчас справляется старая четвёрка (486) Правда датчиков относительно немного ... около 50

Сейчас правда новую заказали. Процессор там на 158 месте по значимости.

PS: Я боюсь, что чтобы загрузить мой новый кластер такой задачей придятся таких датчиков вагон к нему прицепить (железнодорожный - на 60 тонн ;) )

> годных для того, чтобы владеть небольшой группой исследователей:)

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

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

> Это не НPC задача ;) У нас с такой сейчас справляется старая четвёрка (486) Правда датчиков относительно немного ... около 50

> Сейчас правда новую заказали. Процессор там на 158 месте по значимости.

> PS: Я боюсь, что чтобы загрузить мой новый кластер такой задачей придятся таких датчиков вагон к нему прицепить (железнодорожный - на 60 тонн ;) )

нам за сброс (период 10 секунд) надо зачитать, собрать и записать ~150 мегабайт (в сумме больше десяти тысяч каналов, до ста тысяч триггеров за сброс), чтобы сгенерить монте-карло для одного сеанса нужно полсотни современных атлонов загрузить на несколько месяцев в нон-стоп. В ЦЕРНе на LHC-ишных строящихся экспериментах за пару секунд будет вылетать данных на полную сиди-болванку, вес измеряется в тысячах тон ("...weigh approximately 12500 tonnes": http://en.wikipedia.org/wiki/Compact_Muon_Solenoid). low-latency interconnect здесь нахрен не нужон, параллелится просто идеально.

> ага-ага :) apt-apt-apt (по типу того-же-самого) > =)

Не в кассу, apt-apt-apt - то только если ОЗУ 2Мб, и винт на 47Мб без свопа и бута. То бишь - виснет и слетает сцуко, по нехватке памяти. В противном случае - достаточно одного раза ;)

> Ты лучше не мурзилку а спеку в pdf-ке почитай. Это поделие разве что само себя порвёт ;)

Да пока тут народ тер - эта фигня в рваный баян превратилась, читаем:

http://www.ixbt.com/news/all/index.shtml?07/18/68

12 терафлоп на шкаф, порвет всех - покупать у Межстроймаша в начале 2008-го.

> То есть оверхед будет мама не горюй. Вообще не представляю что можно будет эффективно решать при такой архитектуре.

В документах эти хлопцы заявляют, что у них очень эффективно реализованный MPI. В PDF по ссылке они утверждают, что эффективность процев не так важна, как эффективность коммуникаций. Наверняка, задачи где это верно найдутся, только вопрос как много таких задач. Жалко, что у них на сайте нету никаких результатов benchmark'ов.

...

>нам за сброс (период 10 секунд) надо зачитать, собрать и записать ~150 мегабайт (в сумме больше десяти тысяч каналов, до ста тысяч триггеров за сброс), чтобы сгенерить монте-карло для одного сеанса нужно полсотни современных атлонов загрузить на несколько месяцев в нон-стоп

Вы же их не в Real-Time _обрабатываете_ ;)

PS: 50 топовых 2-х ядерных оптеронов это ~500 Гигафлопсов. Так что для риалтайма на таких железяках вам придётся отбашлять сумму-сравнимую с ценой упомянутой железяки предположим 2 месяца сжать в 10 сек это 2x30x24x360 =~520 000 субжевых "суперкомпутеров"

...

>В документах эти хлопцы заявляют, что у них очень эффективно реализованный MPI.

Дело не в эффективности реализации MPI а в эффективности самого алгоритма.

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

К примеру такой же по пиковой производительности кластер на 2-х ядерных оптеронах будет иметь этих ядер в ~10 раз меньше а даже не топовая IB будет в данном раскладе иметь вдвое большую пропускную способность на одно ядро.

Две задачи, которые еще худо бедно будут параллелится на этом чуде я назвал. На остальных (на моих в частности) это поделие идёт в сад.

> Вы же их не в Real-Time _обрабатываете_ ;)

есть идея on-line фильтрации в софтверном триггере, будет оно или не будет, пока вопрос :|

> PS: 50 топовых 2-х ядерных оптеронов это ~500 Гигафлопсов. Так что для риалтайма на таких железяках вам придётся отбашлять сумму-сравнимую с ценой упомянутой железяки предположим 2 месяца сжать в 10 сек это 2x30x24x360 =~520 000 субжевых "суперкомпутеров"

не так, сеанс это примерно месяц записи физ данных в такой моде => 150 мегабайт _каждые_ 10 сек, если писать всё, то в месяц получим ~40 терабайт, если софтовый триггер уменьшит поток хотя бы в половину за счёт отрезания фона и с мизерной потерей интересных данных, то это будет уже очень круто. Ну вот: 100000 триггеров за 10 сек на 50 процов => каждый проц должен за секунду реконструировать минимум 20 событий. Обработчики говорят можно вполне успеть. Перебор время сжирает, время перебора факториально растёт от числа хитов, зараза :(

...

>не так, сеанс это примерно месяц записи физ данных в такой моде => 150 мегабайт _каждые_ 10 сек, если писать всё, то в месяц получим ~40 терабайт, если софтовый триггер уменьшит поток хотя бы в половину за счёт отрезания фона и с мизерной потерей интересных данных, то это будет уже очень круто. Ну вот: 100000 триггеров за 10 сек на 50 процов => каждый проц должен за секунду реконструировать минимум 20 событий. Обработчики говорят можно вполне успеть. Перебор время сжирает, время перебора факториально растёт от числа хитов, зараза :(

А что мешает вдвое увеличить число узлов ? Цена вопроса где-то на уровне $30-50k в зависимости от интерконнекта. Тем более если вам не нужен низколатентный интерконнект то как раз по нижней границе диапазона.

> http://www.ixbt.com/news/all/index.shtml?07/18/68

> 12 терафлоп на шкаф, порвет всех - покупать у Межстроймаша в начале 2008-го.

"...Tom Engel, a high-performance computing specialist at NCAR, said the new hardware -- nicknamed Blueice -- includes 872 dual-core IBM Power5+ 1.9-GHz CPUs, for a total of 1,744 CPUs in a 10-rack cluster."

http://www.ucar.edu/news/pressclips/

12 терафлоп на 10 _стоек_с_водяным_охлаждением_

...

Кхе ... ;) Rpeak/Rmax = 12/2 ??? Вот они - поверы во всей красе.

Кстати в других пузомерках оно конечно выглядит не так удручающе но тенденция очевидна http://www.supercomputers.ru/?page=rating

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

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

...

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

100 процов это 4-5 блейд-серверов (8-9U каждый и в кажном по 10-12 блейдов ) Влезут в 2 стойки легко. В одну если утаптывать ногами ;) Там проблемы не оптику к ним проложить а питание подвести (~5КWt на блейд-сервер) и тепло от них отвести (кондёр на соответствующую холодопроизводительность)

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

> Это не НPC задача ;) У нас с такой сейчас справляется старая четвёрка (486) Правда датчиков относительно немного ... около 50

> Сейчас правда новую заказали. Процессор там на 158 месте по значимости.

>PS: Я боюсь, что чтобы загрузить мой новый кластер такой задачей придятся таких датчиков вагон к нему прицепить (железнодорожный - на 60 тонн ;) )

Не тот детектор :) - имеются в виду ФЭЧи. Но про массу вы правильном направлении думается, только всё сильно не дооценено :) - поряка на три примено для нашего маленького локального эксперимента. Про всякие Atlasы в CERN я вообще даже думать боюсь.