[бенчмарк] gcc vs icc

а когда icc научится под ARM работать?

p.s. на производительность давно пох

> p.s. на производительность давно пох

Расскажи это тем, кто десятками часов перекодирует видео или месяцами что-то считает на кластерах. Я уверен - им далеко не пох на прирост производительности в 20% =).

>p.s. на производительность давно пох

бррр

не интересно, тем более с rm -rf

ICC Core2, PGO 32 bit

vs

64 bit GCC 4.3.3 -march=nocona -msahf -msse3 без PGO

сливает около 10%

хотя тот же lzma32 c2/pgo быстрее GCC компилированого варианта на 10-12%
вот и все сравнение...

на десктопе и в разнородных средах в целом оптимизация предоставляемая GCC достаточно удовлетворительная

а вот для специализированых проектов, сборка конечно желательна оптимальным образом

ICC + вся оптимизация для архитектуры (32 или 64 бит Интел) + PGO

Интел потому что ICC для ARM и прочего нет и как оно ведет себя на АМД не совсем понятно, будет прирост или не будет.

>кто десятками часов перекодирует видео

обычно у них видео, которое непересмотреть и за всю жизнь

>месяцами что-то считает на кластерах.

там алгоритм важнее

>бррр

+/- 20% не влияют

>+/- 20% не влияют

Сказал глупость и рад?

>Сказал глупость и рад?

точняк

Хотеть быстрый отклик системы!

Для этого мы берём Reiser4, tmpfs, много-много памяти, собираем всё с -z now, выкидываем иксы, на их место втыкаем Wayland и... не, нас не тошнит от cairo, мы думаем как быстро всё не работает!

--disable-mmx --disable-mmx2 --disable-sse --disable-ssse3 --disable-yasm
icc configuration compiled with --cpu=core2 --parallel

вот за это незачет автоматом
сравнить код без расширений с математикой на 387
с тем что раскидал ICC используя ssse3 , все это очень и очень некорректно

и еще
на multimedia кодеках не совсем корректно заниматься тестированием производительности компилятора, результаты неточные из за того , что
в кодеках обычно кусочки на ассемблере попадаются, причем для наиболее нагружающих функций

лучше тестировать с помощью архиватора

gzip (c)
lzma (c++)

>gzip (c)

Часть функций на Асме. Хотя есть и патчи ;)

Быть может bzip2 пойдёт.

> --disable-mmx --disable-mmx2 --disable-sse --disable-ssse3 --disable-yasm
> icc configuration compiled with --cpu=core2 --parallel

> вот за это незачет автоматом
> сравнить код без расширений с математикой на 387
> с тем что раскидал ICC используя ssse3 , все это очень и очень некорректно

Какраз таки корректно ИМХО. Этими опциями --disable-* (они не для компилятора, а для configure-скрипта) выключили ассемблерные вставки в ffmpeg. И тем самым доверили полностью всю оптимизацию копиляторам.

> на multimedia кодеках не совсем корректно заниматься тестированием производительности компилятора, результаты неточные из за того , что
> в кодеках обычно кусочки на ассемблере попадаются, причем для наиболее нагружающих функций

Именно для этого ассемблерные вставки и выключили.

>Этими опциями --disable-* (они не для компилятора, а для configure-скрипта) выключили ассемблерные вставки в ffmpeg.

Разве часть кода попросту не переписана на асме? Хоть и под несколько архитектур..

> Разве часть кода попросту не переписана на асме? Хоть и под несколько архитектур..

Там для всего кода на асме есть аналог на чистом C. На случай если под конкретную архитектуру ещё не успели переписать на асме или там это вообще не имеет смысла (SIMD есть не везде).

в gzip как раз нету, в bzip2 есть

одно дело если в configure они отключали
другое дело если они так и собрали, если собрали - незачет
если ради того чтобы отключить ассемблер - сойдет )

>в gzip как раз нету, в bzip2 есть

http://www.linuxfromscratch.org/hlfs/view/unstable/glibc-2.6/chapter05/gzip.html

"By default Gzip uses assembly code. While this may preform better, it is not position independent. The assembly code causes text relocation which is disallowed by options in PaX/Grsec kernels. The DEFS environment variable is set to use only C code."

http://gentoo-portage.com/AJAX/Ebuild/49540/View

Не стоит спорить :) Я редко говорю то, в чём не уверен.

gzip 1.3.x

