LINUX.ORG.RU

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

 , , sunstudio


0

0

По просьбе корпорации Sun, аналитики Phoronix.com провели сравнение эффективности работы компиляторов GCC 3.4.3, GCC 4.0.2, и Sun Studio 12. В тестах обе версии gcc вели себя схоже. Результаты измерений Sun Studio и скомпилированного ею кода по отношению к GCC:

  • PHP собирается из исходников быстрее в 1,7 раза.
  • LAME MP3 конвертирует wav -> mp3 в три раза дольше, а oggenc жмёт медленнее только на четверть.
  • Все сборки GnuPG шифруют на примерно одинаковой скорости. С SQLite ситуация аналогичная.
  • GraphicsMagick, собранный Sun Studio, работает в 2-4 раза быстрее, чем сборки от GCC.

Sun Studio - это набор компиляторов от Sun под ОС Linux и OpenSolaris для языков C, C++ и Fortran. Компиляторы владеют различными оптимизациями, в т.ч. OpenMP. Сравнение проходило на четырехядерном x86_64-процессоре под ОС OpenSolaris.

>>> Подробности

★★★★★

Проверено: Shaman007 ()

Ответ на: комментарий от Led

>Теретически - можно. Практически - сложно (в большинстве случаев - неоправданно сложно).

специально для тех, кому сложно: http://wasm.ru/series.php?sid=17

frame ★★★
()
Ответ на: комментарий от KRoN73

> У людей, которые имеют опыт ручного копания траншей нет преклонения перед траншеекопателем? :) ИМХО, с точностью до наоборот :D

Так дело-то не в преклонении перед экскаватором, а в возведение принципов его работы в разряд эзотерики, недоступной обычному землекопу ;) Ну не всегда сразу очевидный и понятный код генерит компилятор, но понять-то его можно. Нет никакого таинства -O3 и т.п.

mv ★★★★★
()
Ответ на: комментарий от mv

>Так дело-то не в преклонении перед экскаватором, а в возведение принципов его работы в разряд эзотерики, недоступной обычному землекопу ;)

Боюсь, что для человека, не сумевшего подняться уровнем выше землекопа, устройство траншеекопателя - это и есть эзотерика :D

(хотя развивать любые аналогии - это неправильно ;) )

>Ну не всегда сразу очевидный и понятный код генерит компилятор, но понять-то его можно.

Да. Хотя я не в теме вашего спора, но пять копеек всё равно кину - хороший компилятор не порождает ничего эзотеричного, но порождает код более эффективный, чем 99% (цифра от балды) вручную написанных на ассемблере программ. Это даже не считая того, что на более высоком уровне можно реализовать более сложный и эффективный алгоритм :)

...

Я имел довольно высокий «ассемблерный скилл». Но во времена i486 и Watcom C++ 11.x бросил страдать фигнёй и к ассемблеру с тех пор возвращался только один раз (в Embedded). Потому что увидел, что в целом ряде случаев компилятор порождает более эффективный код. И при этом требует на его написание в 10 раз меньше времени :)

...

Кстати, если интересно.
http://balancer.ru/2003/07/26/post-229767.html

Я пытался на ассемблере слепить бенчмарк для расчёта функции Аккермана.

Угробил минут 5 на написание и 45 минут на отладку. Считает ackr(3,8,8) за 2,88сек.

На O'Caml, который я видел впервые в жизни, я минут 5 искал, как на нём пишутся программы, минуту программу писал, заработала сразу. Считает за 2,08 сек.

На Си/Си++ лобовое решение, написанное за пару-тройку минут и за минуту-другую отлаженное считает 4,07 сек. Через час догадался использовать регистровую передачу параметров. Вышло 2.56сек.

На SP-Forth решение писал, наверное, минут 5 и отлаживал столько же. Ради скорости пришлось пожертвовать Форт-стилем и рефакторингом :) Считает за 2,1сек.

Потом посчитал для ackr(3,8,9) на уже тщательно вылизанных программах, вышло:

O'Caml - 19сек.
SPF4 - 21сек.
VC7 - 24сек.
asm - 26сек.
C# - 27сек.

