судя по формату выхлопа это моя программулина :)

если в тему - GCC достаточно слабо использует векторизацию с использованием sse4

версия GCC какая ? и я бы не брала mplayer как показатель, там достаточно много кусков на asm, или orc (oil)

$ analyze-x86 bin/mplayer
instructions:
cpuid: 15 nop: 33498 call: 65236 count: 2452577
i486: 4880
i586: 4
i686: 11482
mmx: 161481
sse: 16368
sse2: 27105
sse3: 273
ssse3: 1105
sse4.1: 41
sse4a: 11
3dnow!: 1928
3dnowext: 13

Да, этот твой код который ты писала на C. Просто сначала скриптом перловым прогонял, а потом этот бинарник собрал ибо быстрее.

версия GCC какая ?

gcc-4.4.4-r2

А какой бинарь лучше взять для проверки?

перлятина тормознее в 60 раз ;)

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


с другой стороны, я бы хотела поинтересоваться, какая цель заставить GCC генерировать SSE4 ? главное чтобы производительность устраивала,
а уж есть там SSE4 средствами компилятора или нет - дело десятое.

Производительность вещь такая что она почти всегда устраивает пока не знаешь что она может быть и выше. Да и вообще все просто, железо поддерживает, то почему бы не дать возможность использовать?

в таком случае перспективнее использовать profile guided optimization,
хотя возни с этим больше чем получаемого выигрыша

вполне себе векторизует

1) -march=pentium4 -mtune=core2 -msse2 -mmmx -fomit-frame-pointer -g0 -O2 -mstackrealign -fexcess-precision=fast --param l1-cache-size=32 --param l1-cache-line-size=64 --param l2-cache-size=1024 --param ggc-min-heapsize=262144


$ analyze-x86 libpython2.6.so
instructions:
cpuid: 0 nop: 6808 call: 22427 count: 311108
i686: 893
mmx: 237
sse: 6
sse2: 1700



2) -march=core2 -msse4.1 -mmmx -fomit-frame-pointer -g0 -O2 -mstackrealign -fexcess-precision=fast --param l1-cache-size=32 --param l1-cache-line-size=64 --param l2-cache-size=2048 --param ggc-min-heapsize=262144

$analyze-x86 /usr/lib/libpython2.6.so
instructions:
cpuid: 0 nop: 6834 call: 22427 count: 311383
i686: 893
mmx: 77
sse: 6
sse2: 1723
ssse3: 97
sse4.1: 291


$gcc --version
cc /argenta/ 4.5.2
Copyright (C) 2010 Free Software Foundation, Inc.

2) еще -ftree-vectorize :)

Упс, про -ftree-vectorize забыл. Счас добавлю и попробую.

>про -ftree-vectorize забыл. Счас добавлю и попробую

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

ps: mplayer вообще-то сам должен бы собираться с -O3 -ffast-math

осторожнее, может оказывать влияние на стабильность,

Да, уже сталкивался, были проблемы с некоторыми пакетами.

Да, вы правы так оно и вышло. Собрал с -ftree-vectorize и sse4.1 появилось.

./analyse /usr/bin/mplayer 
instructions:
 cpuid: 13	 nop: 22786	 call: 46850	 count: 2224953
 i486:	 4296
 i586:	 1
 i686:	 7961
 mmx:	 223868
 sse:	 55276
 sse2:	 36069
 sse3:	 125
 ssse3:	 289
 sse4.1:	 3776
 3dnow!:	 4668
 3dnowext:	 145

Спасибо, проблема решена.

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

Я раньше частенько тестил на lame перекодируя большие mp3 и на время архивация/разорхивация bzip2. Надо и mencoder'om попробовать.

Откопал тут скачанный

Тут ошибка и поэтому она криво считает:

           if (e) { e = strtok (NULL, "\t"); /* 3rd column contains instruction */
           snprintf(itmp, 255, "%s", e);
           s = strtok (itmp, " "); /* formatting as spaces */

-=:=-

хм...в таком случае реквестирую end-release исходника..

хм...в таком случае реквестирую end-release исходника..

Присоединяюсь...

-= Афигеть =-

x86_64-pc-linux-gnu-4.6.0-alpha20101106 *

CFLAGS="-O2 -pipe -march=native -mtune=native --param l1-cache-size=32 --param l1-cache-line-size=48 --param l2-cache-size=224"

localhost analyze_x86 # ./analyze-x86.bin /usr/bin/mplayer
instructions:
cpuid: 12    nop: 9944    call: 0    count: 1325793
i486:    3912
i586:    1
i686:    6310
mmx:    75742
sse:    20868
sse2:    11616
sse3:    448
ssse3:    389
sse4.1:    3
3dnow!:    1075
3dnowext:    17

#----------------------------#

CFLAGS="-O2 -pipe -march=native -mtune=native -ftree-vectorize -msse4.1 -mmmx -fomit-frame-pointer -g0 -O2 -mstackrealign -fexcess-precision=fast --param ggc-min-heapsize=262144"

localhost analyze_x86 # ./analyze-x86.bin /usr/bin/mplayer
instructions:
cpuid: 12    nop: 10041    call: 0    count: 1397153
i486:    3912
i586:    1
i686:    7056
mmx:    85411
sse:    22907
sse2:    23181
sse3:    469
ssse3:    3889
sse4.1:    5219
3dnow!:    1075
3dnowext:    17

Чойто кол-во инструкций нехило выросло...пугающе

Было много тредов по поводу того что при -march=native надо некоторые флаги все равно включать принудительно. У Сильви спроси она лучше расскажет.

           if (e) { e = strtok (NULL, "\t"); /* 3rd column contains instruction */
+           if (!e)
+		continue;
           snprintf(itmp, 255, "%s", e);

Строки вида 81d4469: в выводе objdump печатали в itmp (null) и считались инструкциями

-= Unreal Tournament 3 =-

а вот на -msse4.2 реакции нет...или парсер не знает про них?

-=:=-

Пасиба. Патч годный.
count: 1397153 -> count: 131567

Респект, пропатчил.

версия binutils у вас какая ?

objdump --version

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

Строки вида 81d4469: в выводе objdump печатали в itmp (null) и считались инструкциями

все что парсилось по идее было с инструкциями, кроме (bad)
ее надо бы не считать, но на самом деле ... не столь важно наверное )

считает оно sse 4.2

просто GCC его не использует особенно пока


$analyze-x86 /opt/intel11/bin/mcpcom
instructions:
cpuid: 10 nop: 7181 call: 203151 count: 3007257
i586: 1
i686: 12076
mmx: 7409
sse: 7191
sse2: 11656
sse4.1: 1
sse4.2: 1

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

и то работоспособность не особенно оценить, если использованы cpuid и переключение на альтернативные ветки :)

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




cpuid: 15 nop: 33498 call: 65236 count: 2343360
GNU ld 2.21.51.20101120


cpuid: 15 nop: 33498 call: 65236 count: 2452577
GNU ld 2.20.1

версия binutils у вас какая ?

objdump --version

GNU objdump (Linux/GNU Binutils) 2.20.51.0.7.20100318, Mandriva 2010 Spring, но наверно это не важно

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

Не знаю, следующая команда выводит их приличное количество

objdump -d /usr/bin/mplayer |awk -F "\t" ' {if (NF==2) print $0}'