GCC -O2 -fomit-frame-pointer -ftree-vectorize -mfpmath=sse -march=pentium4 -msse2
ICC (10.1) -axW -fomit-frame-pointer -O2 -march=pentium4 -msse2

>Тогда я не понял, про что тут сказано: "и софтовой эмуляцией (посредством двух 64-битных float)."

Тогда читайте исходники gcc, а именно - реализацию поддержки long double для процессоров, не имеющих 128-битных float-регистров.

Да чё гадать-то? Учишь ассемблер, пишешь на нём пару лет, чтобы опыта поднабраться, потом objdump'ом смотришь, какой компилятор лучше =)

А кто нибудь собирал pcsx2 под icc? Там разные оптимизации под процессор бы не помешали, жаль я не особо в этом разбираюсь.

> Тогда читайте исходники gcc, а именно - реализацию поддержки long double для процессоров, не имеющих 128-битных float-регистров.

Про два флоата я так и не понял, ну да ладно :)

Кстати, имхо, в glibc для x86-64 ieee754 сделан программно и 128 бит. По крайней мере, для некоторых математических функций.

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

для Gtk2 кстати есть gtkperf

так если сравнить

glibc-glib2-gtk-gtkperf с march=i486
и
glibc pentium4sse2, glib2 (icc p4sse2), gtk (p4sse2), gtkperf (icc, p4sse2)

то прирост скорости 2 % )

>GCC -O2 -fomit-frame-pointer -ftree-vectorize -mfpmath=sse -march=pentium4 -msse2

pentium4 автоматически включает sse2, так что -msse2 - лишнее:)

>ICC (10.1) -axW -fomit-frame-pointer -O2 -march=pentium4 -msse2

icc лучше всегда указывать опцию -gcc (особенно - для библиотек), во избежание ненужных проблем:)

> то прирост скорости 2 % )

А если wine'овский конвертер rgb32->rgb16 переписать с чистого Си на ручной sse, то на x86-64 получается прирост скорости 400-450%. К сожалению, вайн - 32-битным должен быть, а в 32 битах доступна только половина sse-регистров, поэтому прирост только 250%

>Да чё гадать-то? Учишь ассемблер, пишешь на нём пару лет, чтобы опыта поднабраться, потом objdump'ом смотришь, какой компилятор лучше =)

Откуда такая наивность? Это от "Учишь ассемблер, пишешь на нём пару лет" такое?:)

Рекомендую посмотреть вывод objdump чего-нибудь сложнее hello.o, скомпилированного с -O3:)

> Откуда такая наивность? Это от "Учишь ассемблер, пишешь на нём пару лет" такое?:) Рекомендую посмотреть вывод objdump чего-нибудь сложнее hello.o, скомпилированного с -O3:)

Да ладно, мы на Спектруме и графические редакторы полностью на ассемблере писали, нечё -O3 пугать! ;)

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

замечательно работает.

я тут тоже замеры проводил для небольших вычистительных задач на C++... по моим замерах g++ 3.4 генерировал более медленный код, чем Sun CC, а g++ 4.2 и 4.4-svn - заметно более быстрый, причем именно на 64-битах.

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


-gcc я обычно не указваю, проблем особенных это не вызывает, если что, я в курсе про этот флажок

ну так они то брали 4.0 ) чтобы специально показать то, что gcc работает плохо )
не могли же они с такой целью взять свежую версию? :)

типа пропиарили то что у них работоспособный OpenMP, а вв gcc он только для видиммости? в 2-4 раза ?? gcc вообще чтоли не распараллеливает OpenMP программу?

тот gcc который они тестировали этого не умеет ) не нужно поддаваться на провокации

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

>>Выше я дал пример с -march=native.

>На х86 этого мало. Если не под х64 собираешь, иначе поминай ммх и ссе.

Забавно, но -match=prescott на моём CPU и GCC 4.3.3 показывает выключение и sseN, и mmx. Как и с native:

home ~ # gcc -march=native -Q --help=target|grep sse
-mno-sse4 [включено]
-msse [выключено]
-msse2 [выключено]
-msse3 [выключено]
-msse4 [выключено]
-msse4.1 [выключено]
-msse4.2 [выключено]
-msse4a [выключено]
-msse5 [выключено]
-msseregparm [выключено]
-mssse3 [выключено]
home ~ # gcc -march=native -Q --help=target|grep mmx
-mmmx [выключено]
home ~ # gcc -march=prescott -Q --help=target|grep mmx
-mmmx [выключено]
home ~ # gcc -march=prescott -Q --help=target|grep sse
-mno-sse4 [включено]
-msse [выключено]
-msse2 [выключено]
-msse3 [выключено]
-msse4 [выключено]
-msse4.1 [выключено]
-msse4.2 [выключено]
-msse4a [выключено]
-msse5 [выключено]
-msseregparm [выключено]
-mssse3 [выключено]

Я жестоко обломан :) Пойду включать вручную :)

