Сравнение компиляторов GCC3, GCC4 и Sun Studio

Предистория: http://www.linux.org.ru/view-message.jsp?msgid=3491514

GraphicsMagick: хорошо завязан на OpenMP, поэтому сравнение можно традиционно считать нечестным)

s/Предистория/Предыстория

не сравнивали
Gcc 4.1
Gcc 4.2
Gcc 4.3
Gcc 4.4


Intel C/C++

вообщем сравнение не полно и не объективно

lame вообще с кусочками кода на ассемблере, там производительность от компилятора не зависит сильно

все что они доказали что GCC плохо работает на солярисе и не более

Это не предыстория, а одна и таже ссылка. Давай ссылку на сравнение компиляторов, а не ОС.

Точно. Поправил) Хоть кто-то ходит по ссылкам.

Ерунда,а не тест.

Так вот куда ушли анонимные аналитики ЛОРа.

кстати обязательно скачаю Sun Studio 4 Linux и потестирую с

сборкой PHP, LAME, ну и Gzip как обычно ;)

Версию GCC4 специально такую древюю взяли? У gcc-шников при переходе с тройки на четверку была куча регрессий производительности, многие из которых в более поздних версиях GCC4 были починены.

> все что они доказали что GCC плохо работает на солярисе и не более

Не думаю, что операционка влияет на соотношение между компиляторами.

> аналитики Phoronix.com
no comments

> GraphicsMagick: хорошо завязан на OpenMP, поэтому сравнение можно традиционно считать нечестным)

В свете этого особенно непонятно, почему они не испытали gcc>=4.2, в которых и появилась поддержка openmp.

Сходил по ссылке. Единственный тест, где солярные компиляторы выигрывают - это GraphicsMagick. И тот благодаря OpenMP, поддержки которого в столь древней версии GCC4 тупо нет.

И да, в тесте очень не хватает Интеловского и Микрософтовского компиляторов. Боюсь, что оба они заметно обгоняют gcc по качеству оптимизации.

Хотела я честно сравнить GCC и SunStudio, но вот после такого.... слив засчитан вообщем

/var/tmp/gzip-1.3.12 :$time make
Making all in lib
make[1]: Entering directory `/var/tmp/gzip-1.3.12/lib'
make all-am
make[2]: Entering directory `/var/tmp/gzip-1.3.12/lib'
source='creat-safer.c' object='creat-safer.o' libtool=no \
DEPDIR=.deps depmode=none /bin/sh ../build-aux/depcomp \
/usr/local/sunstudio12/bin/cc -DHAVE_CONFIG_H -I. -O -c creat-safer.c
"///usr/local/sunstudio12/prod/include/cc/time.h", line 6: too many open files: <time.h>
"./time.h", line 24: too many open files: "///usr/local/sunstudio12/prod/include/cc/time.h"
"./time.h", line 24: too many open files: "///usr/local/sunstudio12/prod/include/cc/time.h"
"/usr/include/bits/stat.h", line 88: incomplete struct/union/enum timespec: st_atim
cc: acomp failed for creat-safer.c
make[2]: *** [creat-safer.o] Error 2
make[2]: Leaving directory `/var/tmp/gzip-1.3.12/lib'
make[1]: *** [all] Error 2
make[1]: Leaving directory `/var/tmp/gzip-1.3.12/lib'
make: *** [all-recursive] Error 1

> кстати обязательно скачаю Sun Studio 4 Linux и потестирую с сборкой PHP, LAME, ну и Gzip как обычно ;)

А протестируй! Последние версии gcc3, gcc4, Sun Studio и бесплатный Интеловский. Прекрасная новость получилась бы!

Интелевоский да, а вот про МС я бы так не говорил.

> "./time.h", line 24: too many open files: "///usr/local/sunstudio12/prod/include/cc/time.h"

Рыдаю, под столом

собираю PHP5.2.8 для начала Сан, чтобы время зря не тратить если будет фейл

> Интелевоский да, а вот про МС я бы так не говорил.

Лет пять назад тестирование какое-то смотрел на тему gcc VS visual studio. И тогда (по смутным воспоминаниям) gcc ощутимо уступал. Может быть, сейчас ситуация иная: не знаю.

вообщем что получилось с PHP5, Эпик Фейл засчитан, тип системы определило как -gnuaout , что в результате предсказуемо привело к неспособности линкера найти free memcpy realloc strlen и так далее...

>И да, в тесте очень не хватает Интеловского и Микрософтовского компиляторов. Боюсь, что оба они заметно обгоняют gcc по качеству оптимизации.

Вот когда первый узнает о процессорах, кроме intel, а второй об операционных системах, тогда и будем сравнивать их c gcc.

скорость билда PHP5

Sun, fail to link - 3 min 40 sec
GCC 4.3.3, success - 1 min 59 sec

ICC прекрасно знает о других процессорах, хотя расширений у AMD заметно меньше и соответственно возможности оптимизации под них тоже меньше

> расширений у AMD заметно меньше и соответственно возможности оптимизации под них тоже меньше

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

> ICC прекрасно знает о других процессорах, хотя расширений у AMD заметно меньше и соответственно возможности оптимизации под них тоже меньше

А как же SPARC, PPC, ARM, MIPS и кучка ещё менее популярных?

вот так оно собирает LAME, что тоже не удивляет, потому что в LAME достаточно большие кусочки asm кода