...

GCC в тесте нет, так как был я тогда ещё виндузятником ;) Но он даже сегодня хуже, чем VC7.

KRoN73 ★★★★★
()
Ответ на: комментарий от KRoN73

> Да. Хотя я не в теме вашего спора, но пять копеек всё равно кину - хороший компилятор не порождает ничего эзотеричного, но порождает код более эффективный, чем 99% (цифра от балды) вручную написанных на ассемблере программ. Это даже не считая того, что на более высоком уровне можно реализовать более сложный и эффективный алгоритм :)

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

> http://balancer.ru/2003/07/26/post-229767.html

Можно ускорить. Если выкинуть call и push/pop, будет сильно быстрее.

mv ★★★★★
()
Ответ на: комментарий от KRoN73

> GCC в тесте нет, так как был я тогда ещё виндузятником ;) Но он даже сегодня хуже, чем VC7.

gcc-4.4.0 на 3, 8, 9 выдаёт:

real    0m3.277s
user    0m2.709s
sys     0m0.475s

ocaml 3.11.0:

real    0m5.646s
user    0m4.707s
sys     0m0.847s

Gcc код здорово развернул, во всю использует conditional moves.

mv ★★★★★
()
Ответ на: комментарий от mv

>Да даже если компилятор генерит в 10 раз более плохой код, но делает это быстро, то он всё равно лучше любого ассемблера :)

Ты, наверное, имел в виду не время компиляции, а время написания кода? :) Тогда - да. Поэтому я сегодня на PHP пишу. Хотя 15 лет назад за каждый такт воевал ;)

>Если выкинуть call и push/pop, будет сильно быстрее.

Не получится. Там несколькоуровневая нераскручиваемая рекурсия :) Глянь на первое сообщение темы, там задача описана.

KRoN73 ★★★★★
()
Ответ на: комментарий от mv

>Только push/pop не выкинуть ;)

Угу, в том и прикол :)

KRoN73 ★★★★★
()
Ответ на: комментарий от mv

>gcc-4.4.0 на 3, 8, 9 выдаёт:
>user 0m2.709s

>ocaml 3.11.0:
>user 0m4.707s

Я, кстати, не помню, отмечал потом в той теме или нет, но когда перешёл на Linux, то с удивлением обнаружил, что местный O'Caml много медленнее виндового :)

У тебя какое железо?

Те цифры были получены на PIII-1200/SDRAM (124МГц).

KRoN73 ★★★★★
()

ICC profile guided optimization

прокомментируйте кто-нибудь данный (немного странный результат)
p7zip, сжатие одного и того же архива в 600 Мб

Прирост скорости в PGO составил 18.6%, в то время как с такими же флагами но без PGO 24.9%

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



GCC (default) 2350 Kb/s peak
real 4m27.885s
user 6m28.136s
sys 0m2.661s
+0%

GCC (pentium4, sse2) 2800 Kb/s peak
real 3m50.100s
user 5m35.349s
sys 0m2.373s
+14%

ICC 10.1 (Core2, SSSE3) 3200 Kb/s peak
real 3m20.661s
user 4m55.040s
sys 0m2.401s
+24.9%

ICC 10.1 (Core2, SSSE3, PGO) 3100 Kb/s peak
real 3m37.275s
user 5m9.787s
sys 0m2.420s
+18.6%

Sylvia ★★★★★
()
Ответ на: комментарий от KRoN73

> Ты, наверное, имел в виду не время компиляции, а время написания кода? :) Тогда - да. Поэтому я сегодня на PHP пишу. Хотя 15 лет назад за каждый такт воевал ;)

Конечно! У меня сейчас в лэптопе более мощное железо стоит, чем 4 года назад был наш не самый паршивый продакшн-сервер ;) А через чур медленная, state of the art разработка никому не нужна. Другое дело, что совсем уж расслабляться тоже плохо.

> Не получится. Там несколькоуровневая нераскручиваемая рекурсия :) Глянь на первое сообщение темы, там задача описана.

Да, я уже поправил себя. Хотя, gcc умудрился в некотором виде циклы развернуть.

