Silicon Graphics презентовала самый мощный в мире компьютер под управлением одной копии Linux - SUSE Linux Enterprise Server 10 на 1024 процессорах (предыдущий рекорд - 512)
> ...image processing na SGI slivaet AMD nepadetski.
Вообще ничего не понял...
И софт-, и хардварными решениями от SGI я вполне доволен. В последнее время я недоволен Итаниумами -- будучи на порядок дороже Оптеронов, они в разы тормознутее по гигагерцам, и даже с учетом приведения по тактовой частоте на целочисленном счете Итаниумы сливают и Оптеронам, и старым Альфам. Очевидно, процессор мертв...
С др. стороны, Оптерон с его ГиперТранспортом и свичем на процессоре -- попса. Больше 8 процов соединить невозможно в принципе (ок, возможно, но будут тормозить), и все это -- NUMA-подобная штамповка. То, что АМД делает в виде чипсета, SGI делает в виде ящиков с проводами. Никаких проблем смасштабировать вплоть до 1024 процессоров на роутерах и "fat tree" топологии на основе их NUMAlink. Дорого -- да, но по сравнению с сопоставимыми по производительности сетевыми решениями от Квадрикса -- даже дешево!
Итаники все портят... Жалко, что по чисто маркетинговым причинам Ориджены на родных SGI Мипсах никто не хочет покупать!
"На рынке всегда побеждает самое кривое техническое решение" ...
Хехе первым 10 постам видна высота полёта местных посетителей. Между прочим SLES - один из сертифицированных оракелом дистрибутивов. Всякие генты и слаки можете себе засадить куда хотите и как хотите глубоко - ни одна считающая свои деньги крупная фирма не станет поддерживать свой софт на пионерских несертифицированных конструкторах.
>Silicon Graphics презентовала самый мощный в мире компьютер под управлением одной копии Linux - SUSE Linux Enterprise Server 10 на 1024 процессорах (предыдущий рекорд - 512)
через неделю Novell выпустит патч для Сузи, который исправляет скорость работы на этом комрьютере. Сейчас програмисты заняты тем, что вставляют в код Sleep (100000); куда только можно.
Я вижу, каждый день, честно... В качестве "общественно-полезной" нагрузки мне ДЕЙСТВИТЕЛЬНО приходится эти самые Альтиксы администрировать. И оно _действительно_ именно так масштабируется... :)
То есть, шедУлер тут не при чем. Оно ДЕЙСТВИТЕЛЬНО способно вот так просто считать циферки...
Тормозит, когда ОЗУ мало. Вот у меня 256 стоит, для Сузи не хватает, даже для xfce, сидел за fvwm. А в Слаки хоть бы хны. Хватает на quake4 ещё. (если вырубить своп, то отрубается на первом монстре)
Ох уж эти сказки, ох уж эти сказочники... На чё у тя там хватает? На 10 FPS? С прогрузкой свопа через каждые 10 секунд? Ну-ну, WindowsXP вон тоже запускается на 75 мегагерцах, даже нутпад открыть думаю возможно =)
2 Die-Hard: ООО привет владельцам альтиксов :-). На самом деле производительность Альтикса будет прилично выше, если использовать MPI от SGI, да еще и RASC модули. Мы в своё время лажанулись, когда в топ-50 свой альтикс отправили, но вместо использования родного MPI использовали интеловский - результат не очень высокий. Смысл такого комплекса как правило в том, чтобы иметь возможность запускать софт в рамках одной системы, т.е. не использовать MPI. Для геологов кстати очень удачное решение. Хотя в принципе если использовать партишены, то производительность не падает :-).
Кстати по поводу СУСи, до сих пор ставлю на альтиксы только редхат, ну ненавижу сусю, с ней столько гемора было.
>а ты ее, "масштабируемость" видел? И я видел, более того даже щупал :-)
>думаю, стандартный лялих на этих 1024 головах в самозабвении занят только scheduling'ом . В вашем случае лучше не думать вообще. Я не знаю, что у тебя понимается под "стандартным лялихом", но вот то, что сертифицировано под Альтиксы занимается не только шедулингом, но ещё и расчетами, ну или ораклом - что захочешь.
>а хитрые SGI'овцы отключили у себя все планировщики и гоняют одну числодробильную задачу с прямым доступом в память ветвям... И пусть гоняют (хотя это ваш очередной бред), если архитектура позволяет. К тому же линпак пока ещё никто не отменял.
> ...циферки тебе чуть ли не каждая DOS посчитает, а вот как только IO появляется - кранты.
Ну вот не надо!
Я уже несколько дней пытаюсь в General и Talks получить ответ на вопрос, почему тот IO тест, что на Альтиксах показывает 300 MB/s, на Оптеронах больше 80 MB/s не тянет...
А масштабируемость по процам, извини, как-то даже неприлично сравнивать...
> На самом деле производительность Альтикса будет прилично выше, если использовать MPI от SGI, да еще и RASC модули.
Разумеется, мы это и юзаем.
> ... вместо использования родного MPI использовали интеловский
Как-то даже непонятно...
Интеловский MPI, мягко выражаясь, не очень...
> ...до сих пор ставлю на альтиксы только редхат, ну ненавижу сусю, с ней столько гемора было.
Ну, у нас обратная ситуация: Зюзя -- корпоративный стандарт (кстати, я ею вполне доволен!), но в то время, когда мы покупали первый Альтикс, на нем был доступен только РедХат. Мы спрашивали про Зюзю, но нам ответили, что это все не так просто...
Теперь мигрировать совершенно неохота (хотя SGIцы уговаривают), раз работает. Единственный гемморой я поимел при прикручивании NIS+, но теперь оно работает.
> ...циферки тебе чуть ли не каждая DOS посчитает, а вот как только IO появляется - кранты.
>Ну вот не надо!
>Я уже несколько дней пытаюсь в General и Talks получить ответ на вопрос, почему тот IO тест, что на Альтиксах показывает 300 MB/s, на Оптеронах больше 80 MB/s не тянет...
в огороде бузина, а в Киеве ТЕТКА! Слушай, ты вроде разумный человек... Ну при чем тут оптероны и даже IO тест. Я про OS говорю, и никто до сих пор мне не доказал, что использование лялиха на таких системах годится только для считанного количества числодробилльных задач, которым OS по большему счету до фени. Собственно объем рынка SGI это подтверждает...
для сложных задач с одновременным интенсивным использованием памяти, IO, многозадачности (вроде, скажем, TPC) лялих на таких системах смешон.
> и никто до сих пор мне не доказал, что использование лялиха на таких системах годится только для считанного количества числодробилльных задач, которым OS по большему счету до фени.
Ну, ты можешь говорить что угодно, но я-то сам тесты делал.
Я девелоплю именно сложную задачу, с одновременным интенсивным использованием памяти, IO, итд. И я лично тестировал и сантехнику, и ИБМ, и Хпукс, и НЕК, и Тру64 (Оптеронов тогда еще не было).
Альфы были лучше всех, но дохлые. ИБМ и Сантехники предлагали нечто маловразумительное. Хваленый Хпукс Линуксу совершенно слил.
В конце остались Нек и SGI, оба с Линуксом. Выбрали SGI, поскольку они сотрудничали лучше.
> Собственно объем рынка SGI это подтверждает...
Собственно, не только SGI в такие игры играет. Есть еще IBM, HP, NEC...
Но вот такие мощные компъютеры мало кому нужны. Когда я слышу про эти ваши "сложные" задачи "с одновременным интенсивным использованием памяти", когда про супер-пупер сервер говорят, что он рулит аж терабайтной базой с помощью M$SQL, мне немного смешно делается. Нам бы ваши проблемы...
ну вот, что собственно и требовалось доказать. Я прекрасно понимаю, что числодробилка сложная штука, я сам разрабатывал и под MPI и под PVM, но OS проявляет свои свойства совсем в других условиях, а не там где задача девелопится с нуля одной командой.
доказать теорему ферма и разработать параллельную СУБД + сервер приложений - обе задачи сложные, но для первой достаточно полей на книге (утрирую конечно :-))
>Я девелоплю именно сложную задачу, с одновременным интенсивным использованием памяти, IO, итд. И я лично тестировал и сантехнику, и ИБМ, и Хпукс, и НЕК, и Тру64 (Оптеронов тогда еще не было).
>Альфы были лучше всех, но дохлые. ИБМ и Сантехники предлагали нечто маловразумительное. Хваленый Хпукс Линуксу совершенно слил.
собственно то, что ты упрямо мешаешь железо, фирмы и UNIX'ы в одну кучу наглядно подтверждает что твоей задаче OS не нужна.
> собственно то, что ты упрямо мешаешь железо, фирмы и UNIX'ы в одну кучу наглядно подтверждает что твоей задаче OS не нужна.
Сдается мне, что полезная информация в этой фразе отсутствует. По крайней мере логика явно страдает...
Я утверждаю, что при выборе решения под нашу задачу было протестировано множество комбинаций железа и софта от самых разных фирм, и в итоге было выбрано решение от SGI с Линуксом в качестве операционки. Ты из сообщенного мной факта широкого тестирования почему-то делаешь вывод, что для моей задачи операционка не нужна...
Ради Бога, я не собираюсь с тобой спорить. Ты не знаешь, что за задачу я имею в виду; а я все это дело сам гонял и сравнивал. Кстати, это отнюдь не тупая числодробильня, а в ее разработку вбуханы десятки человеко-лет.
> Ради Бога, я не собираюсь с тобой спорить. Ты не знаешь, что за задачу я имею в виду; а я все это дело сам гонял и сравнивал. Кстати, это отнюдь не тупая числодробильня, а в ее разработку вбуханы десятки человеко-лет.
числодробильня бывает очень даже и не тупая, у меня есть пример одной на 30 ч/лет. И IBM тоже вбухивает кучу денег в софт на своих супервычислителях, но там все самописанное под задачу и железо, а линакс для них просто запускалка задачи.
> Неофициально -- уже год назад инженер от SGI убеждал меня мигрировать на Сузю, поскольку они вскоре в SGI это сделают. Причины достаточно банальные: РедХет не соглашается на более тесное сотрудничество, типа, объемы SGI для Красной Шапки слишком малы, чтобы с ними возиться. Поэтому SGI клепал свой собственный RH-based дистрибутив (SGI ProPack), а Красная Шапка от этого была не в восторге. Сюзя же с SGI с 2003 года ОЕМ партнеры, и Сюзя охотно шла на сближение. В результате, Сюзя согласилась поддерживать их ПроПак, а РедХет в это время пытается окучить HP (по части Итаников).
> Вот такую историю мне поведал инженер технической поддержки от SGI прошлым летом...
спасибо, просветили. Приятно, черт возьми, иметь своих инсайдеров на ЛОРе :)
Suse 10.1 все же рывок в скорости. Даже как-то непосусевски :). По сравнению с 10.0 прогресс в скорости есть, т.е. субъективное мнение: стоит сделать апгрейд.
Память тут определяющее. Но, памяти жрет мало. Даже OpenOffice Writer повышает столбик всего на 10-25 Мб.
В общем приятно работать в системе. Молодцы, оптимизировали, а не погнались за фенечками.