Комплексный тест методов оптимизации численных расчетов в среде GNU/Linux

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

впечатляет >Т.о. в большинстве случаев есть смысл менять ядро с 2.4.x на 2.6.x; при yп этом ожидаемый прирост будет в пределах 1-2%. бред полный а в конце вроде совсем наоборот: >* Разница производительности на различных ядрах настолько мала, что я бы не стал рассматривать производительность как повод к смене ядра.

N-da... Krasnnoglaziki s Gentoo idite na [beep]...
Pro jadro xoro6o skazano. Pro gcc - a kak on na fone ifc&&icc,PathScale,PGI,Absoft'a smotritsja ? Otwe4u sam, neploxo, esli u4est` 4to on besplatiny! No esli est` den`gi i golowa na meste,ego dergat` tol`ko dla kernel nado ..
Karo4e zaipali eti testi ))))
Best wishes,$echo.
P.s. Debian Woody na Athlon2000+MP, 1.5GB RAM usaju i ni xo-xo. A Barton2600+ na slake s gcc saset pri4mokiwaja, potomu kak ego fanat GNU adminit)))) Bugaga

<quote>впечатляет >Т.о. в большинстве случаев есть смысл менять ядро с 2.4.x на 2.6.x; при yп этом ожидаемый прирост будет в пределах 1-2%. бред полный а в конце вроде совсем наоборот: >* Разница производительности на различных ядрах настолько мала, что я бы не стал рассматривать производительность как повод к смене ядра. </quote>

А если программа считается в течение 2х-3х суток? ИМХО в таком случае и за 2% надо бороться.

$echo, ну нафик так грубо-то? Расчеты-то конечно да, тут PGI и I[FC]C рулят, вот только всю систему собрать интеловскими компиляторами пока сложновато (а в генту кстати немного проще (: ). И вот тут-то GCC 3.3 (и 3.4 c -fweb - занятная штука) помогают.

А если денег мало и игрвться хочется?

P.S. С недавнего времени почти фанат gentoo и debian.

> я сделал вывод, что дебиану еще очень долеко до джэнту (имхо).

Мерили уже около года назад. Оказалось, что это женте далеко до дебиана. Причем не только до дебиана, но и до какой-то шапки. Жента может сделать рази что тормозилку Сюзю.

2-3 суток? А 3-4 недели не хотите ли? При этом на восьми нодах кластера?

С одной стороны конечно бороться стоит, с другой стороны разница ждать 504 часа или на 10 часов меньше разницы особой нет. (но это пока машинное время свое, не покупное и не продаваемое, естественно :))

Гонялась scimark2 С-версия. А есть еще и версия на Java. Вот бы еще и её погоняли :)

Prosto ja zloy s4a ... axuet` kakoy zloy .... nedelju uge s Opteronami w sado-mazo eroti4nom tance plja6u .... mljaaaaaaaaaa
est` Linux sobranniy icc... naziwaetsja Krasniy Flag {Chine}, no Intelowskie Developeri toge u4astwuet w etom .... subj net-) no poprobuy naguglit`

gcc-3.3 dlja linux`a[kernel]. Samiy to . Ja uge pro eto goworil.

Gentoo mne ne nrawitsja. I wse tut. Ja dowerjaju Debianowskim manteymeram) i beru ot nix debki i security patchi. Wremja to ne galko na sborku/peresborku ?

Ter' 4udikam ... pro 4asi s4eta ....
u menja s4a task legit - oceno4noe wremja s4eta ~15 sutok na Athlon2000+MP. Procenti[<10%] pogodi ne sdelajut . Potomu kak takie taski ne dlja PC. Libo cluster, libo inaja architectura. Ne ipet. Ja ne pioner 15 sutok gdat`. A teper` prikinem skol`ko ja wiigraju wigaw s koda ~40% na kadom uzle i zapustiw .. skagen na 14-ni procax ?)
Ladna ... dela
P.s. Pro6u izwinit` translit. Lapi ne doxodjat do IRIX rusifikacii -)
Best wishes,$echo.

http://www.redflag-linux.com/eindex.html

Народ! Давно пора аналитические методы развивать, чтобы не мудохаться с численными расчетами неделями и гробиться в поисках кластеров

2 sidanko (*) (29.10.2004 11:13:43)
Да-да, чувак, реши мне пожалуйста интегро-дифференциальное
уравнение с нетривиальной областью интегрирования!
А то я затрахался уже Алтарелли-Паризи численно считать:)
Куча физиков тебе большое человеческое спасибо скажет:)

