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

Silvy отлично теперь пожалуйста на собери при помощи CC из Sun Studio 12 вместе с examples(на 32-bit линуксе).

>Недавно собирал qt 4.4.2 при помощи sun studio 12, так пришлось целый день убить. Кроме того что пришлось многое руками поправить

после такого не возникает желания, я там PHP5 собирала, действительно очень медленно, с -O -fast 5 минут с лишним, в то же время как GCC 4.3.3 управился за 2 минуты

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

(ICC бинарники ушли в runtime на ноут, GCCшные остались на десктопе)

>Чаще ИМХО -O3 вообще к падению производительности приводит

Интересно, а зачем mplayer-щики -O4 ставят? Причем и на кодеки, и на остальную обработку.

в старых версиях GCC была более ощутимая разница между O2 и O3
вообщем то осталась параноидальная немного традиция к использованию

O4 O6 O9 и O99

в Glibc наверное еще можно увидеть O99

более универсальный способ кстати просто использовать -O
без цифры, это позволит компилятору самому выбрать оптимальную для него оптимизацию, для GCC -O например равноценно -O2 , на ICC - также,
а вот SunStudio12 -O интерпретирует как -xO3 (-O3)

>> По просьбе корпорации Sun, аналитики Phoronix.com провели сравнение эффективности работы компиляторов

> И что после этого заказного сравнения можно ожидать? А ничего что sun studio проприетарно как нефть?

Хммм... Были в Питере три мужика, занимались производительностью на санстудии: двое на спеках, а один доморощенные тесты для бласа и лапака на фортране писал, причём не интегральные, а для каждой процедурки в отдельности. И чёрт этого последнего дёрнул провести сравнение самой 12-й санстудии с GCC 4.3 на линуксе на написанных им самим тестах. И рассказывали мне его коллеги, что про ПРОЧИХ РАВНЫХ УСЛОВИЯХ (статическая библиотека, собранная тестируемым компилятором по стандартным исходникам без опенмп) отсосал сановский компилятор по полной программе -- в лучшем случае то же время, что и для gfortran, в худшем -- регрессия на 60% (!!!). Доложился об этом начальству, а его взяли и сократили за усердие...

Эээ а какие ещё есть gcc совместимые (хотябы относительно) компиляторы кроме icc и sunstudio?

Open64 есть например
http://www.open64.net/

>Простым просмотром дампа дизассемблира можно понять, кто виноват в косяке - ты или компилятор.

"Простым" - не получится. разве что скомпилено было с -O0

> "Простым" - не получится. разве что скомпилено было с -O0

Да бросьте...

>Вот мои флаги: HOSTCFLAGS = -Wall -Wstrict-prototypes -O3 -fomit-frame-pointer -msse4a HOSTCXXFLAGS = -O3

Даже если предположить, что SSE/MMX в ядре допустимо (только предположить, потому что реально это не так), то ты только потеряешь в производительности, потому как переключение контекста (с охранением/востановлением SIMD регистров) сожрёт у тебя ресурсов на порядок больше, чем ты выиграешь (кстати, на чём?) от использования SIMD.

>-O2 включает все возможные оптимизации не приводящие к увеличению размера кода Это про -Os, а не про -O2. А именно:

-Os включает оптимизацию -O2, кроме тех флагов, которые увеличивают размер кода.

>amd64 скорее исключение :)

>хотя взамен они получили SSE

SSE был уже в AthlonXP

>именно он у меня не компиллировался из-за какой то ошибки скачивания

"не компиллировался" из-за "ошибки скачивания"??? Оригинально:)

>Похоже настало время привести всё в порядок.

начать использовать нормальный дистрибутив?

>-Os включает оптимизацию -O2, кроме тех флагов, которые увеличивают размер кода.

На практике система с -Os работает очень, очень и очень вальяжно :) Мягко так, и неторопливо :D Пробовал когда-то, думая, что экономия памяти мне важнее, вроде бы, не столь принципиального падения скорости. Посидел дня четыре, не вынес, и пересобрал мир :D

>> "Простым" - не получится. разве что скомпилено было с -O0

> Да бросьте...

Это вы бросьте... Дизассемблировать Z80 и 8086 - это не то же самое, что i386 c -O3 (ну, это хоть как-то ещё возможно), или x86_64 с -O3 (где регистров в два раза больше и вариантов их использования в несколько раз больше, чем на классическом i386). Даже в -O2 компилятор переставляет инструкции местами для возможности параллельного их испольнения (на i586 и выше, которые это умеют)

>На практике система с -Os работает очень, очень и очень вальяжно :) Мягко так, и неторопливо :D Пробовал когда-то, думая, что экономия памяти мне важнее, вроде бы, не столь принципиального падения скорости. Посидел дня четыре, не вынес, и пересобрал мир :D