>там выше по треду есть определение автофлагов, не включает оно ничего в любом случае лучше вручную задать флажок и точно знать что оно включено )

Да, вы правы :(

>-gcc я обычно не указваю, проблем особенных это не вызывает, если что, я в курсе про этот флажок

Да ну? А Qt, с которым KDE не собирался - не проблема?

>pentium4 автоматически включает sse2, так что -msse2 - лишнее:)

У нас теперь всё проверить можно :)

$ gcc -march=pentium4 -Q --help=target|grep sse
-mno-sse4 [включено]
-msse [выключено]
-msse2 [выключено]
-msse3 [выключено]
-msse4 [выключено]
-msse4.1 [выключено]
-msse4.2 [выключено]
-msse4a [выключено]
-msse5 [выключено]
-msseregparm [выключено]
-mssse3 [выключено]

>Я жестоко обломан :) Пойду включать вручную :)

Ага, я тоже чё-то неправильно понял описание -march а мануале :(

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

в Qt4 были проблемы с -fexceptions и с -fvisibility=hidden
мне кажется что -gcc бы это не решил ?

да и в qt есть -config linux-icc
свой отдельный специально для Интел, так что Qt тут является исключением
единственное что требуется build key в qconfig.h подправить на GCC совместимый, иначе будет несовместимость с модулями-плагинами

а вот это еще интереснее
$ cc -march=pentium4 -msse2 -Q --help=target
-mno-sse4 [enabled]
-msse [enabled]
-msse2 [enabled]
-mmmx [disabled]



-mmmx то тоже надо задавать вручную

и это не смотря на то что -

-msse2 Support MMX, SSE and SSE2 built-in functions and
code generation

>в Qt4 были проблемы с -fexceptions и с -fvisibility=hidden

>мне кажется что -gcc бы это не решил ?

Не факт. -gcc делает только одно: даёт на выходе объектники и библиотеки, совместимые по формату с gcc, на оптимизацию кода он не влияет (почему я и говорил, что лучше включать его всегда, если только у вас не система, в которой нет кода, собранного не-gcc)

>да и в qt есть -config linux-icc

Но ведь в kde нет -config linux-icc?:)

>-mmmx то тоже надо задавать вручную

Это логично. Потому что регистры всех SSE - одни и те же. А регистры MMX - это другие регистры:)

нету, и более того cmake не особенно уважает конфигурацию из qmake

хотя кде4.2 у меня работает сейчас на 4.5 хотя и собирала на 4.4.3
надо будет очередной снапшот qt4.5 собрать icc опять будет, все равно оно в runtime а не для сборки

может и логично , но
gcc --help=target пишет о том что -msse2 включает MMX, SSE, SSE2 ,
хотя на самом деле -mmmx оно не включает , кругом обман
так что -march= -mtune= -mmmx -msse -msse2 и т п ) и не надо говорить о том , что что-то тут излишне , пусть излишне, но зато нет такого что не включено оно вдруг )

Лично мне непонятно, что phoronix сравнивает. Да, по умолчанию, Sun Studio генерит медленный код (провал в первых двух тестах), но зато быстро (выйгрыш в тестах на время сборки). Да, Sun Studio поддерживает OpenMP (выйгрыш у старых версий gcc). И какой вывод?

Согласен с человеком с opennet:
--------------------------------------------------------------
http://www.opennet.ru/openforum/vsluhforumID3/49723.html#4
В Sun Studio по умолчанию очень плохая оптимизация. Код может быть в три-четыре раза медленнее, чем для GCC, Intel, PGI, etc. Всегда необходимо использовать -fast, иначе сравнение бессмысленное. Ну вот такое вот поведение у Sun Studio. Для других компиляторов эффект -fast будет незначительным 10-30%.
--------------------------------------------------------------

С опцией -fast первый тест (правда на 32-битной Убунте) проходит с результатом 40 (на сайте 127). Сейчас сравню с результатом на OpenSolaris на тойже машине.

>А как же SPARC, PPC, ARM, MIPS и кучка ещё менее популярных? mironov_ivan ** (*) (20.02.2009 21:41:46)

+ Atmel AVR32

Всётаки чтобы не гадать на кофейной гуще предлагаю собрать что нить с -msse3 и сравнить с -mmmx -msse -msse2 -msse3
тада буит ясно, входит одно в другое или нет

да без проблем

gzip-1.3.12 :$./configure CC=cc43 CFLAGS="-march=core2 -msse3 -O2 -fomit-frame-pointer"

экземпляр 2
./configure CC=cc43 CFLAGS="-march=core2 -mmmx -msse -msse2 -msse3 -O2 -fomit-frame-pointer"


~/tmp :$cmp gz1 gz2
~/tmp :$

идентичны

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

+1. даже вчитываться не стал. сайт уже давно себя "зарекомендовал".

./configure CC=cc43 CFLAGS="-march=core2 -O2 -fomit-frame-pointer"
и вот так тоже получается точно также

