>Кстати, кэй демы больше не выставляет?
Выставляет.

Ну, одна ссылочка прямо в заголовке этого треда есть, другую щаз дам:

http://ontil.ihep.su/~vsl/nbench-alpha600-gnuc.txt

http://ontil.ihep.su/~vsl/nbench-alpha600-decc.txt

Англоговорящему анонимусу: Я и говорю, что политика Intel по отношению к компиляторам более чем странная. Зачем выводить ICC на линукс, когда там уже есть kai, который стоит столько же, гораздо качественнее, и при этом принадлежит _им_же. Я не вижу в этом никакой логики кроме подковерных разборок в интеле. Может, они хотят затащить на линукс свой кодогенератор, который в отличие от kai умеет mmx/sse, может, хотят в будущем скрестить "оптимизатор" kai и свой кодогенератор, может, две разные команды соревнуются... Резюме -- "внешней" логике вывод этого компилятора не поддается -- смысла в нем очевидно нет.

Компилятор, юзающий SIMD-ы, на задачах, этого требующих, может и вовсе в разы/на порядки уделать компилятор, про SIMD-ы не знающий.

Кстати, Antichrist, расскажи, как это компилятор _C++_ может заюзать SIMD? Правда, интересно. Как он срюхнет, когда нужны соответствующие инструкции? Автоматом проанализирует циклы по массиву и разложит его по регистрам? Он же не знает ничего ни про векторы, ни про матрицы? Или SIMD будет использоваться в его реализации stl?

Не надо гнать. Гнать не надо. KAI существует только под одну платформу - x86, так что ни фига он не портабельный.

Хоть ты, Antichrist, и грамотный человек, но http://developer.intel.com/software/products/kcc/platforms.htm тебе рекомендую. Почитай на досуге.

Судя по всему - какой-то вумный анализ. Раскладывает dataflow в пределах функции, сортирует по независимым блокам, ищет похожие операции над разными данными - и сливает в одну SIMD. Я бы так сделал...

Thanx. Заврался я. Не нашёл демку для спарка - и обиделся зело :(

2ZhekaSmith: Ты туп, уж извини, но это факт.
"не умеющий читать по английски"
Почему-то для слащдота это нормально http://slashdot.org/developers/02/01/26/1328215.shtml
А для тебя нет. И я даже знаю почему :) Потому что ты относишся к этому как к своей личной обиде, что доказывает твой уровень развития.
"не умеющий ... писать по русски"
Уж кто-бы говорил... По-русски, по-английски пишется именно так, марш в школу, в пятый класс, до учиватся.
"Кстати, в VC есть куски кода интеловского компилятора"
И? А gcc инженеры от интеля тоже затачивали, чтоб он уж совсем отстойным не был...

KAI только под x86???

Ой, со зла це, ой со зла... Собственно, под x86-то как раз и промашка у них есть -- нет win32 версии. Потому и связались с Интелом.

Вчепятление: KAI правильнее во всех отношениях, но Intel -- очень-очень хорош. Хотя иногда-таки дерьмо лепит (типа Internal Compiler Error), но довольно редко и есть надежда на улучшение.

Даблин. Не ожидал даже... Зацените, товарисчи:

http://ontil.ihep.su/~vsl/nbench-pIII-800-gcc.txt

http://ontil.ihep.su/~vsl/nbench-pIII-800-icc.txt

А где чайнику найти хорошие доки (желательно хотя бы часть на русском) про компиляцию программ под Линукс. Для меня опции gcc - это темный лес. О2 или О10 не о чем не говорят.

а вот на Мипсы все болт положили :(, гады...

Вот и я говорю, нет кэя под МИПС-ы 32-р... ИСА-2... :( сиротааааа яяя... так и придётся гнуться (и они тоже положили :)), да на ассемблёре ручками разгребать... (мать... мать... мать... привычно отозвалось эхо:))

asoneofus, хотите решение? Переходите на другую платформу, и не мучайтесь:)

btw, кто там длинные строчки параметров gcc приводил, -mprentium != -march=pentium, второй вариант правильнее

To Antichrist (*) (2002-01-28 23:49:16.0):

Н-да, впечатляет.

Быстрые опции GCC

