?

Log in

No account? Create an account
КОЛОКОЛА ГРОМКОГО БОЯ
("КГБ")
Оффтопик 
16th-Nov-2004 07:35 pm
редакторская колонка
Народ! Кто-нибудь может подсказать ссылочку на сайт или руководство, как можно разогнать Athlon 64 3700+?
Комментарии 
16th-Nov-2004 05:50 am (UTC)
Разгон 3200+, подробно не смотрел, но думаю, идея тут есть. Ну и еще куча всякой фигни типа тестов тут же.
http://overclockers.ru/news/newsitem.shtml?category=2&id=1066685693
16th-Nov-2004 07:30 am (UTC) - Ага, там появилось!
А то я там только про Alhlon XP 32-разрядный нашел. Спасибо.

Хотя, увы, прочитал эту статью - и задумался. S754 явно изживает себя; память не справится с требованиями по скорости. Увы.
16th-Nov-2004 08:01 am (UTC)
А зачем? Ты что, занимаешься моделированием физ.процессов или другими задачами, требующими аналогичной производительности процессора?
16th-Nov-2004 09:34 am (UTC)
Нет, но собираюсь, возможно, подключиться к работе по моделированию генома, а включать в список своих мытарств еще и ВЦ СО РАМН или ВЦ в Кольцово - желания не имею...
16th-Nov-2004 09:34 pm (UTC)
Тебя спасет кластер. А разгон процов всегда был занятием довольно рискованным. Кластер же для рассчетов - самое то.
16th-Nov-2004 09:53 pm (UTC) - Кластер - в моем случае не метод.
Во-первых, даже самый примитивный кластер Beowulf-класса на основе 4 процессоров P-IV 2.8 НТ/800 мне не по карману, да и ставить некуда. Во-вторых, интеловский Фортран не поддерживает кластерные решения в "неродной" архитектуре, а "родная" на IА-64 стоит вообще столько, что я пойду по миру без штанов. В-третьих, узкое место кластера - его роутер, а хороший эксклюзивный роутер стоит тоже немало. И самый очевидный выход, таким образом - наращивать гигафлопы традиционным методом. Либо ждать, пока в 2005 станут доступны многоядерные пни. (Да потом еще ждать, когда под это дело напишут приличный фортран.)

С другой стороны, насчет разгона 3700+ я, пожалуй, погорячился. Там свое узкое место - конвейер памяти. Как ни гони такты, в памяти все будет застревать. В общем, все классические признаки революционной ситуации - низы не хотят, а верхи не могут.
16th-Nov-2004 10:07 pm (UTC) - Re: Кластер - в моем случае не метод.
Говорят, мощность кластера возрастает нелинейно. Так что можно набрать пачку 166-пней, слинковать их и без мониторов-клавиатур пустить. Правда с настройкой будет геморрой, да и проблемы раутера никто не отменял. Софт же... не знаю, как сейчас дела обстоят с этим на пиратском рынке, к сожалению. Гнать же процы - дело не слишком благодарное. У меня был забавный случай, когда я свой Р166 разогнал до 180. Он работал нормально, а потом что-то глюкнуло, и я решил его обратно открутить. И тут же все начало _так_ глючить, что хоть в петлю. Пришлось обратно частоту поднимать. В качестве добавчной детали можно упомянуть что кулер уже полгода как к тому моменту сдох - просто сгорел. Впрочем, для процов тех времен это было не столь витально.
16th-Nov-2004 10:29 pm (UTC) - Возрастание мощности в кластерных системах.
Мощность МВК возрастает пропорционально количеству обрабатываемых одновременно вычислительных потоков в задаче. В советские времена я писал задачки для "Эльбруса"; распараллеливание процессов на программном уровне было самым жутким геморроем, несмотря на аппаратную поддержку.

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

В данной же задаче мы, по сути, встречаемся с анализом 2-х последовательных потоков вычислительных данных. Даже при виртуозном программировании, распараллелить это более чем на 16 процессов ИМХО не представляется возможным. И главное спасение здесь - конвейер невперенной длины.

Что до разгона, я от него решительно отказался. Заранее.
16th-Nov-2004 10:49 pm (UTC) - Re: Возрастание мощности в кластерных системах.
Это традиционная проблема - программное распараллеливание. Особенно характерно она проявляется при писании эмуляторов многопроцессорной техники. Там крайне важна синхронность, а ее, к сожалению, в софтварно-мультитредном окружении не так уж легко добиться малой кровью.

А в управлении сложными разбиениями вычислений нельзя применить модульную технологию? То есть есть два процесса - считающий и управляющий с определнным рангом. Управляющий управляет своими рассчетами и еще парой управляющих процессов рангом пониже... И так далее. Тут не шестнадцать, тут два компа всего :)
16th-Nov-2004 11:02 pm (UTC) - Re: Возрастание мощности в кластерных системах.
А что, задача на куски совсем никак не разбивается? Т.е. чтобы не весь массив данных за один раз обрабатывать, а разбить на много кусков и последовательно обсчитывать. А если для обсчета следующего куска не требуются данные от предыдущего - то можно и параллельно и даже на разных компах.

Очень советую подумать над такой схемой, потому что иначе если комп сбойнёт на 14-м часу обсчёта - будет обидно :-). А так - обсчитал кусочек, данные сохранил, приступил к следующему :-)
16th-Nov-2004 09:55 pm (UTC)
Полностью согласен с 10chiken. Что даст разгон в плане увеличения производительности? Максимум 10-15%. Т.е. в идеальном случае будет у тебя программа считаться не 15 часов, а 13. И что, это тебя спасёт? :-) А риск спалить/сломать процессор ценой 600 баксов - достаточно большой. Причем разгон - это всегда негарантийный случай.
16th-Nov-2004 10:03 pm (UTC) - Ладно, на фиг разгонять!
Жалко, конечно... в тетрис играться на разогнанной машинке всяко круче...

С другой стороны, спецы утверждают, что гораздо выгоднее просто перевести часть данных на SCSI устройства - это даст в моем случае почти двукратное ускорение.

Всем спасибо!
Выпуск подгружен %mon%