не, ну всю систему собрать с -Os - это уже изврат:) или просто шутка:)

на самом деле, -O2 по-умолчанию; -Os для чего-то в initrd или для некритичных к производительности демонам, постоянно висящим в памяти и изредка что-то делающим; -O3 - для кодеков/компрессоров/компиляторов. Всё остальное (за редким исключением) - "от лукавого" и от недостатка образования:)

>Интересно, а зачем mplayer-щики -O4 ставят

http://www.linux.org.ru/view-message.jsp?msgid=3207138#3269086

Silvy, а что библиотеки созданные icc можно линковать с бинарниками созданными g++ ?

да

но
1) желательно в CFLAGS , CXXFLAGS или icc.cfg / icpc.cfg иметь флажок -gcc

2) учесть то что Intel автоматически слинковывает библиотеки
libirc.a libimf.so libsvml.so libintlc.so.5
и если будут ошибки с ненайденными символами потом (как правило не бывает,
только если статическую библиотеку собрали lib*.a) то скармливать линкеру еще и эти библиотеки

>>именно он у меня не компиллировался из-за какой то ошибки скачивания

>"не компиллировался" из-за "ошибки скачивания"??? Оригинально:)

ну да, так и есть. из-за ошибки скачивания появлялся пакет неправильной длины. Начиналась установка, и первая же проверка на длину файла эту установку естественно завершала.

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

;-)

>>Похоже настало время привести всё в порядок.

>начать использовать нормальный дистрибутив?

а ты бы не затруднился ответить на один вопрос - а чем меня существующий не устраивает ?

> Это вы бросьте... Дизассемблировать Z80 и 8086 - это не то же самое, что i386 c -O3 (ну, это хоть как-то ещё возможно), или x86_64 с -O3 (где регистров в два раза больше и вариантов их использования в несколько раз больше, чем на классическом i386). Даже в -O2 компилятор переставляет инструкции местами для возможности параллельного их испольнения (на i586 и выше, которые это умеют)

Дак не обязательно именно дизассемблировать. Можно заставить гыцацу выдать ассемблерный листинг вперемешку с оригинальным кодом. Примерно так:

gcc test.c -g -Wa,-ahlsd=test.s -o test

В файле test.s будет листинг.

В первую очередь - это PGI http://www.pgroup.com/ .
А тема жжот, без анонимусов здесь просто хацкор.ру в исполнении быдлосильви и поклонников.
Молодцом, собсно, скоро будет петросян-линукс - это хоть что-то.

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

Всем тихо! Вещает анонимный гений!

О терь у анонимусов тысяча имён %)

А ты как думал? =)
Не хватает терпения на быдло, однако.
4 года был анонимусом, обитал в основном в деве и хардваре, теперь вот пришлось зарегится.

Зарегался давно, логиниться пришлось с недавних пор =)

>Всем тихо! Вещает анонимный гений!
Как будто ты очень конкретная личность, бугога, недоумок!

> Как будто ты очень конкретная личность, бугога, недоумок!

Есть что сказать по существу?

А что ты ожидаеш по существу в столь пионерской теме?
Зачем ты про анонимный гений завел разговор?
Сам что по существу сказал?
Распоясались тут, пионерчики.

Т.е. по теме сказать нечего?

> Это вы бросьте... Дизассемблировать Z80 и 8086 - это не то же самое, что i386 c -O3 (ну, это хоть как-то ещё возможно), или x86_64 с -O3 (где регистров в два раза больше и вариантов их использования в несколько раз больше, чем на классическом i386). Даже в -O2 компилятор переставляет инструкции местами для возможности параллельного их испольнения (на i586 и выше, которые это умеют)

Опыта работы с ассемблером ведь нет, так? Иначе бы такого тупого преклонения перед компилятором не было.

> "извиняюсь" - это извиняю сам себя.

Извиняюсь - это не "я извиняю сам себя", а "приношу свои извинения".

> надо говорить "извините", т.е. просить прощения.

Ну надо - значит вперёд и с песней. Кто держит-то?

Почему сразу "тупое преклонение перед компилятором"?

Компилятор пишут люди. Они свои знания вкладывают в программу.

Я очень сильно удивился, когда недавно посмотрел код, который генерирует gcc.

Например printf("%s\n", message); превращается в call puts

А чего стоит передача параметров функции через регистры.

Или использование команд mov, call при передаче параметров через стэк (вместо push, call, add esp).

Причем это только то, что заметно с первого взгляда.

Рекомендую. http://www.luxrender.net/forum/viewtopic.php?f=21&t=603

