Потихоньку пробую C# (mono-project)... Одно могу сказать - "Hello world" с классом gtk-sharp кимпилировалось около 30 секунд на Pentium4. Не бог весть что...

так он же свеженький совсем, врядли у них скорость на первом месте сейчас

Блин, зацените, какой у этого мужика срач на столе! И можно ему после этого доверять?

у него пузырь там на столе! он пьяный мерил!

> так он же свеженький совсем, врядли у них скорость на первом месте сейчас

Ну да, в приоритетах у них целый огород - http://www.mono-project.com/contributing/todo.html. Как минимум год еще уйдёт на переоценку ценностей у ребят их Ximian(Novell), до тех пор пока они не вольют в этот перспективный проект больше толковых программистов...

Результатец явно в целом не в пользу gcc. Если на целочисленных операциях gcc где-то и быстрее icc, причём тут явно gcc 3.4.3 лучший, то на плавучке icc делает gcc. Впрочем альфа gcc 4.0 тут предпочтительнее gcc 3.4.3 и где-то приближается к icc. Мало того, оптероны на математике слили пню. А ведь gcc чуть ли не единственный компилятор для Opteron.

Это не срач, это творческий беспорядок :)

> Мало того, оптероны на математике слили пню.

"This article is not a comparison of the Pentium 4 and Opteron processors; my test systems are far too different for any such comparison to have meaning."

> too different

Угу. Dual Opteron vs Pentium IV. Впрочем, похоже для тестовых задач многопроцессорность не использовалась. Кстати, зря он не стал icc использовать на Opteron'е. Конечно, код был бы 32 битным, но всё равно было бы любопытно сравнить, поскольку как я помню для 32 - битных атлонов icc генерит код весьма хороший, во всяком случае, сравнение P-III 1000 Мгц против равночастотного Athlon TB на математике скомпилированной именно icc, показывало победу именно атлона. Была тогда даже шутка, что интелу стоило бы забросить процессоры и делать то, что у него хорошо получается -- компиляторы.

>В общем же, gcc еще есть куда расти: на интеловском P-4 icc все еще обгоняет gcc практически во всех бенчмарках, но особенно сильно в расчетных задачах.

ИМХО компиляция с оптимизацией очень полезна для супер-компьютеров и вычислительных центров

Дон собирает пакеты в своем несравненном Gentoo Linux с ключиками -O0?
"Очень полезна" мягко сказано, необходима. Ведь суперкомпьютеры и ВЦ создаются не для перекомпилляции ядра и сборки Gentoo из сырцов ....

> ИМХО компиляция с оптимизацией очень полезна для супер-компьютеров и вычислительных центров

Это вы к чему сказали? :)

К тому, что в других целях оптимизация вовсе незачем, т.к. ощутимой разницы и прироста в производительности труда на workstation-ах и desktop-ах (тем более) не будет видно.

А что такое workstation в вашем понимании?

Вот POV-Ray например - чем не приложение для рабочих станций?

Да и из остальных 6 тестов как минимум 2 (huff & tree) не имеют отношения к HPC.

Workstation, в моём понимании - мощный компьютер с хорошо продуманной архитектурой, с гигами рам, с мощным процессором (может и несколькими), мощной видеокартой. Применять такой можно, например, в задачах, где есть очень жадные требования к графике, для программирования и разработки больших проектов и т.д. Я конечно не спец., не судите строго :) Всё-таки, наверное, и workstation-у не помешает оптимизация.

А вам приходилось работать с POV-Ray?

Кстати, когда у меня была джента, оптимизированная очень простыми флагами, графика и большие pdf-ки (например карта города - http://www.narvaplan.ee/Linnakaart.pdf) у меня очень тормозила на моём 256 ram, pentium4, geforce2. Однако, на неоптимизированном Debian-е, всё загружается намного быстрее и в целом не тормозит систему.

> Однако, на неоптимизированном Debian-е, всё загружается намного быстрее и в целом не тормозит систему.

Действительно странно - с чего бы это простое и незамысловатое "-O3" оптимизирует хуже, чем всё сообщество Debian? :)

Вообще-то это был -O2 и судя по тормозам, использовалось очень много памяти при просмотре pdf-ки.