make[3]: Entering directory `/var/tmp/lame-3.98.2/libmp3lame/vector'
source='xmm_quantize_sub.c' object='xmm_quantize_sub.lo' libtool=yes \
DEPDIR=.deps depmode=none /bin/sh ../../depcomp \
/bin/sh ../../libtool --tag=CC --mode=compile /usr/local/sunstudio12/bin/cc -DHAVE_CONFIG_H -I. -I../.. -I../../include -I. -I../../libmp3lame -I../../mpglib -I../.. -O -c -o xmm_quantize_sub.lo xmm_quantize_sub.c
/usr/local/sunstudio12/bin/cc -DHAVE_CONFIG_H -I. -I../.. -I../../include -I. -I../../libmp3lame -I../../mpglib -I../.. -O -c xmm_quantize_sub.c -o xmm_quantize_sub.o
"xmm_quantize_sub.c", line 55: [init_xrpow_core_sse]:ube: error: This intrinsic requires target that supports appropriate instruction set
....
cc: ube failed for xmm_quantize_sub.c

> А как же SPARC, PPC, ARM, MIPS и кучка ещё менее популярных?

Понятно, что по количеству таргетов у gcc тут выигрыш перед конкурентами. Это не делает сравнение на ia32 и amd64 менее интересным.

для начала ICC и на родной архитектуре может собрать далеко не все с удовлетворительным результатом, GCC в этом плане обладает гораздо большей совместимостью, оно и понятно, код то писали для него )

ICC хорош для сборки архиваторов, математических библиотек и. т. п.

И кстати о процессорах, сейчас решил скачать sun studio чтобы заценить и не обнаружил сборки под amd64. Он вообще amd64 не поддерживает (в т.ч. сборку под него) или я что-то не понял или не там искал?

>The hardware components once again consisted of two AMD Opteron 2384 quad-core processors, a Tyan Thunder n3600M motherboard, 4GB of Corsair DDR2-667MHz memory, 160GB Seagate Serial ATA 2.0 hard drive, NVIDIA GeForce 9800GTX 512MB graphics card.

Мне бы такую машинку...

а у товарищей с фороникса как оно собралось?

В сборке под win64 и процы AMD у icc получается более "быстрый" код чем у vc и gcc.

Форониксы на Солярисе тестировали, я на линуксе, вообщем ситуация с точностью до наоборот и даже хуже )

там одна сборка для 32 и 64 похоже
во всяком случае -m32 -m64 флаги присутствуют

зацените, а то может я тяп-ляп его поставила , что он у меня феерично-эпические глюки выдает )

> а у товарищей с фороникса как оно собралось?

Скорее всего с напильник-патчами под sun studio =).

> зацените, а то может я тяп-ляп его поставила , что он у меня феерично-эпические глюки выдает )

Поставил на закачку ICC 11.0.081, MSVC++ Express 2008 SP1 и Sun Studio Express 2008/11. Но с моим коннектом докачается всё это примерно завтра к обеду 8).

icc (ICC) 11.0 20081105
очень глючный код собирает, p7zip и gimp например не могут открывать файлы (битые архивы или прозрачный фон), странные глюки,
в 10.1 такого безобразия нет

MSVC есть для Линукс тоже? ) надо будет оценить

> MSVC есть для Линукс тоже? ) надо будет оценить

Нет конечно =). Я хочу попробовать затестить gcc (оригинальный + mingw под виндой), icc (linux), sun studio (linux) и msvc++ (винда + возможно полученные бинарники в вайне). Скорость компиляции меня мало волнует, интересует скорость работы сгенерированных бинарников.

>GCC 4.0.2

"Аналитики" Phoronix.com продались с потрохами за миску похлебки?

Sun Studio Express 2008/10
Ubuntu и OpenSolaris
LAME собирается без проблем

> icc (ICC) 11.0 20081105
> очень глючный код собирает, p7zip и gimp например не могут открывать файлы (битые архивы или прозрачный фон), странные глюки,
> в 10.1 такого безобразия нет

ICC известен тем, что при включенной оптимизации (особенно "векторизации" кода под SIMD) может расколбасить даже правильный с точки зрения стандартов код...

векторизация там давно by default как в 10.1 так и в 11.0

Вот и колбасит by default.

Эээ я вот развлекался с icc, вместе со скоростью приходят и баги странные, которые часто всю эту скорость и сжирают. Очень похожее поведение у меня с -O3 было, то есть некоторые вещи быстро, а некоторые наоборот тормозили как незнаю что

Не, без тестов gcc с llvm бекэндом и clang это не интересно...

Кстати у ся в генте врубил векторизацию, вродь живой остался)))

> Кстати у ся в генте врубил векторизацию, вродь живой остался)))

А как врубается и зачем, если не секрет (гуглить лень)? :)

Вообще как мне кажется ICC разрабатывался не как универсальный компилятор, а как компилятор под определенный круг задач, в основном связанными с математическими вычислениями, поэтому он и глючит на обыденных задачах. Насчет Микрософтовского компилера ничо плохого не скажу, он конечно неприлично долго линкует, зато код пошустрее чем minGWшный получается, хотя с родным правильно настроенным GCC не сравнивал.
Вообще как мне кажется главное в gcc это универсальность и стабильность, то есть то что нужно для обычных настольных компьютеров.

-ftree-vectorize

для GCC

фейл только с сборкой OOO если форсировать