2Старый пионэр: >> та же хрень. Вот так строка для gcc выглядит в последней инкарнации: >> -O20 -mpentiumpro -funroll-loops -fomit-frame-pointer -ffast-math -malign-jumps=2 -malign-loops=2

Неправильно это, тут уже написали, к тому же другие -malign могут все тормознуть (сам не раз убеждался в этом), и так, попробуй (если не влом) следующую строку и только ее: -O20 -march=pentiumpro -fomit-frame-pointer -ffast-math

>> По размеру делает icc в те же 3 раза, по скорости - примерно на ~15% (мне лично скорость более интересна, бо задача практически переборная).

По поводу размера: ты strip сделал??? strip <имя бинарника>

Ogr "не умеющий ... писать по русски" Уж кто-бы говорил... По-русски, по-английски пишется именно так, марш в школу, в пятый класс,

***до учиватся.***

;)

А для K7 какой он код делает?.

Господа! Какое качество кода у интеловского компилятора при оптимизации под K7 (Athlon)?
Если никакое - то нам такого "добра" задаром не нужно.

To Antichrist (*) (2002-01-28 23:49:16.0) >

Сравнения несколько, по-моему, некорректны.
У тебя для компиляции используется gcc-2.96, а вот для альфы ты юзал 2.95 ...
Однако известно, что 2.96 - сакс, который оптимизацию производит только по известным только инженерам RedHat правилам. К примеру такая библиотека как ATLAS (Automatically Tuned Linear Algebra Software)(релизация BLAS) с 2.96-м на Intel'е даёт ужасные результаты (правда на Alpha - все ок).

P.S. Несколько offtopic: Сейчас как раз занимаюсь сравнением Portland Group и GNU компайлеров. Сравниваю на LINPACK'е (точнее ScaLAPACK'е) и мерю мелкий кластер из 2-х проц. P3-1000. Так вот, gcc+g77+g++ почти всегда либо делает ЛУЧШЕ, либо так же, как и Portland Group. Вот вам и коммерческий компилятор...

Специально для людей верующих в крутизну GCC. Только сейчас снял цифирки... платформа - Sun UltraSparcIIi 360Mhz, Solaris 8 Прога - стандартный тест FLOPS gcc - GNU CC cc - CC из Sun WorkShop gcc -DUNIX flops.c -O3 -o flops.gcc cc -DUNIX flops.c -xO5 -o flops.cc ./flops.gcc

FLOPS C Program (Double Precision), V2.0 18 Dec 1992

Module Error RunTime MFLOPS (usec) 1 2.8422e-14 0.1541 90.8722 2 2.5047e-13 0.0605 115.6129 3 -7.6605e-15 0.1450 117.2414 4 2.2771e-13 0.1661 90.3104 5 3.8858e-14 0.2418 119.9354 6 7.5495e-15 0.1845 157.2215 7 -1.1369e-13 0.2871 41.7959 8 1.2612e-13 0.2088 143.7126

Iterations = 128000000 NullTime (usec) = 0.0030 MFLOPS(1) = 116.1403 MFLOPS(2) = 74.5155 MFLOPS(3) = 105.2430 MFLOPS(4) = 129.2069 /flops.cc

FLOPS C Program (Double Precision), V2.0 18 Dec 1992

Module Error RunTime MFLOPS (usec) 1 -7.6739e-13 0.0664 210.6996 2 -5.7021e-13 0.0515 135.9636 3 -2.4314e-14 0.0492 345.6712 4 6.8501e-14 0.0464 323.2323 5 -1.6320e-14 0.1466 197.7624 6 1.3961e-13 0.1104 262.7965 7 -3.6152e-11 0.1994 60.1881 8 9.0483e-15 0.1255 239.1034

Iterations = 256000000 NullTime (usec) = 0.0000 MFLOPS(1) = 169.6012 MFLOPS(2) = 124.9462 MFLOPS(3) = 196.2716 MFLOPS(4) = 274.5875 Смотрим преимущество в процентах над GCC MFLOPS(1)= 46% MFLOPS(2)= 68% MFLOPS(3)= 87% MFLOPS(4)= 113% То есть минимальное преимущество - 46%, максимальное - 113%.

BTW: Так он (Intel) как выяснилось еще и OpenMP умеет *8) !!!!

Кто нибудь сравнивал его в оном на SMP с Portland ?

2Kirill: А что твой тест юзает ? MPI ? OpenMP ?