mv ★★★★★
()
Ответ на: комментарий от mv

>2200 мгц

Вот. И O'Caml отрабатвает за 4 секунды.

А под виндой на P3-1200МГц отрабатывал за 2. Как сейчас у тебя GCC :)

KRoN73 ★★★★★
()
Ответ на: комментарий от Sylvia

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

лолшто?

dikiy ★★☆☆☆
()
Ответ на: комментарий от Manhunt

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

Это твой воспаленный мозг так решил?

srgaz
()
Ответ на: комментарий от KRoN73

> Вот. И O'Caml отрабатвает за 4 секунды.

Хм, SBCL за 8.2с управляется. Недурно...

mv ★★★★★
()
Ответ на: комментарий от srgaz

> Сравнивать GCC 4.2.* им сыкотно.. 

gcc-3.4.6:

real    0m4.137s
user    0m3.434s
sys     0m0.627s

gcc-4.3.0:

real    0m3.685s
user    0m3.360s
sys     0m0.286s

gcc-4.4.0:

real    0m3.277s
user    0m2.709s
sys     0m0.475s

gcc реально прогрессирует. 4.4.0 у 4.3.0 очень сильно отыгрывает.

mv ★★★★★
()
Ответ на: комментарий от srgaz

>Сравнивать GCC 4.2.* им сыкотно..
Так ведь сравнивали выше (правда на Linux и с GCC4.3)
http://www.linux.org.ru/jump-message.jsp?msgid=3519239&cid=3519951

У меня правда получились немного другии цифры
gcc 4.3.2 (-O3 -fomit-frame-pointer -ffast-math) - 45.83
SunStudioExpress 2008/11 (-fast) - 40.51

Т.е. равенство, и это на том тесте, который якобы "Sun Studio проиграла в 3 раза".

Sova777
()
Ответ на: комментарий от Sylvia

>Re: Сравнение компиляторов GCC3, GCC4 и Sun Studio > Хотела я честно сравнить GCC и SunStudio, но вот после такого.... слив засчитан вообщем

Это не Студии слив защитан, а билд-конфигуро-строителям, которые закладываются на багофичи отдельно взятого компилятора на одельно взятой платформе. На солярке все собирается без проблем

А что касается линукса то если чуть-чуть пофиксить исходники гзипа все становится шоколадно: gzip - плюс/минус погрешность (gcc = 4.2)

Кстати на lame студия выигрывает 7-10 процентов у того же 4.2

Aha
()
Ответ на: комментарий от los_nikos

А что значит "проприетарно"? Оно волне себе free for use. А если не нравится что код не открытый так вам что надо - на самом деле ехать или чтоб шашечки на такси нарисованы были?

Aha
()

гм. Странно. Тест крона-73 должен вообще работать без вычислений в run-time. В идеале. А так я померял с разными компиляторами, разными опциями оптимизации, на разные платформы и получил такое:

test_amd64_O2_gcc-3.4 3.44
test_amd64_O2_gcc-4.2 3.42
test_amd64_O2_gcc-4.3 4.50
test_amd64_O2nofp_gcc-3.4 3.43
test_amd64_O2nofp_gcc-4.2 3.44
test_amd64_O2nofp_gcc-4.3 4.48
test_amd64_Os_gcc-3.4 3.56
test_amd64_Os_gcc-4.2 3.51
test_amd64_Os_gcc-4.3 4.52
test_amd64_O3_gcc-3.4 3.43
test_amd64_O3_gcc-4.2 1.79
test_amd64_O3_gcc-4.3 2.15
test_amd64_O3nofp_gcc-3.4 3.43
test_amd64_O3nofp_gcc-4.2 1.77
test_amd64_O3nofp_gcc-4.3 2.17
test_x86_O2_gcc-3.4 4.12
test_x86_O2_gcc-4.3 4.56
test_x86_O2nofp_gcc-3.4 3.65
test_x86_O2nofp_gcc-4.3 4.49
test_x86_Os_gcc-3.4 4.22
test_x86_Os_gcc-4.3 4.67
test_x86_O3_gcc-3.4 4.13
test_x86_O3_gcc-4.3 1.64
test_x86_O3nofp_gcc-3.4 3.61
test_x86_O3nofp_gcc-4.3 1.36
./test_amd64_profile-gcc-4.3 1.64
./test_32_profile-gcc-4.3 1.50
./test_amd64_profile-gcc-4.3-nofp 1.65
./test_32_profile-gcc-4.3-nofp 1.44
./test_64_icc-O3 4.45