Да я бы рад решить, если бы знал как ;) я и говорю - тут думать надо!!! а то считаешь на машине так с неделю, а там баг в проге, а потом ходишь и думаешь - реальный ответ получил или нет. Хорошо если листинг кода маленький, проверить можно, а бывает 20 тыс. строк кода ...

ИМХО

Номальные пацаны уже давно пользуются формализмом Вильсоновской


ренормализационной группы

2 sidanko (*) (29.10.2004 11:29:24)
Это история моей жизни:)
Одни тестовые прогоны минут по 10-20 занимают,
тут блин не только LOR, но и весь anekdot.ru заботаешь.
После таких развлечений можно стать профессионалом
по впариванию любых результатов.

2 Sun-ch

Я бы уточнил, не Вильсоновским методом ренормгрупп, а методом ренормгрупп с матрицей плотности (DMRG), разработанный Вайтом и Ноаком.

Саныч, ты че несешь?!
Ренормгруппу Боголюбов разрабатывал!
А Вильсон операторное разложение на световом конусе ввел
в ГНП-процессы, потому коэффициенты и называются вильсоновскими.

Алтарелли-Паризи как раз и есть следствие ренормгрупповых
уравнений. И решать его можно 2 способами
1) brute force -- медленно, но верно
2) в пространстве моментов Меллина -- быстро но муторно

2 ivon

Жизнь, к сожалению, слишком коротка, чтобы заниматься прогонами ...

ИМХО

В формализме Вильсоновской ренормализационной группы можно дать вывод

уравнения эволюции Алтарелли-Паризи

2 Sun-ch (*) (29.10.2004 12:06:49)
короче, я тебя понял. Не знаю, где ты вычитал, что
ренормгруппа Вильсоновская -- скорее всего, в импортной
литературе. Я не поленился слазить в учебник Индурайна:
ренормгруппу ввели Штюкельберг и Петерман. Далее были
статьи Гелл-Манна-Лоу, а уже в следующем году Боголюбов&Ширков
выпустили более общую статью и далее серию статей (смотри их же).
Классическая книжка Коллинза "перенормировки" тоже указывает
сразу на Штюкельберга и потом Боголюбова.

Все это фигня конечно, но ты меня заинтриговал, я уж думал,
у меня крыша едет :)

-O3 -march=athlon-tbird -mcpu=athlon-tbird -fomit-frame-pointer \ 
                   ^^^^^^^^^^^^
fforce-addr -falign-functions=4 -funroll-loops \ 
-maccumulate-outgoing-args -msse
                                              ^^^^^^

Забавная комбинация флагов ;)

Понятно что человек это дело пущал на XP но все-же

ss@k7-raid:~$ cat /proc/cpuinfo
processor       : 0
vendor_id       : AuthenticAMD
cpu family      : 6
model           : 4
model name      : AMD Athlon(tm) Processor
stepping        : 2
cpu MHz         : 1000.054
cache size      : 256 KB
fdiv_bug        : no
hlt_bug         : no
f00f_bug        : no
coma_bug        : no
fpu             : yes
fpu_exception   : yes
cpuid level     : 1
wp              : yes
flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 mmx fxsr syscall mmxext 3dnowext 3dnow
bogomips        : 1992.29

 никак не ...

 ss@XP1700:~$ cat /proc/cpuinfo
processor       : 0
vendor_id       : AuthenticAMD
cpu family      : 6
model           : 6
model name      : AMD Athlon(tm) XP 1700+
stepping        : 2
cpu MHz         : 1468.502
cache size      : 256 KB
fdiv_bug        : no
hlt_bug         : no
f00f_bug        : no
coma_bug        : no
fpu             : yes
fpu_exception   : yes
cpuid level     : 1
wp              : yes
flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 mmx fxsr sse syscall mp mmxext 3dnowext 3dnow
bogomips        : 2929.45

Автор работы - А.В. Леонидов из ФИАНа

>2-3 суток? А 3-4 недели не хотите ли? При этом на восьми нодах кластера?

и сколько у него Rmax по HPL ?

PS: и первая и вторая цифры вполне реальные - задачи то бывают разные ...

Насчёт оптимизации g77. Никто ею не будет заниматься. В GCC 3.5 уже будет компилятор g95. В принципе, он уже работает у меня дома. Я таак понимаю, сейчас все силы брошены туда.