было бы интересно еще глянуть на атлоны, нецелочисленную математику на них считают.. или просто 32битные тесты на тех же оптеронах хотя бы, с icc

а ром у него хороший ..... сам вчера такой пил =)

Зато слева на столе наблюдается "A New Kind of Science" Вольфрама - риспект!

у icc одна из сильных сторон это оптимизация вычислительных задач... и вряд-ли кто-нить сможет перепрыгнуть его в этом...

про g++ -O3

Вообще-то, g++-3.3 -O3 генерит довольно-таки отстойный (с точки зрения производительности), а частенько -- и вовсе некорректный код. Потому в README к всякого рода числодробильным библиотекам (CLN, blitz++, TNT) авторы писали "НЕ пользуйте -O3, а пользуете -- не жалуйтесь, что тормозит и/или глючит". (Поэтому, кстати, бинарники, собранные RH или Debian работают шустрее, чем то, что наклепают пЫонеры -- любители самосбора).

С g++-3.4 ситуация стала получше -- теперь с -O3 можно получить корректно работающий код, но производительность все равно ниже, чем -O2 -куча-хитро-подобранных-ключей (которые разрешают _некоторые_ из оптимизаций из -O3).

А какие флаги лучше указывать для сборки програм с расчетом на производительность? Проц Селерон 2,4 (на основе пня4), дистр фк2.

> Потому в README к всякого рода числодробильным библиотекам (CLN, blitz++, TNT) авторы писали "НЕ пользуйте -O3, а пользуете -- не жалуйтесь, что тормозит и/или глючит".

Кстати, gentoo team, насколько я помню, тоже не рекомендуют пользоваться -O3, и многие ebuild'ы его просто режут.

>Это не срач, это творческий беспорядок :)

Угу, у моих знакомых программеров(да и уменя), ещё хуже....

>Была тогда даже шутка, что интелу стоило бы забросить процессоры и делать то, что у него хорошо получается -- компиляторы.

:-))))))))))))))))))))))))))))

А кто-нибудь пробовал этим icc что-нибудь общеполезное собрать, типа mplayer/mencoder? Там было бы реально интересно сравнить производительность. Опять же, почему не сравнили с референс-веткой 2.95? Понятно, что 32 бита. но ветки 2.96-3.2.X тормозили по сравнению с 2.95 нипадеццки, как минимум на тестах mplayer'a. Понятно, что 3.4 - быстрее, чем 3.2, но быстрее ли оно чем 2.95, это еще вопрос.

> А какие флаги лучше указывать для сборки програм с расчетом на производительность?

Во-первых, надо писать код более-менее вдумчиво, а не надеятся, что комплилятор сделает из г... конфетку.

Во-вторых, нужная оптимизиция очень сильно зависит от задачи и используемых библиотек. Подбирается, как правило, методом научного тыка :(.

P.S.

// тупой код

// компилятор, в принципе, должен избавиться от цикла

double A[256];

double B[256];

// чего-нибудь запишем в A и B

double result(0.0);

for(int i=0; i<256; i++) result += A[i]*B[i];

// ...но жизнь -- не сказка. Поэтому хитрим:

template<int N> inline double meta_dot(double* a, double* b) {

return meta_dot<N-1>(a,b) + a[N]*b[N];

}

template<> inline double meta_dot<0>(double* a, double* b) {

return a[0]+b[0];

}

const int sz=256;

double A[sz]; double B[sz];

// чего-нибудь запишем в A и B

double result = meta_dot<sz>(A,B);

// если при сборать так:

// g++ -O2 -finline-functions -finline-limit=1500 blah-blah

// то цикла в коде НЕ будет.

> А кто-нибудь пробовал этим icc что-нибудь общеполезное собрать, типа mplayer/mencoder?

Пожалуй, это общебесполезное :) Кроме того, gcc'-измов в нем полно...

> Опять же, почему не сравнили с референс-веткой 2.95?

Мало того, что оно с STL не дружит, дак еще и тормозной код генерит...

> но ветки 2.96-3.2.X тормозили по сравнению с 2.95 нипадеццки

Тормозило ЧТО?

> как минимум на тестах mplayer'a

Это шаманство теперь назывется тестами? С каких пор?