Насколько я знаю Portland хорош для SMP+OpenMP а на "плоском" коде он проигрывает gcc PS: ... для кластера все сложнее ...

/SS

2saper: да, был сделан strip -R .comment -R .note

Для полноты жизни еще отломал KAI C++ 4.0f for RedHat(e) 7.1
(вот тут лежит: http://developer.intel.com/software/products/downloads/KCC-4.0f3-i386-7.1.htm)

kfront (size 2847600)
Offset 2ad2e8, меняем первый 0 из 00 00 00 00 a0 a8 20 08 на 1
kfront-thin (size 1775660)
Offset 1ac888, меняем первый 0 из 00 00 00 00 84 5b 16 08 на 1

Есть подозрение что и под все остальные платформы весь FlexLM 7 отламывается исправлением одного бита, но мне смотреть ломы. Да и надо ли оно кому ?

Старый пионэр

2AffreuxChien:
а шо, разве все пингвинофилы сидят исключит-но на камнях от AMD ? "Вам" могет это добро и не надо, а другим будет крайне полезно
ЗЫ: оптимизации для AMD at least в опциях icc не замечено ни разу

Старый пионэр

To SS:

Я компилил ScaLAPACK под MPI причем без какого-либо использвоания SMP (а оно возможно, но МЕДЛЕННЕ для обоих компиляторов, чем обмен между процессорами через сетевой адаптер). НО! задача очень сильно грузит процессоры (решение систем линейных уравнений) и я, честно говоря, не понимаю почему pgi тут работает не быстрее GNU.

.... из малоприятного наблюдается несовместимость STL от gcc и icc :(

2Kirill: А я вот не представляю как можно соптимизироваить код - написанный под MPI когда там уже все разложено _руками_ ... там же вся синхронизация фактически выполняется вручную ...

BTW: А как был сделан вывод о более медленном исполнении в SMP ? Или я чего не понял насчет железяки ? У тебя N узлов по 2xPIII ? Я правильно понял ?

/SS

У нас в конторе делали евалюейшн Intela на ~30 разных машин на вычислительном софте под Вынь в сравнении с MSVC. Прикольно, что было как относительное ускорение до 35% так и замедление до 10%. Машины не самые старые, памяти много, и интелы и амд. По данным углядеть хоть какие-то закономерности мне не удалось. Впрочем ускорение было на большинстве машин.

>Прикольно, что было как >относительное ускорение до 35% так и замедление до 10%. >Машины не самые старые, памяти много, и интелы и

Видимо первые это интель а вторые AMD

Сейчса как раз тестю icc на Athlon-ах (TB, XP)

- icc на них как раз проигрывает процентов по 10%

(а по размеру кода до 40% 8) )

Ну и еще имеется некий прикол при исполнении задачки на загруженом до LA=4 (не локально - то есть нагрузка создается мигрировавшими задачами) ноде MOSIX кластера: - задача построенная в gcc - в mtop показывает 100% загрузку процессора - та же задача построенная в icc в mtop показывает 25 % (это РЕАЛЬНАЯ доля загрузки процессора данной задачей)

Из косяков наблюдаются глюки с обработкой exception-ов ...

/SS

Ogr: "Почему-то для слащдота это нормально"

А ты на слэшдот не ссылайся. У них своя башка, у тебя своя. Разницу между "делает код быстрее на 47%." и "делает код быстрее на 47% в тестах на интенсивные вычисления." понимаешь? Если нет, то и разговаривать с тобой не о чем. Если да, то признай ошибку и не пытайся скрыть за криками "ламера" свое собственное ламерство.

> asoneofus, хотите решение? Переходите на другую платформу, и не мучайтесь:)
> AC (*) (2002-01-29 02:21:26.0)

На интел? Увольтессс... Нафиг с пляжа!
Сан, ХП, - вещЧи неплохие, но на них девайс не сваяешь - запчастя в розницу не продаются :) (им.вв. кирпичи)
Остаётся АРМ - но эта поделка ещё та...

Кто - нить компИлер хороший под МИПС32 ИСА-2 знает?

КАИ не в счёт, он для МИПС64 ИСА-1/2...

To SS:

Эта тема - offtopic. Ежели есть интерес пиши на birk_at_chat.ru

