[loroogle] icc

хорошо, я вообщем-то больше для себя написала,
у гентушников есть похожий скрипт на перле, но без ssse3 и работает он дико медленно ( в 60 раз медленнее )

На objdump в качестве дизассемблера не всегда возможно полагаться.
У меня так(x86_64):

$ objdump -d /bin/bash |grep cpuid | wc -l
0

у меня bash собран icc , он всегда использует cpuid

objdump в качестве дизассемблера не всегда возможно полагаться.

предложите вариант лучше (и не менее доступный чем objdump из стандартного комплекта binutils)

Я так сходу не предложу, но библиотек-дизассемблеров под x86(_64) валом.

С правильными флагами GCC делает ICC почти во всех тестах.

Тьфу на вас.

Ради интереса потестируйте unrar, собранный GCC, и попробуйте собрать более быстрый unrar с помощью ICC. Ничего у вас не получится :)

Брать оптимизированный unrar здесь.

на 64 или на 32?

можно я еще раз напишу, что неинтересны моменты того что:

1) un (интереснее упаковщик, чем распаковщик)
2) rar (я предпочитаю совсем другие форматы - 7z , zip)
3) бинарник с неизвестного источника (может там с профилером сидел кто-то и на асм переписывал, а может и бяку всунули попутно)

>С правильными флагами GCC делает ICC почти во всех тестах.

Вот сиди и проверяй каждый флаг через Acovea и для каждой проги.
А мне было достаточно пересобрать icc и получить прирост скорости.

попробуйте собрать более быстрый unrar с помощью ICC.

Давай. Соберу unrar c icc, pgo, под 64 бита и под свой конкретный проц.

Ничего у вас не получится :)

троллить только так не надо

я кстати еще добавлю, компиляторы сравниваются не по одной программе,
а то тут p7zip мучали, кто-то там на хабре с povray бенчмарки делал, всегда есть как положительные результаты, так и отставание в чем-то,
так что перед тем как выбирать ICC как компилятор для чего-то, нужно определиться а стоит ли затрачивать на это время?

некоторые пакеты могут даже отключать оптимизированный MMX/SSE asm код, в случае если используется «неподдерживаемый» компилятор

с того сайта:

real   0m33.715s
user   0m5.772s
sys   0m0.060s

мой, собран gcc:

real   0m33.762s
user   0m5.772s
sys   0m0.058s

мой, собран icc:

real   0m32.815s
user   0m5.600s
sys   0m0.040s

P.S. where is your god now?

>так что перед тем как выбирать ICC как компилятор для чего-то, нужно определиться а стоит ли затрачивать на это время?

естественно, не стоит собирать им нересурсоемкую мелочь

некоторые пакеты могут даже отключать оптимизированный MMX/SSE asm код, в случае если используется «неподдерживаемый» компилятор

видать защита от MSVC, у которого другой диалект асма :)

а вообще, по дефайнам gcc и icpc отличить не так уж просто, стараться надо

>Соберу unrar c icc, pgo, под 64 бита и под свой конкретный проц.

-ipo1 не забудь :)

для фаллометрических целей еще можно поколдовать с точность арифтметики с плавающей точкой

ну зачем сразу над человеком то издеваться?

Глянь выше, я без особого шаманства обогнал его «super-puper-ultra-unrar»

-ftz козырный флаг,я гарантирую это

>Проприетарщина? :(

смотри и завидуй %)

>This option flushes denormal results to zero

стремно что-то ))

>я без особого шаманства обогнал его «super-puper-ultra-unrar»

в числодробильне часто требуется добиться максимальной производительности, а это несколько сложнее, чем обогнать gcc/gfortran :)

>стремно что-то ))

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

а ещё козырных флагов накидать?
самому долго выискивать

параллелицазия с использованием OpenMP: -openmp (но для этого нужны OpenMP директивы в коде, а в GCC это появилось недавно)

можно еще автопараллелизацию попробовать: -parallel но профит не гарантирован.

Завидовать глюкам? Ну уж нет, вот когда весь софт будут проверят на предмет копиляции icc, тогда ещё можно будет.

Вика, замучила ты меня уже.

Погляди у страницы автора, нет там никаких backdoors.

Можешь sudo на nobody сделать у бинарника, чтобы меня не смешить.

бинарники там для x86.

какой-то несжимаемый файл распаковывали? попробуйте что-то нормальное.

>вот когда весь софт будут проверят на предмет копиляции icc

нормальные разработчики без GNU головного мозга обычно проверяют

>какой-то несжимаемый файл распаковывали?

Сжатие в 3 раза - это теперь «несжимаемый»?

С*ранно. У меня ICC получается на 20% медленней.

Да и при ваших результатах ICC никак не смотрится круче. ;)

А ведь он оптимизирует как будто до упора.

>У меня ICC получается на 20% медленней.

Опции компилятора где?

>А ведь он оптимизирует как будто до упора.

Тут никто не оптимизировал до упора.
-march=core2 -msse4 -O3 -ffast-math -g0 --param l2-cache-size 256 для GCC
и -xSSE4.2 -O3 -gcc -fp-model fast=2 -no-prec-div для icc

prefetch, графиты, все остальные оптимизации - не включались.

>автопараллелизацию попробовать: -parallel
это не настолько же страшно, как -floop-parallelize-all -ftree-parallelize-loops=n ?

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

>prefetch
есть что покурить?
по-русски желательно

>графит

ЕМНИП, графит только скорость компиляции увеличивает :)

и да - обработай аву )
белые артефакты в виде ауры не айс

не-не-не
графит скорость компиляции уменьшает раза эдак в 1.5-2 (на примере хромиума)
это оптимизатор циклов - развороты-паралеллизация и прочее

>белые артефакты в виде ауры не айс

Считай это фичей)) Лениво пока этим заниматься, я go-oo под slitaz собираю.

> -xSSE4.2

FYI, в 11ом есть такая штука -xHost

аналог -march=native ?
если да - не нужно

>есть что покурить?

донской) и документацию.
http://software.intel.com/en-us/articles/use-software-data-prefetch-on-32-bit...
http://software.intel.com/en-us/articles/optimize-prefetch-on-32-bit-intel-ar...
http://software.intel.com/en-us/articles/how-to-choose-between-hardware-and-s...

>-xHost

Читал. Как-то не впечатлился. Разницы с xSSE4.2 вроде нет.

так - и много профита даёт?

т.е. даже шшупать не стОит? :)

>и много профита даёт?

Много. Если вручную лопатить код в поисках узких мест.

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

>уж лучше тогда переписывать

как вариант) но в этом случае придется переписать половину юзерспейса ибо тормозит)

так - ты мне лучше скажи вот что
тупо натыкать флажков(не раскуривая кода) может дать профит/регресс?

Может как профит (если шина простаивает), так и регресс (если шина и так забита данными)

Если кратко:
Вместо посчитали-загрузили из памяти-посчитали-и.т.д. будет
запустили префетч-посчитали-посчитали-посчитали (а данные для следующей итерации цикла будут грузиться заранее)

а теперь не по-древне_индейски
чем должен заниматься софт для получения профита от prefetch?

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