вообщем, повода для гентушников срочно эмержить ворлд нет
но в любом случае паранойа с "излишним" указанием флагов лишней не будет

System Hardware
Processor: Unknown (Total Cores: 4), Motherboard: ASUSTeK P5Q, Chipset: Unknown, System Memory: 2 x 2048M DDR-1066MHz, Disk: 11GB, Graphics: GeForce 9600 GT 1024MB (720/900MHz), Screen Resolution: 1024x768

System Software
OS: OpenSolaris 2008.11 snv_101a_rc1b X86, Kernel: 5.11 (i686), Display Server: X.Org Server 1.3.0, OpenGL: 2.1.2 NVIDIA 177.80, Compiler: GCC 3.4.3, File-System: zfs

Test
LAME MP3 Encoding: 40.71

Параметры сборки:
$ dwarfdump ./installed-tests/encode-mp3/lame_/bin/lame | head -15

.debug_info

COMPILE_UNIT<header overall offset = 0>:
<0>< 11> DW_TAG_compile_unit
DW_AT_name main.c
DW_AT_language DW_LANG_C99
DW_AT_comp_dir /export/home/sova/.phoronix-test-suite/installed-tests/encode-mp3/lame-398-2/fr ontend
DW_AT_SUN_command_line /opt/SunStudioExpress/prod/bin/cc -DHAVE_CONFIG_H -I. -I.. -I../libmp3lame -I../include -I.. -fast -c main.c
DW_AT_SUN_compile_options Xa;O;R=Sun Ceres C 5.10 SunOS_i386 2008/10/22;backend;raw;cd;
DW_AT_producer DBG_GEN 5.2.5
DW_AT_stmt_list 0

.debug_line: line number info for a single cu
Source lines (from CU-DIE at .debug_info offset 11):

Хм... наверное там всё как то хитрее сделано. Надо буит поиграться как нить. А повод для ворлда буит наверное с выходом gcc 4.4

регрессий много, и обещается несовместимость ABI с packed структурами,
подробности можно поискать, а так в целом - производительность стала получше у кода, хотя само время сборки чуть дольше, интегрировали библиотеку Pragma Polyedra (полигональная геометрия), добавлена поддержка расширений процессоров Intel Nehalem, Westmere, Sandybridge а также новых АМД, хотя там расширений меньше

А спать не пора? :)

> ./configure CC=cc43 CFLAGS="-march=core2 -O2 -fomit-frame-pointer"
и вот так тоже получается точно также

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38749

>> Andrew, ah, right. But then, why output differs? Gentoo does not modifies this
>> bits...

> gcc driver has separate checks for CPUID features. So, it first determines CPU
> model and then adds appropriate flags, derived from CPUID.

> А спать не пора? :)

Сон не нужен? :)

Silvy, Вы меня _каждый_ день вгоняете в шок. Серьёзно. Вы просто украшение ЛОРа. Девушка, и такими постами бросаетесь. Большая, по-моему, редкость.

такие толстые новости пропускать... мда.
4.0.х - дремучая бета. Не представляю, из какого дистра её выцепили.

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

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

>> GCC 4.0.2

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

Так кризис...

> -ftree-vectorize

> для GCC

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

/me созрел для вопроса:

Silvy, а где Вы работаете?

> В убогом fpu есть 80-битные long float'ы, а в sse нет. И комбинировать пару регистров для обработки 128-битных float'ов, как у s390 или ia64, sse не умеет.

Всё. Чувствую себя идиотом.

ЗЫ. А можно я про ПХП что нибудь скажу?

Какой там спать, когда добавлена полигональная геометрия и поддержка расширений процессоров Intel Nehalem, Westmere, Sandybridge ..?!

Остановись! Не то ты такими темпами дозреешь до вопросов "Что вы делаете сегодня вечером?" и "Согласна ли ты выйти за меня замуж?".

и все таки тесты

тяп-ляп установка SunStudio получилась фейл, пришлось пустить козла в огород^W запустить инсталлер в chroot'e

gzip так и не собрался

lame - да, тесты ниже против GCC и ICC версий, флаги сборки SunStudio (-O -fast) других кажется нет особенно

cборка PHP5 , GCC 1min58s, SunStudio 5:35 и так и не залинковалось,
система упорно определяется как -gnuaout


time lame.gcc -h -V 0 --abr 128 Sunbeam_WakeUp.wav
real 0m13.428s
user 0m13.395s
sys 0m0.027s

lame.sun
real 0m14.227s
user 0m14.191s
sys 0m0.026s

intel 10.1 (тест повторила 2 раза.... так что в самом деле медленнее)
real 0m19.884s
user 0m19.805s
sys 0m0.039s

> так что в самом деле медленнее

Да он совсем не должен быть быстрее. Интел только на очень специфичном коде генерит хорошую оптимизацию, а ассемблерные вставки скорее всего не оптимизирует. Кстати, вот это интересно было бы проверить...