На Byte2 - точно никакой разницы между 2.95.x, 2.96 и 3.x нет, я уже проверял. Так что корректно.

Ну а по поводу g77 - на фига он такой, если только 77? Мне 90 нужно. И HPF. Именно в разпараллеливании вся прелесть Portland-а.

А я понимаю... ATLAS и без того ручками заоптимизирован до опупения, компилеру там делать нечего. ;)

А почему g++

void main(){}

может, а для интеля надобно

int main() {}

Да и не дружит интель с gcc как то - инклуды ему, понимаш не те.

Да и что это за сервер регистрации такой, непонятно мне.

Можно говорить о преимуществах того или иного продукта по скорости на _отдельных_ тестах, но нет исходного кода - нет для меня и софта. Исходный код то ведь математически доказать можно, а фокусников-иллюзионистов много сейчас развилось.

2ZhekaSmith: "Разницу между"
Я же говорю - ты туп. Делает icc код быстрее? Делает? Есть еще вопросы? Ах да, он на вычислительных задачах делает, но вот бЯда, игрушки это тож вычислительные задачи, вебсервер тоже где-то там вычислительная задача... Так что иди отдохни...

Ogr (*) (2002-01-29 20:15:51.0)

Юродивое ты наше...

> Ах да, он на вычислительных задачах делает, но вот бЯда, игрушки это тож вычислительные задачи, > вебсервер тоже где-то там вычислительная задача...

Это мог сказать только человек, не имевший дела с вычислениями.

При вычислительных штуках 1% производительности -- это экономия часов и дней. Для игрушки или вебсервера это ноль без палки.

4-7% -- недалека разница...

Прежде всего большое спасибо Пионэру за публикацию, как сломать icc. Этот с%ка у меня никак эту долбаную лицензию не находил и запускаться не хотел. А теперь о компиляторе. Ну, попробовал я эту штковину на своем эмулятое. На самый первый самый поверхностный взгляд а) то, что с icc размер запускаемого файла получается меньше - неправда. C gcc размер ~230к c icc - 320k. б)*очень* непорадовало одно обстоятельство : компилю с -tpp5, он мне пишет "overriding with -tpp6". Ну, и что сие значит ? То, что под P5 компилить не умеет ? Ну, во-первых, это плохо, во-вторых, в хелпе выдает, что может... Ну, машина-то у меня PIII, но на моей-то машине эмулятор и без оптимизации летает ! Мне надо скомпилить как раз под первый пенек ! А вот что=то пока не получилось. Скорость пока оценить не могу, завтра на пеньке погоняю (если запустится), о результатх напишу.

Мля ! Народ ! Этот iсс дейсвительно rulez ! Не дожидаясь завтра, я решил посмотреть, сколько периодов тактовой частоты CPU кушают некоторые алгоритмы из моего эмулятора, при компиляции разными компиляторами. Выбрал алгоритм синтеза звука как ИМХО наиболее ресурсоемкий. Так вот, при компиляции эмулятора с помощью gcc этот алгоритм кушает ~540k периодов тактовой частоты CPU за 1/50 секунды. При компиляции с помощью icc ... 320k !!! Т.е. ускорение ~60% !!! Я блин такого не ожидал !!! Эмулятор написан на С. Плавающей запятой в этом аглоритме нет. Ключи gcc -0x, где x=2,3,20 (разницы практически никакой) От разных -mx только хуже, от разных allignов никакого эффекта. Ключи icc -ip -tpp5 -O3. А вот файлы больше получаются именно с icc. C разными ключами получается поразному, но у icc стабольно на примерно идентичных ключах ~70% побольше.

Пора Огру еще прлюсик к хардлинкам записать. Он, оказывается, не знает еще что есть вычислительные задачи. Для него везде, где есть хоть одно вычислительное действие (например, a[2]) - вычислительная задача. LOL.

2 lenin:
Ну раз даже ленин из мавзолея поднялся чтобы зарулезить новый компилер - значит он и правда рулез :-D lol

2Ogr: меня мягко говоря поразило ваше представление о "вычислительных задачах" - похоже что вы несколько не рубите в данном вопросе. А сказать чего-нть непеременно хочется, да ? Большинство приведенных примеров целесообразнее писать вообще на скриптовых языках (вроде Perl & Python), а на C/C++ писать только действительно resource consuming вещи (SWIG rulez, очень рекомендую)