расскажите, чем плох цикл? И что делать, если в процессе обнаружилось, что sz должен быть раз в дцать больше?

Поэтому автор статьи и acovea обещает реализовать в acovea сборку определённых программ по той же схеме подборки флагов. Только неизвестно сколько будет сборка идти :)))

>> но ветки 2.96-3.2.X тормозили по сравнению с 2.95 нипадеццки
>Тормозило ЧТО?

MPlayer/MEncoder, вестимо.

>> как минимум на тестах mplayer'a
>Это шаманство теперь назывется тестами? С каких пор?

Для меня на домашней тачке это актуальный тест. Другими вычислениями я на ней не занимаюсь. А что?

2Dselect:

>> то цикла в коде НЕ будет.

Но не факт, что такой развернутый цикл будет быстрее.
Есть ведь еще кэш кода (или trace-кэш у четвертого пня) и
если критические части кода из этого кэша часто вываливаются, то
скорость будет черепашья.

чем плох цикл

> расскажите, чем плох цикл?

Производительностью. Потому любой более-менее нормальный компилятор пытается избавиться от циклов (там, где это возможно, и где это разумно) -- например, странслировать его в какую-нибудь инструкцию FPU, или просто записать в явном виде. Если интересно, попробуйте сами поиграться, скажем, с перемножением векторов -- посмотрите разницу.

> И что делать, если в процессе обнаружилось, что sz должен быть раз в дцать больше?

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

> Но не факт, что такой развернутый цикл будет быстрее. Есть ведь еще кэш кода (или trace-кэш у четвертого пня) и если критические части кода из этого кэша часто вываливаются, то скорость будет черепашья.

Поэтому важно правильно отгадать -finline-limit=NNNN :)

2Dselect:

>> Поэтому важно правильно отгадать -finline-limit=NNNN :)

Поэтому следует написать простой цикл развернутый этак на 4 или,
еще лучше, на 8 с использованием SSE2, и не заморачиваться с шаблонами.
Кажется, в gcc 3.4.x появилась поддержка SSE2 интринзиков, а в icc она
уже давно, так что можно даже обойтись без ассемблера.
И работать будет с любой длиной вектора, если обработку хвоста добавить.

и чего я, буду на asm'-е лабать?

> Поэтому следует написать простой цикл развернутый этак на 4 или, еще лучше, на 8 с использованием SSE2, и не заморачиваться с шаблонами.

Таки лучше написать шаблон, и подобрать -flimit-inline, и не учить asm той-хрени-на-которой-завтра-придется-работать. Пусть с ним авторы GSL парятся :).

> И работать будет с любой длиной вектора, если обработку хвоста добавить.

А это не нужно было. Хвала Богам, число уравнений -- величина отностительно постоянная :)

> Кажется, в gcc 3.4.x появилась поддержка SSE2 интринзиков,

Меня не очень-то тянет стать бета-тестером...

да, еще по icc вопрос...

> а в icc она уже давно, так что можно даже обойтись без ассемблера.

А он уже научился не терять точность при работе с double? (если да, то какое заклятье нужно?)

Мнда... Интеловские компилеры, это, конечно, клево, но на численных задачах и они иногда выдают даже с -O2 какой-то бред. А с -O0 - все вроде работает... (Обнаружено на ихнем fortran-е, к сожалению, прога была на 90-м, так что с g77 сравнить не удалось)

> а в icc она уже давно

Кстати icc вроде бы должен такой цикл и сам векторизовать в SSE2.

то я ж и спрашиваю

> Интеловские компилеры, это, конечно, клево, но на численных задачах и они иногда выдают даже с -O2 какой-то бред.

Зато быстро :)

> А с -O0 - все вроде работает...

Аналогично. (g++'-ный код с -O2 -finline-functions -finline-limit=1000 -march=pentium4 работает раза в два быстрее, и дает правильный ответ).

> (Обнаружено на ихнем fortran-е, к сожалению, прога была на 90-м, так что с g77 сравнить не удалось)

За FORTRAN не знаю: благо, мне этот отстой не приходится пользовать. Но вот у icc такой глюк (фичу?) я наблюдал...

Ну вот, gcc опять проиграл :(( Хотя я рад, что новые версии становятся все лучше и лучше &mdash; прогресс!! :-)