Отличный, грамотный отчёт. Высококлассная работа.

>Wremja to ne galko na sborku/peresborku ?

Неа, не жалко. Пока сделано так, что центральная нода с раидом в расчетах не участвует (остальные ноды безхардовые). К тому же при перекомпиляции ccache очень помогает, ну и не компилирую же я каждый день kde!

>вот только всю систему собрать интеловскими компиляторами пока сложновато

да и нафик не надо...;)) ИМХО

ну как грят многие те у кого расчёты сутками работают, ICC использовать нельзя... т.к. в результате получается совсем уж, что-то приблизительное..... в общем либо чситаем быстро, либо точно..;) физикам-математикам-инженерам уж никак низя юзать интеловский компайлер... нах..;)) не совсем моё ИМХО... это ИМХО более компетентных народаф чем я..;)

>Отличный, грамотный отчёт. Высококлассная работа. Только стрёмно как-то fast-math для численных рассчётов ставить, если точность большая нужна.

Раз уж дебиан, надо было libc6-i686 тоже потестировать...

>Только стрёмно как-то fast-math для численных рассчётов ставить, если точность большая нужна.

Эта опция влияет не на точность а на то что fp-трапы не дает обработать на уровне юзера ... ну и еще состояние FPU не сохраняет (если используется низкоуровневая FP библотека, закладывающаяся на соблюдение IEEE то могут быть косяки)

Если уж говорить про точность то тут могут быть вопросы про использование -msse -mfpmath=sse для Athlon-ов, которые, как извстно умеют SSE только с float

HPL не гонял, надо ради интереса запустить, когда нагрузки особой не будет. Но сразу скажу - это так, "кластер" ислючительно для внутренних задач, "пионерская поделка" как тут говорят, ни на что особо не претендущая.

А про задачи - ну конечно разные бывают, просто я хотел сказать о своих реальных цифрах, и всё.

Вот я собирал mplayer icc под PIII, так оно побыстрее работало, чем с gcc (2.95 кажется, точно не помню).

Когда русский настроишь, злыдня? ;)

Доброго времени суток.
PathScale 1.4 не пробовали ? Сегодня сразу на грабли напоролся [туда и отписал в саппорт] ... EM64T поверх ifc && icc восьмерки не юзали? там гибко можно режимы прописывать ... [small|medium|large] {аналог в PathScale -mcmodel=small|meduim} ? хех ... пиво хочу.
Best wishes,$echo.

Как только снег пойдет, так сразу ... зима-холода скажут нет обострению)
Best wishes,$echo.

Саныч! Сам-то понял, чего сказал?

Паронормальный Балтуновский-Вильсоновский :)))

>PathScale 1.4 не пробовали ?

Не ... руки не доходят

Да ... даже EM64T от Интела ?
ЗЫ Оптероны у Вас поболее в пользовании, чем у меня
а с gcc он совместим ... проверяно )
подвыпитый уже ... но не злой -)
И еще Вы ассемблерный код gcc изучали на предмет Оптеронов ?-)
Появлюсь в понедельник .... наверное будет загул такой мягкий и не напряжный ... на несколько суток )
Best wishes,$echo.

А того анонимуса что в свое время в Девелопер форуме сказал про моветон насчет PathScale я бы битой уипал .... лично .. отзавись друг мой ласковый .....

>Да ... даже EM64T от Интела ?

А на интел я ХЗ скоко времени уже не ходил :)

У меня еще наверное за полгода анонсов от интелей и от PathScale в почтовом ящике валяется ... HPC это не только чтение спеков но и окучивание и удобрение заказчика ;) Как пробьем новый грант - будет время и в коде порыться :)

>Давно пора аналитические методы развивать

Аналитические методы далеко не везде рулят... Вот, например, задача одномерной теплопроводности решена аналитически, только в решении есть хорошая функия erfc() --- ее вычисление это опять численный метод. Да даже кубический корень вычисляется численным методом.

> Раз уж дебиан, надо было libc6-i686 тоже потестировать... После публикации было проверены доп. факторы: 1) Наличие\отсутсвие libc6-i686 2) Сборка g++ или gcc для С тестов (дело в том что 2 из 3 реальных С-теста были написаны на C++; поэтому прверялся только один реальный тест и scimark2) 3) Динамически\статически слинковано.

Все три вышеперечисленных фактора -- в пределах погрешнсоти. Поэтому и решил не дописывать статью.

-- Юревич Юрий