lib/match.c
/* match.s -- optional optimized asm version of longest match in deflate.c

нда, придется для тестов искать место где это optional отключается и включается альтернатива на C

иначе не совсем честный и полный тест выходит

>искать место где это optional отключается

Сходи по первой ссылке: там показано как собрать только из С-кода ;)

странно сделали ) обычно делают

--disable-asm в configure

спасибо, а то я обычно компилятор на gzip'e или lzma (хм, а там случаем в LZMA SDK не затесалось ничего?) мучаю, получается что часть функций для сравнения выпадает, и сравнение идет только по менее используемым функциям, что приводит к усреднению результата.

Кстати, посмотри в сторону lame.

~/tmp :$pipebench < test | time ./gzip.asm > /dev/null
Summary:
Piped 634.74 MB in 00h00m36.86s: 17.21 MB/second
35.83user 0.25system 0:36.85elapsed 97%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+0outputs (0major+214minor)pagefaults 0swaps

~/tmp :$pipebench < test | time ./gzip.noasm > /dev/null
Summary:
Piped 634.74 MB in 00h00m26.60s: 23.85 MB/second
25.95user 0.13system 0:26.61elapsed 98%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+0outputs (0major+214minor)pagefaults 0swaps


и весьма неожиданный результат... assembler замедляет !? ;)

~/tmp :$pipebench < test | time ./gzip.noasm.icc > /dev/null
Summary:
Piped 634.74 MB in 00h00m24.97s: 25.41 MB/second
24.32user 0.12system 0:24.97elapsed 97%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+0outputs (0major+247minor)pagefaults 0swaps

ICC 10.1

Также, я бы посмотрел на XZ Utils. Это пятая версия формата LZMA. Чуть сильнее, вроде). http://tukaani.org/xz/

Бенчмарк прилагается: http://tukaani.org/lzma/benchmarks

смотрела, но пока-что у XZ распространенность не очень, в отличие от предыдущих lzma , в принципе там есть совместимость со старым форматом
--lzma1
--lzma2 (новый, он же по умолчанию)
ключики

ну и не знаю как там чуть сильнее, был бы он чуть быстрее ) Ну и код раскидать на SMP было бы совсем неплохо, 7-zip , который использует тот же lzma способен работать на 2 ядрах, правда не полностью утилизует, но хоть что-то

переделала тест с странностями (еще 3 измерения для каждого)

asm 24.73 MB/second
noasm 23.87 MB/second

видимо это 1% в нагрузке на процессор так сказался, что-то помешало )

>код раскидать на SMP было бы совсем неплохо

В gcc-4.4 уже встроен код из проекта Graphite, так что скоро мы сможем наблюдать прирост в 30-40% на некоторых задачах, AFAIR :)

этот прирост включен всегда для любого кода или надо флажки ставить отдельные или нужна поддержка в коде #pragma и т п ?

и что лучше PPL или Cloog ? 4.4.0-experimental вроде поддерживает либо то, либо другое.
У меня с PPL , который собран ICC ;)

ps: регрессий пока много,
mplayer например новым gcc полностью не собирается, на один какой то файл выдает ошибку, хотя все остальное собирается и работает

wine собирается, но работает плохо, в windows приложениях ошибки памяти часто и вообще глюки

Сейчас версии 4.4 нет, так что сказать не могу.

у меня снапшот от 2009 02 28

последний лежит на ftp - от пятницы 13 ) соберу сейчас

>mplayer например новым gcc полностью не собирается, на один какой то файл выдает ошибку, хотя все остальное собирается и работает

Гугление по ошибке не помогло? Думаю, патч уже есть.

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

хотя вот оно, текущий транк mplayer

In file included from liba52/imdct.c:728:
liba52/imdct_3dnow.h: In function 'T.43':
liba52/imdct_3dnow.h:289: error: can't find a register in class 'GENERAL_REGS' while reloading 'asm'
liba52/imdct_3dnow.h:283: error: can't find a register in class 'GENERAL_REGS' while reloading 'asm'
liba52/imdct_3dnow.h:289: error: can't find a register in class 'GENERAL_REGS' while reloading 'asm'
liba52/imdct_3dnow.h:283: error: can't find a register in class 'GENERAL_REGS' while reloading 'asm'
liba52/imdct_3dnow.h:289: error: can't find a register in class 'GENERAL_REGS' while reloading 'asm'
liba52/imdct_3dnow.h:283: error: can't find a register in class 'GENERAL_REGS' while reloading 'asm'
liba52/imdct_3dnow.h:289: error: can't find a register in class 'GENERAL_REGS' while reloading 'asm'
liba52/imdct_3dnow.h:257: error: can't find a register in class 'GENERAL_REGS' while reloading 'asm'
liba52/imdct_3dnow.h:283: error: can't find a register in class 'GENERAL_REGS' while reloading 'asm'
liba52/imdct_3dnow.h:289: error: can't find a register in class 'GENERAL_REGS' while reloading 'asm'
liba52/imdct_3dnow.h:257: error: can't find a register in class 'GENERAL_REGS' while reloading 'asm'
liba52/imdct_3dnow.h:117: error: 'asm' operand has impossible constraints
liba52/imdct_3dnow.h:283: error: 'asm' operand has impossible constraints
liba52/imdct_3dnow.h:286: error: 'asm' operand has impossible constraints
liba52/imdct_3dnow.h:286: error: 'asm' operand has impossible constraints
liba52/imdct_3dnow.h:289: error: 'asm' operand has impossible constraints
liba52/imdct_3dnow.h:292: error: 'asm' operand has impossible constraints
liba52/imdct_3dnow.h:292: error: 'asm' operand has impossible constraints
liba52/imdct_3dnow.h:93: error: 'asm' operand has impossible constraints
liba52/imdct_3dnow.h:117: error: 'asm' operand has impossible constraints

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

Возможно, проблема с liba52.

Я бы не стал собирать его gcc-4.4 без упоминания в рассылке факта работоспособности, как минимум)

Есть необходимость в использовании gcc-4.4 для mplayera?

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

необходимости тоже особенно нет, собираю просто ради проверки собираемости и работоспособности.
А так обычно - 4.3.3

Код только недавно принят. Да и я не уверен что само распараллеливание циклов включается автоматом: попадалось на глаза упоминание о использовании отдельной опции компилятора.

Но проще посмотреть, чем гуглить ;)

Вспоминается как собирал ради слежения за прогрессом и профита... Это затягивает)

> +/- 20% не влияют

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

> и весьма неожиданный результат... assembler замедляет !? ;)

компиляторы уже давно многие вещи умеют оптимизировать лучше человека