ImHO один единственный узел на двух Оптеронах 240 будет стоить раза в 2-3 дешевле этого миникластера, а производительность на задачах, требующих двойной точности, будет заметно больше.
а мне вот интересно, какое ПО для кластеризации под bsd использовать, чтобы параллелить процессы, в коде которых нет поддержки параллельных процедур. В /usr/ports/parallel подобных решений нету, разве что есть два продукта - но для них та программа, которая параллелится, должна поддерживать изначально функции кластерной работы. Почитал про openmosix - патчи на ядро Линукс - тут выкладывали линк на доку. Вот это да - это то что надо. На FAQ во FreeBSD ответ на вопрос о кластерном решении краткий -"в общем случае - нет". А вот 3-party решения мне неизвестны, кто-нибудь пользовался? Хе, openmosix - это ведь ИМХО не совсем кластер, а система распараллеливания вычислений?
мля, а по существу можно и по-конкретнее? Вообще-то <something> - suxx на заборах да в лифтах подъездах вам писать надо. Тут не только детсад сидит, но и дадьки заходят серъезные
> openmosix - это ведь ИМХО не совсем кластер, а система распараллеливания вычислений?
Это как раз HPC (и уже не только) кластер с довольно давней историей в которой было довольно много интересного в том числе и BSD ... но давно.
Просто "кластер" это общее понятие группы машин, соединенных сетью и используемых для решения _одной_ задачи, а вот задачи бывают весьма разные и HPC это одна из них.
Да это группа машин. Но главная задача НА это не параллельное выполнение задачи, а обеспечение той самой "High Availability". Когда после смерти процесса принимается попытка его перезапутить, а еслти ето не удаётся и процесс критичен вся система запускается на другом ноде кластера.
угу, openmosix дергает корни из mosix, который еще давно придумали евреи. еще тогда он разрабатывался под BSD.. эх, жаль, что в BSD нету аналогов mosix/openmosix, хотя dragonfly стремится это исправить.
openmosix вещь хорошая (года 2 уже держим кластерок на нем), но дико нестабильная.
>угу, openmosix дергает корни из mosix, который еще давно придумали евреи. еще тогда он разрабатывался под BSD.. эх, жаль, что в BSD нету аналогов mosix/openmosix, хотя dragonfly стремится это исправить.
>openmosix вещь хорошая (года 2 уже держим кластерок на нем), но дико нестабильная.
ну это у них волнами идет (как и у родного мозикса) тот что был для ядер 2.4.21-2.4.22 глюкало было еще то. Я сейчас переполз на MOSIX 1.11 для 2.4.25 - впечатление пока самое хорошее (особенно на приличном железе)
Единственно чем отличается openMosix от MOSIX это гораздо более развитой userland и большее число пионерских фич (видимо это влияние лицензии)
> а мне вот интересно, какое ПО для кластеризации под bsd использовать, чтобы параллелить процессы, в коде которых нет поддержки параллельных процедур.
Как вы себе это представляете? Автоматическое распараллеливание, насколько я понимаю, - задача компилятора.
> Почитал про openmosix - патчи на ядро Линукс - тут выкладывали линк на доку. Вот это да - это то что надо.
Плохо прочитали. OpenMosix позволяет мигрировать процессам с машины на машину, распределяя таким образом нагрузку. То есть задача уже должна быть распараллелена!
Мы на 2.4.20 перелезли (хотя ИМХО, по-хорошему, 2.4.18 самый стабильный релиз).
А то что mosix сделали для 2.4.25 это гуд. Надо будет попробывать.
Пару дней назад смотрел, для 2.4.21 вроди как только был.
Всякие userspace тулузы-поделки типа MPI/PVM - все это бред. Накой оно надо, когда можно с таким же успехом запускать команды паралельно через SSH/RSH (что собственно эти тулузы и делают)?
Ладно, ждем опенмосикса 2.4.24 - обещают сделать стабильным }:-]
> Всякие userspace тулузы-поделки типа MPI/PVM - все это бред. Накой оно надо, когда можно с таким же успехом запускать команды паралельно через SSH/RSH (что собственно эти тулузы и делают)?
Это вы мощно задвинули. Со знанием дела, с пониманием. Чувствуется, что за плечами большой опыт HPC.
>Мы на 2.4.20 перелезли (хотя ИМХО, по-хорошему, 2.4.18 самый стабильный релиз). А то что mosix сделали для 2.4.25 это гуд. Надо будет попробывать. Пару дней назад смотрел, для 2.4.21 вроди как только был
2.4.25-1.11.0 пока что есть только для оригинального мозикса (www.mosix.org) Мойше видимо пока не успел для open* код стянуть ;)
>Всякие userspace тулузы-поделки типа MPI/PVM - все это бред.
Ну отчего же бред. Во первых отлично работает поверх мозикс без ssh/rsh а во вторых версия DSM патча для openMosix еще достаточно сырая да и производительность пока так себе. Плюс куча софта/библиотек используют MPI/PVM
бред вплане для настоящего SSI (single image) кластера.
процессы (в идеале; все) должны мигрировать сами по мере необходимости.
Я конечно не спорю что в этих тулузах есть польза (для конкретной задачи, опять-же, если эту задачу затачивать под МПИ/ПВМ), но согласитесь, что гораздо приятнее работать без мысли про заточку в голове. :)
только что собрал и запустил HPL+ATLAS+LAM-MPI на взятом домой поигратся новом ноде кластера (2x242 в ia32 моде) сейчас посмотрим сколько он накрутит (правда на машине крутится куча левого мусора KDE,xmms,etc ну и походу тихонько лазаю по сети и слушаю музыку)
Всякие userspace тулузы-поделки типа MPI/PVM - все это бред.
Главное их достоинство -- портируемость. Не везде есть TCP/IP, и не везде он является самым быстрым из доступных способов связи. На SMP- и NUMA-машинах надо использовать IPC, на каком-нибудь угрёбищном Парситеке с HighSpeddLinks - Parix API, ну и так далее.
Unreal2004 dajet v 2 raza bolshe chastotu kadrov chem v RedHate 9.0;
hotja i v etoi i v toj sistemah stojat poslednije drova ot NVidia.
V etoj sisteme ja vse polnostju iz source-codes sobral s opzijami
"-O3 -march=athlon". Dlja avtomatizazii ispolzujetsja nALFS parser.
V RedHate eshe ne meril x11perf , no dumaju v razi skorost menshe.
Ja dumal chto sistema budet nestabilnoj, no vse rabotaet uzhe neskolko dnej ;) --- vernee letajet !!!
Tak chto Linux RULIT !!! No ne v kachestve distributiva.
>но согласитесь, что гораздо приятнее работать без мысли про заточку в голове
Оно конечно приятнее, НО: как уже было сказано, не везде есть, к примеру TCP/IP. Это раз.
Работая с использованием MPI, возмлжности контроля и оптимизации обменов между ветвями параллельной программы много выше. Это два.
И три, правда в другую сторону: стабильность openmosix и так-то вызывает некоторые сомнения, а уж что говорить о больших кластерах с сотнями выч. узлов. Кроме того, openmosix работает ТОЛЬКО на x86.
у меня таск есть... числодробильня ))) но на доступном
Оптероне дискового пр-ва не хватает .. циферы уже есть по данному таску на
Бартоне 2700+
Атлоне 2000+ MP
P-IV 2.53 Ghz
... по поводу SMP/NUMA - OpenMP, HPF - курим доки ..
"Я сейчас курю восхитительную мысль с обаятельным запахом. Ее смолистая нега окутала мой разум точно простыней. /В. Хлебников/"
$echo.
P.s. если 50 Гб есть - было бы интересно прогнать таск ))) ?
угу ... конфигурировал я ch_shm / кажется так девайс зовется/ под PC-GAMESS. Он мне потом выдал - идешь ты лесом - дафай ch_p4 ... Очень часто кодеры не спрашивают нас - SMP у нас или нет )
$echo.
Слышь, куритель доков, если руки заточены криво, то не у всех и ch_p4 работает...
Я в первый раз слышу чтоб приложению правильно написанному под MPI было какое-то дело до MPICH'евского communication device. Я погонял немало разных задач под ch_shmem/ch_p4/ch_gm и если были runtime-проблеммы, то связанные только с тем, что что-то или в системе или в MPICH'е было криво настроено.
млять ... буратина закачай pcgamess собери расшаренный mpich а запусти под ним / очки советую надеть / - версия предпоследняя / то есть в ней
нет еще модуля DFT/ ... а потом имхо свое загоняй
$echo
Дык это то ясно как ... Я просто хотел протестировать железяку на общепринятом тесте мой собственный код разумеется умеет и OpenMP и PVM через пайпы
>P.s. если 50 Гб есть - было бы интересно прогнать таск ))) ?
Пока сотня есть ;)
BTW: кстати сравнил одну из своих задачек под один процессор с АХР не_помню_сколько+ (там реальная частота 2ГГц). Этот (242) оптерон уделывает АХП на 15-20%
самое забавное что данная конкретная задачка на АХР масштабируется по частоте (не рейтингу !!!)не линейно (срaвнивалась на 1000ТВ-FSB200-PC133 ХР1600+-FSB266-DDR266 ХP1700+-FSB266-DDR266 ) а хуже, видимо сказывается пропуcкная способность шины и памяти
Пока сотня есть ;) / за глаза /
echo1982@mail.ru
вот .. сегодня я никакой / только отходить начал ... 2 ночи гудел/(
да и выспаться надо.
прёт меня ... за последний час 2 малолетки стукнулись ... дал фоты антика из "ранних" / я думаю он не протифф / ... / - как бы дурку не уволокли .. потому как смеюсь и смеюсь...
$echo.
Дык об чем речь и шла )))))
там политика такая - pcgamess тока в виде бинариев распространяется
фраза " Очень часто кодеры не спрашивают нас - SMP у нас или нет ) "
а по поводу GAMESS-USA - у них
1) есть своя наработка DDI
2) можно с MPI собрать / это тоже проделано на одном из кластеров/
никаких проблем )
$echo.
P.s. вообщем-то извиниться надо ... злой я сегодня " мастер добрых дел сегодня злой ..." (с) Сплин . ссори за порявленную агрессивность .
>там политика такая - pcgamess тока в виде бинариев распространяется
Вобщем ясно.
Возвращаясь к SMP/NUMA системам. Если надо тестить их на HPL, (действительно общепринятый, все же, тест) он а) написан на C, следовательно про HPF речь не идет и б) написан с использованием MPI, так что и OpenMP не заюзаешь.
согласен . Но 1) GAMESS входит в наборе тестов SPEC-) 2) Если и тестировать, то на задачах, которые будут дробиться на кластере ... / как правило, разработки прошлого века)) и на фортране, если речь идет о естственнонаучных организациях и задачах/... Дальше на Ваше усмотрение -) Best regards,$echo. P.s. есть еще GAMESS-UK - если позволяют ср-ва , советую его приобрести).
>Если и тестировать, то на задачах, которые будут дробиться на кластере
Это верно, конечно, но только для случая когда известно кто и что будет пускать. А у нас, например, на машинах юзеров много и состав их разный. Кроме того в Top500 окромя HPL ничего не принимают :-) (ну может еще ScaLAPACK-овский тест).
>есть еще GAMESS-UK - если позволяют ср-ва , советую его приобрести
Не возникает потребностей у пользователей почему-то. Только BLAS/LAPACK.