Нет, но собираюсь, возможно, подключиться к работе по моделированию генома, а включать в список своих мытарств еще и ВЦ СО РАМН или ВЦ в Кольцово - желания не имею...
Во-первых, даже самый примитивный кластер Beowulf-класса на основе 4 процессоров P-IV 2.8 НТ/800 мне не по карману, да и ставить некуда. Во-вторых, интеловский Фортран не поддерживает кластерные решения в "неродной" архитектуре, а "родная" на IА-64 стоит вообще столько, что я пойду по миру без штанов. В-третьих, узкое место кластера - его роутер, а хороший эксклюзивный роутер стоит тоже немало. И самый очевидный выход, таким образом - наращивать гигафлопы традиционным методом. Либо ждать, пока в 2005 станут доступны многоядерные пни. (Да потом еще ждать, когда под это дело напишут приличный фортран.)
С другой стороны, насчет разгона 3700+ я, пожалуй, погорячился. Там свое узкое место - конвейер памяти. Как ни гони такты, в памяти все будет застревать. В общем, все классические признаки революционной ситуации - низы не хотят, а верхи не могут.
Говорят, мощность кластера возрастает нелинейно. Так что можно набрать пачку 166-пней, слинковать их и без мониторов-клавиатур пустить. Правда с настройкой будет геморрой, да и проблемы раутера никто не отменял. Софт же... не знаю, как сейчас дела обстоят с этим на пиратском рынке, к сожалению. Гнать же процы - дело не слишком благодарное. У меня был забавный случай, когда я свой Р166 разогнал до 180. Он работал нормально, а потом что-то глюкнуло, и я решил его обратно открутить. И тут же все начало _так_ глючить, что хоть в петлю. Пришлось обратно частоту поднимать. В качестве добавчной детали можно упомянуть что кулер уже полгода как к тому моменту сдох - просто сгорел. Впрочем, для процов тех времен это было не столь витально.
Мощность МВК возрастает пропорционально количеству обрабатываемых одновременно вычислительных потоков в задаче. В советские времена я писал задачки для "Эльбруса"; распараллеливание процессов на программном уровне было самым жутким геморроем, несмотря на аппаратную поддержку.
В нынешних реализациях многозадачной архитектуры традиционно используется thread технология, которая при работе с чувствительными данными (да и в отладке) показывает себя не вполне стабильно. Реальное распараллеливание процессов, с организацией семафоров и процедур блокирования/разблокирования данных, особенно в виртуальных массивах емкостью более нескольких терабайт - задача не для моего ума. Я юзер, а не программер.
В данной же задаче мы, по сути, встречаемся с анализом 2-х последовательных потоков вычислительных данных. Даже при виртуозном программировании, распараллелить это более чем на 16 процессов ИМХО не представляется возможным. И главное спасение здесь - конвейер невперенной длины.
Что до разгона, я от него решительно отказался. Заранее.
Это традиционная проблема - программное распараллеливание. Особенно характерно она проявляется при писании эмуляторов многопроцессорной техники. Там крайне важна синхронность, а ее, к сожалению, в софтварно-мультитредном окружении не так уж легко добиться малой кровью.
А в управлении сложными разбиениями вычислений нельзя применить модульную технологию? То есть есть два процесса - считающий и управляющий с определнным рангом. Управляющий управляет своими рассчетами и еще парой управляющих процессов рангом пониже... И так далее. Тут не шестнадцать, тут два компа всего :)
А что, задача на куски совсем никак не разбивается? Т.е. чтобы не весь массив данных за один раз обрабатывать, а разбить на много кусков и последовательно обсчитывать. А если для обсчета следующего куска не требуются данные от предыдущего - то можно и параллельно и даже на разных компах.
Очень советую подумать над такой схемой, потому что иначе если комп сбойнёт на 14-м часу обсчёта - будет обидно :-). А так - обсчитал кусочек, данные сохранил, приступил к следующему :-)
Полностью согласен с 10chiken. Что даст разгон в плане увеличения производительности? Максимум 10-15%. Т.е. в идеальном случае будет у тебя программа считаться не 15 часов, а 13. И что, это тебя спасёт? :-) А риск спалить/сломать процессор ценой 600 баксов - достаточно большой. Причем разгон - это всегда негарантийный случай.
Жалко, конечно... в тетрис играться на разогнанной машинке всяко круче...
С другой стороны, спецы утверждают, что гораздо выгоднее просто перевести часть данных на SCSI устройства - это даст в моем случае почти двукратное ускорение.
![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
ninetydegrees
![[identity profile]](https://www.dreamwidth.org/img/silk/identity/openid.png){kind=small}
(no subject)
http://overclockers.ru/news/newsitem.shtml?category=2&id=1066685693
Ага, там появилось!
Хотя, увы, прочитал эту статью - и задумался. S754 явно изживает себя; память не справится с требованиями по скорости. Увы.
(no subject)
(no subject)
(no subject)
Кластер - в моем случае не метод.
С другой стороны, насчет разгона 3700+ я, пожалуй, погорячился. Там свое узкое место - конвейер памяти. Как ни гони такты, в памяти все будет застревать. В общем, все классические признаки революционной ситуации - низы не хотят, а верхи не могут.
Re: Кластер - в моем случае не метод.
Возрастание мощности в кластерных системах.
В нынешних реализациях многозадачной архитектуры традиционно используется thread технология, которая при работе с чувствительными данными (да и в отладке) показывает себя не вполне стабильно. Реальное распараллеливание процессов, с организацией семафоров и процедур блокирования/разблокирования данных, особенно в виртуальных массивах емкостью более нескольких терабайт - задача не для моего ума. Я юзер, а не программер.
В данной же задаче мы, по сути, встречаемся с анализом 2-х последовательных потоков вычислительных данных. Даже при виртуозном программировании, распараллелить это более чем на 16 процессов ИМХО не представляется возможным. И главное спасение здесь - конвейер невперенной длины.
Что до разгона, я от него решительно отказался. Заранее.
Re: Возрастание мощности в кластерных системах.
А в управлении сложными разбиениями вычислений нельзя применить модульную технологию? То есть есть два процесса - считающий и управляющий с определнным рангом. Управляющий управляет своими рассчетами и еще парой управляющих процессов рангом пониже... И так далее. Тут не шестнадцать, тут два компа всего :)
Re: Возрастание мощности в кластерных системах.
Очень советую подумать над такой схемой, потому что иначе если комп сбойнёт на 14-м часу обсчёта - будет обидно :-). А так - обсчитал кусочек, данные сохранил, приступил к следующему :-)
(no subject)
Ладно, на фиг разгонять!
С другой стороны, спецы утверждают, что гораздо выгоднее просто перевести часть данных на SCSI устройства - это даст в моем случае почти двукратное ускорение.
Всем спасибо!