> гм... ядра sidux хороши, и ничего компилить не нужно http://manual.sidux.com/ru/welcome-ru.htm

команда sux мне понравилась... там еще подобные команды есть, ;)

И что тут удивительного?

>Опыта работы с ассемблером ведь нет, так?

Есть. Ещё с того времени, как ты в штаны непроизвольно писался:)

> Причем это только то, что заметно с первого взгляда.

sign "орлиный глаз". Просто невероятно, до чего дошло современное компиляторостроение! Параметры через регистры передают, это же надо!

> Есть. Ещё с того времени, как ты в штаны непроизвольно писался:)

Ну так чего пугаешься? :) При должном уровне сноровки выхлоп компилятора вполне понять можно.

>При должном уровне сноровки выхлоп компилятора вполне понять можно.

Так компилятора или дизассемблера?:)

на 8086 я с помощью дизасма AutoCAD правил - никаких проблем. Сейчас скомпилированное с "-march=core2 -O3" тоже можно, но это уже нетривиально и в несколько раз сложнее.

> Так компилятора или дизассемблера?:)

objdump'а

> на 8086 я с помощью дизасма AutoCAD правил - никаких проблем. Сейчас скомпилированное с "-march=core2 -O3" тоже можно, но это уже нетривиально и в несколько раз сложнее.

Тем не менее, можно. Так?

>Тем не менее, можно. Так?

Теретически - можно. Практически - сложно (в большинстве случаев - неоправданно сложно). Говорю так потому, что приходилось, сейчас и после -O3 для x86_64, а не "когда-то в молодости на Z80". Возьмите и попробуйте СЕЙЧАС, с -march=x86_64 -O3, а то такое ощущение, что вы рассуждаете о "теретической возможности", опираясь на опыт 20-летней давности. Или я ошибаюсь?

> Или я ошибаюсь?

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

> This intrinsic requires target that supports appropriate instruction set

а вы не забыли указать -xarch= с соответствующей архитектурой? Например -xarch=sse2 (но это моя догадка). А то явно вы пытаетесь вкомпилировать xmm intrinsic в сборку для 386. О чем и получаете сообщение. Пока что вы продемонстрировали, что ни вы ни система сборки lame не в курсе как собирать lame с помощью suncc.

> Он вообще amd64 не поддерживает

Вполне поддерживает. Но сами бинарники компилятора 32 битные. Это виндоус и линукс бывают или 32 или 64 битными. Солярис же с тех пор как появились 64 битные процессоры SPARC одновременно и такой и такой. Все дело в том, что однозначного выигрыша в производительности не получается ни там ни там. А что ваш линукс x64 разучился запускать 32 битные бинарники?

> GCC -O например равноценно -O2 , на ICC - также, > а вот SunStudio12 -O интерпретирует как -xO3 (-O3)

Нужно понимать, что эти цифры у разных компиляторов означают разное. У suncc уровней пять, у gcc их три.

Ну почему же сразу "ни вы ни система сборки lame не в курсе как собирать lame с помощью suncc"?!? И система и Сильва знают как собирать это добро с помощью suncc (ну или думают что знают), вот только по умолчанию при сборке СанСтудией LAME не добавляет абсолютно никаких флагов оптимизации - голый ЦЦ

cc -DHAVE_CONFIG_H -I. -I../.. -I../../include -I. -I../../libmp3lame -I../../mpglib -I../.. -c xmm_quantize_sub.c -KPIC -DPIC -o .libs/xmm_quantize_sub.o

и так далее.

А вот для gcc - "все что барин изволит":

gcc -DHAVE_CONFIG_H -I. -I.. -I../include -I. -I../libmp3lame -I.. -O3 -fomit-frame-pointer -ffast-math -maccumulate-outgoing-args -Wall -MT interface.lo -MD -MP -MF .deps/interface.Tpo -c interface.c -fPIC -DPIC -o .libs/interface.o

Мне теперь абсолютно понятно откуда взялись 127 против 43 при тестировании на LAME, если указать даже банально -O результаты будут сравнимыми. В общем компилировать нужно с -fast и только с -fast и будет всем счастье

Единственное что осталось не понятным, так это откуда такие тестеры берутся

>> "извиняюсь" - это извиняю сам себя.

> Извиняюсь - это не "я извиняю сам себя", а "приношу свои извинения".

Вересаева читать надо. Моду говорить "извиняюсь" завели поляки в начале XX века.

>Опыта работы с ассемблером ведь нет, так? Иначе бы такого тупого преклонения перед компилятором не было.

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

Тот, кому несколько лет пришлось плотно писать на ассемблере потом начинает очень и очень уважать хорошие компиляторы...