Лишний раз убедился что gcc - прекрасный компилятор. Сколько тестов не трердили что 'медленный' - каждый раз проверяю и убеждаюсь что кро поддержки кучи платформ и архитектур он ещё и лучший код генерит.

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

Удивился, что profile-guided оказалось медленнее чем без оной.

Оказалось что быстрее всего код выполняется на x86, с -fomit-frame-pointer -O3 в gcc-4.3.

на amd64 в целом медленнее. И самый быстрый оказался gcc-4.2.

Не удивлён что 4.4 работает быстрее. Какая-то бага есть в 4.3 :)

Забавно, но: icc (11) полностью облажался.

Обязательно потестю на досуге VC2007 и Sun Stiduo12.

Немного переделал примерчик:
#include <stdio.h>

unsigned a(unsigned n,unsigned x, unsigned y);

int main(void)
{
printf("%d\n",a(3,8,9));
return 0;
}

unsigned a0(unsigned x, unsigned y)
{
return x+1;
}

unsigned a1(unsigned x, unsigned y)
{
if (!y)
return x;
else
return a0(a1(x,y-1),x);;
}

unsigned a2(unsigned x, unsigned y)
{
if(!y)
return 0;
else
return a1(a2(x,y-1),x);
}

unsigned a3(unsigned x, unsigned y)
{
if(!y)
return 1;
else
return a2(a3(x,y-1),x);
}

unsigned a(unsigned n,unsigned x, unsigned y) {
if (n==3)
return a3(x,y);
else if (n==2)
return a2(x,y);
else if (n==1)
return a1(x,y);
else if (!n)
return x+1;

if(y)
return a(n-1,a(n,x,y-1),x);

return 2;
}

Получились ещё более интересные результаты:
test_amd64_O2_gcc-3.4 2.55
test_amd64_O2_gcc-4.2 2.53
test_amd64_O2_gcc-4.3 0.00
test_amd64_O2nofp_gcc-3.4 2.54
test_amd64_O2nofp_gcc-4.2 2.55
test_amd64_O2nofp_gcc-4.3 0.00
test_amd64_Os_gcc-3.4 2.54
test_amd64_Os_gcc-4.2 0.00
test_amd64_Os_gcc-4.3 0.00
test_amd64_O3_gcc-3.4 1.70
test_amd64_O3_gcc-4.2 0.23
test_amd64_O3_gcc-4.3 0.00
test_amd64_O3nofp_gcc-3.4 1.72
test_amd64_O3nofp_gcc-4.2 0.22
test_amd64_O3nofp_gcc-4.3 0.00
test_x86_O2_gcc-3.4 2.85
test_x86_O2_gcc-4.3 0.00
test_x86_O2nofp_gcc-3.4 2.47
test_x86_O2nofp_gcc-4.3 0.00
test_x86_Os_gcc-3.4 2.94
test_x86_Os_gcc-4.3 0.00
test_x86_O3_gcc-3.4 2.60
test_x86_O3_gcc-4.3 0.00
test_x86_O3nofp_gcc-3.4 2.31
test_x86_O3nofp_gcc-4.3 0.00
./test_amd64_profile-gcc-4.3 0.00
./test_32_profile-gcc-4.3 0.00
./test_amd64_profile-gcc-4.3-nofp 0.00
./test_32_profile-gcc-4.3-nofp 0.00
./test_64_icc-O3 2.51

Т.е. icc обломался ещё раз. Прогресс в gcc налицо.

gena2x ★★★
()
Ответ на: комментарий от gena2x

>Удивился, что profile-guided оказалось медленнее чем без оной.