2lenin: KAI кстати на моей задачке тоже генерит код меньше чем gcc - уж и не знаю, чем это объясняется (скорее всего тем что gcc вставляет кучу мусора в init код, вроде инициализации системы ввода-вывода и проч. shit). Но KAI сосет по скорости по сравнению с icc.

Неприятно поразило следующее - большинство GNU софта настолько кривы и убоги и так заточены под кривой и убогий же gcc, что ничем другим просто не хочут собираться (для тех кто захочет обвинить меня в ереси и злобных нападках на любимого пингвинячьего бога c предложением сжечь на костре святой инквизиции - ну пересобирите хотя бы binutils на чем-либо отличном от GCC. Тогда и поговорим аргументированно. Я уже просто молчу про ваш главный фетиш Linux kernel). Есть повод задуматься...

2all: я тут еще отломал за компанию PGroup C++ 3.3-2 - надо кому ? Оно шо-то тоже не поражает воображение (код медленный и размерчик приличный у выходных файлов получается)

Старый пионэр

А мне кажется, что ничего удивительного в том, что коммерческий компилятор, да еще от производителя процессора генерирует код под этот процессор лучше, чем бесплатный и разработанный под тучу платформ. Странно, если было бы наоборот. И очень хорошо, что, в целом, gcc генерирует сравнимый код - по крайней мере всегда есть выбор.

>>>Я уже просто молчу про ваш главный фетиш Linux kernel

Уже не молчишь... Но причина - в истории вопроса. Заточка кода кернела именно под gcc _сознательный_выбор_ тов. Линуса. Обоснование - давайте не будем писать код портабельно под РАЗНЫЕ компиляторы, а будем писать код под ОДИН, но многоплатформенный компилятор. Практика все же говорит о том, что он похоже был прав - кто не согласен, пусть попробует сделать иначе. Давно пора.

Простите, может быть я что нибудь недопонимаю, но для меня переносимость и открытость кода важнейшие критерии.

Я лучше куплю себе машину, работающую побыстрее, нежели откажусь от этих критериев.

Если бы не AT&T UNIX+C, то сейчас бы и писали на ассемблере, да на Фортранах, что конечно бы было бы хорошо, но дороговато.

Из косяков icc замечено:

SIGSEGV в exit(status)

#include <iostream.h> int main( int argc, char **argv ) { cout << "Test\n"; exit(-1); return 0; }

При status != 0 ... интересно почему ?

/SS

На том же самом flops.c результаты которого на спарке были, на интеле под Linux было проведено сравнение gcc и icc. Результат аналогичный - выигрыш от 50% до 100%.

2Ogr: "Number crunching" и "numerically intense" в оригинальной статье означают определенный тип задач. Это - расчетные задачи (погоды, атомных взрывов), мультимедиа (включая обработку изображений) и цифровая сигнальная обработка (DSP). Такие задачи характеризуются тем, что хорошо подходят для векторной архитектуры - в них много одинаковых операций над векторами (массивами) данных. Если использовать SIMD (Single Instruction Multiple Data) расширения, такие как MMX/SSE, можно добиться ускорения в несколько раз. При необходимости такие задачи оптимизируют вручную (для интела на ассемблере), т.е. хороший компилятор помогает, но ручная оптимизация может добавить еще немало скорости.

Веб-серверы, ядра, перл, офисы и прочее к таким задачам не относятся. Вообще. Игрушки относятся, но, сюрприз, критические участки тоже оптимизируют вручную.

2ZhekaSmith: Теоретик ты наш... Помолчал бы, а?
"хороший компилятор помогает, но ручная оптимизация может добавить еще немало скорости"
Тебе дать url с документацией по процессору и попросить тебя ею воспользоватся при оптимизации руками? :) Или сам уже понял какую чушь сказал? Оптимизация асемблера руками это критинизм достойный студента первого курса заборостроительного техникума.

Для тех кто говорил про работу на AMD http://rsdn.ru/article/?devtools/perftest.xml довольно интересное чтение.
2ZhekaSmith: А Вам в обязательном порядке прочитать вот эту часть http://rsdn.ru/article/?devtools/perftest.xml#IDAYQR2JB надеюсь что после это перед произнесением слова уже будет думать.