выше есть мой тест Intel PGO с 7zip
вот и меня тоже удивляет, пересобрала еще LZMA, за планку брала GCC, Pentium4+SSE2 (обычные параметры для сборки "домашних" пакетов, ноут у меня такой...)


GCC -O2 - _минус_ 5.8%
GCC P4,SSE2 - 0% (планка для сравнения)

ICC, CORE2 +11.8%
ICC, CORE2,PGO +14.0 %
то есть PGO себя чуточку показало

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

если сравнивать скорость кода генерируемого GCC, то максимальна она (код на C) 3.4.6 , 4.2.x показывает самую низкую производительность,
4.1.х - средне, 4.3.3 достаточно быстро и GCC 4.4.0 очень приличную скорость, то есть радует что работа в этом направлении ведется и ведется активно. 4.0.х ветку я для сравнения подходящей не считаю, в отличие от "аналитиков Фороникс"

Sylvia ★★★★★
()
Ответ на: комментарий от Sylvia

>если сравнивать скорость кода генерируемого GCC

да , заранее скажу что тестировала с gzip и его производительностью,
так что если на другом коде будут другие результаты - вполне возможно...

Sylvia ★★★★★
()
Ответ на: комментарий от Sylvia

Dear Silvy,

Я посал про тест крона, где icc явно оказался не у дел, 4.3 показал себя во многих тестах хуже чем 4.2.

И ни один компилятор не оправдал моих надежд на вычисление функции во время компиляции, что явно возможно.

Более того, icc конкретно проиграл даже на упрощённом тесте.

-ipo ему не помогает на этом тесте.

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

В вашем тесте, на x86 -fomit-frame-pointer был?

gena2x ★★★
()
Ответ на: комментарий от Sylvia

>да , заранее скажу что тестировала с gzip и его производительностью

Лучший способ оптимизировать gzip - это собрать себе pigz и пользоваться ним:)

Led ★★★☆☆
()
Ответ на: комментарий от gena2x

мне не очень интересны тесты ради тестов, это синтетика,
хотя конечно очень показательная, мне интересно сделать тесты с реальными приложениями, gzip в этом плане отличается простотой сборки, совместимостью практически со всеми компиляторами, хотя вот СанСтудия его отказалась собирать :) А также простой методикой проверки производительности самого кода, ассемблерных вставок в gzip нет.

-fomit-frame-pointer был во всех случаях


2 Led, производительность gzip'a даже без оптимизации меня устраивает, pigz есть, и есть pbzip2, bzip2smp что кстати лучше в том плане что bzip2 более медленный по сравнению с gzip,
еще бы lzma найти с поддержкой потоков, хотя Тукаани что то делает в этом направлении, но неубедительно и совместимость с старым lzma поломал в новых `XZ`

Sylvia ★★★★★
()
Ответ на: комментарий от Sylvia

>есть pbzip2, bzip2smp что кстати лучше в том плане что bzip2 более медленный по сравнению с gzip, еще бы lzma найти с поддержкой потоков, хотя Тукаани что то делает в этом направлении, но неубедительно и совместимость с старым lzma поломал в новых `XZ`

Многопоточные компрессоры всегда будет давать худшую компрессию, по определению.

Поэтому для быстрого сжатия - pigz или аналоги, я bzip2 и lzma стОит использовать только если время сжатия некритично, но хочется достичь максимального сжатия, поэтому их многопоточные варианты (заведомо более проиграшные) ИМХО не нужны.

Led ★★★☆☆
()
Ответ на: комментарий от Led

bzip2smp
pbzip2
дают идентичный результат однопоточному bzip2

единственное что первый только сжимает и только stdin 2 stdout
а второй только уже готовый файл

для realtime сжатия есть lzo
для всего остального - субьективно по нуждам и тому какой процессор.


7zip (p7zip) - двухпоточный, хотя неспособен утилизовать второе ядро более 50% (т.е. 150% получается нагрузка примерно), но это тоже лучше чем ничего

Sylvia ★★★★★
()
Ответ на: комментарий от Led

>Многопоточные компрессоры всегда будет давать худшую компрессию, по определению.

Смелое заявление. Главное, громко и с пузырями.

AVL2 ★★★★★
()
Ответ на: комментарий от AVL2

>Смелое заявление. Главное, громко и с пузырями.

Ок, тогда тихо и без пузырей, многопоточный код, не снижающий уровень сжатия, для указанных выше bzip2 и lzma - в студию! И я признаю, что ступил:)

Led ★★★☆☆
()
Ответ на: комментарий от Sylvia

> для bzip2 (вот не читаете мои сообщения) - сами напросились
> http://compression.ca/pbzip2/

$ time pbzip2 -9 -k dfly-gui-2.2.0_REL.iso
454.05user 12.44system 4:24.66elapsed 176%CPU (0avgtext+0avgdata 0maxresident)k
88inputs+0outputs (0major+1542566minor)pagefaults 0swaps
$ mv dfly-gui-2.2.0_REL.iso.bz2 dfly-gui-2.2.0_REL.iso.pbz2
$ time pbzip2 -9 -r -k dfly-gui-2.2.0_REL.iso
447.87user 9.13system 4:22.81elapsed 173%CPU (0avgtext+0avgdata 0maxresident)k
920inputs+0outputs (1major+434633minor)pagefaults 0swaps
$ mv dfly-gui-2.2.0_REL.iso.bz2 dfly-gui-2.2.0_REL.iso.rpbz2
$ time bzip2 -9 -k dfly-gui-2.2.0_REL.iso
423.49user 4.90system 7:14.96elapsed 98%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+0outputs (0major+2027minor)pagefaults 0swaps
$ ls -l dfly-gui-2.2.0_REL.iso*
-rw-r--r-- 1 led led 1269006336 лют 16 10:32 dfly-gui-2.2.0_REL.iso
-rw-r--r-- 1 led led  494774334 лют 16 10:32 dfly-gui-2.2.0_REL.iso.bz2
-rw-r--r-- 1 led led  495072030 лют 16 10:32 dfly-gui-2.2.0_REL.iso.pbz2
-rw-r--r-- 1 led led  494724210 лют 16 10:32 dfly-gui-2.2.0_REL.iso.rpbz2

Led ★★★☆☆
()
Ответ на: комментарий от Led

Да, забыл добавить: это всё на двухядерном процессоре.

Led ★★★☆☆
()
Ответ на: комментарий от Led

612904960 linux28.7.tar

$pbzip2 -9v linux28.7.tar
Parallel BZIP2 v1.0.3 - by: Jeff Gilchrist [http://compression.ca]
# CPUs: 2
110289814 linux28.7.tar.bz2

$bzip2 -9v linux28.7.tar
109535518 linux28.7.tar.bz2
разница не такая уж и большая, но есть.. хорошо, другой код, просто когда давала ссылку не было возможности проверить на двухядерном


$cat linux28.7.tar |bzip2smp -9v > linux28.7.tar.bz2
bzip2smp: No hyperthreading detected.
bzip2smp: CPUs detected: 2
bzip2smp: Threads to use: 2
109535518 linux28.7.tar.bz2

то есть также как и bzip2
ссылка - http://bzip2smp.sourceforge.net/
сжимать файл он не умеет, только поток с stdin на stdout

Sylvia ★★★★★
()
Ответ на: комментарий от Sylvia

Да, так и есть, согласен.

Правда (чего и следовало ожидать) памяти на каждый CPU он огребает не менее 7,5М. Для lzma этот подход врядли представляет практическую ценность: там для -9 уже требуется 311М памяти при упаковке и, что более критично, 33М при распаковке.

Led ★★★☆☆
()
Ответ на: комментарий от KRoN73

>Поэтому я сегодня на PHP пишу. Хотя 15 лет назад за каждый такт воевал ;)

Такая ж история. Последний раз, когда использовал ассемблер, убил целый выходной, получил прирост производительности в пределах погрешности. Потом немножко подумал, ввел одну переменную (4 байта), получил ускорение в 2-5 раз. С тех пор ассемблер не трогаю

anonymous_0
()

компиляторы мож и хорошие а ide которая идёт к семейству компиляторов херовая.. сделана на яве,которая под линухом не лучшим образом работает.

Konstantyn
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.