GCC 4.1.2

> Нах тебе ядро icc-шкой собирать ? Ты часом не "аптимизатор" ? ;)

bleeding-edge masochist

> > Нах тебе ядро icc-шкой собирать ? Ты часом не "аптимизатор" ? ;)

> bleeding-edge masochist

просьба отписать о результатах дополнительно на форуме :) тема интересная.

Не трудитесь компилировать ядро icc. Даже если вы его скомпилируете (для этого придется чуть подправить несколько mакe-файлов), кроме "Uncompressing Linux....." вы ничего не увидите. Эта задача _сложная_ (потому как ядро - программа весьма специфическая), и необходимость ее решения вовсе не очевидна.

Другое дело user-space софт. Intel С имеет хорошую математическую библиотеку (чтоб ее запользовать, надо вместо math.h включать mathimf.h и вместо -lm говорить -limf (добавляется по умолчанию) и возможно еще -lsvml) и хороший векторизатор. Отсюда следует, что в вычислительных задачах он может иметь преимущество.

Пример. Несжатый архив исходников OpenOffice имеет размер около 1 Гб. Собранный gcc 4.1.1 bzip2 сжимал его около 8 минут, а icc 9.1 - около 7 мин. С gzip'ом выигрыш тоже есть, но менее заметный (P4 3.2GHz с HT).

Еще из моей практики icc хорошо помог lame и flac. Цифр сейчас не помню, но могу попозже посмотреть если кому интересно.

>Если новое не нужно, то не стоит переходить на новый софт. Я лично на gcc-4 потому, что он поддерживает новые флаги для g++

то бишь смысла если используются довольно скромные CFLAGS в переходе нет? или какие-то преимущества (типа более быстрой компиляции или большей производительности при стандартных опциях) все-таки есть? А то как-то не хочется пересобирать всю систему, ради циферок в gcc --version.

Использую CFLAGS=-march=athlon-xp -O2 -pipe -msse -mmmx -m3dnow -mfpmath=sse -ggdb.

Раньше собирал с -О3, но после того как обнаружил, что gimp собранный с -О3 стабильно сегфолтится при закрытии окошек, а с -О2 нет, решил сменить.

> Компилятор подключает дофига свих библиотек. Если ты напишешь "Hello LOR" тыщу мульенов раз и работать будет быстрее, то вся разница будет в библиотеках, а они в intel'е собствеенные

Улыбнуло. Причём здесь библиотеки, которые подключаются к компилятору??? Это дело реализации КОМПИЛЯТОРА.

По большому счёту задача компилятора сводится к преобразованию:

Исходный код -> бинарник

А уж бинарник никто мне не мешает дизассемблировать и узнать, чего же там такого "наоптимизировано".

> Раньше собирал с -О3, но после того как обнаружил, что gimp собранный с -О3 стабильно сегфолтится при закрытии окошек, а с -О2 нет, решил сменить.

Убирать -mfpmath=sse не пробовал?

И каким же образом будете узнавать? Вот, допустим, есть уравнение и есть ответ. Что, сможете определить метод решения?

>Убирать -mfpmath=sse не пробовал? пробовал, толку ноль. тем более что с -О2 проблема исчезает (при наличии все того же -mfpmath=sse). кроме того я очень сильно сомневаюсь, что в коде который отвечает за gui где-то есть floating point operations.

> -msse -mmmx -m3dnow

И как вы _это_ используете ? ;)

А в чём проблема? У меня тоже такое сочетание (плюс -msse2), пока что не жалуюсь.

> Вот, допустим, есть уравнение и есть ответ. Что, сможете определить метод решения?

Честно говоря, не вижу аналогии между уравнением и дизассемблированным машинным кодом.

Вот, допустим, есть две одинаковые программы, собранные на разных компиляторах. Если программы достаточно простые без всяких глобальных псевдоинтелликтуальных оптимизаций то можно заметить, что в одном случае в одинаковой ситуации использованы одни регистры, в другом - другие; в одном случае переход такой - в другом другой, так же можно обратить внимание, что стек в одной программе используется "как-то хитро" - регистры заталкиваются в строго определённом "нелогичном" порядке, который на самом деле более чем логичен с точки зрения производителя процессора, сделать выводы об оптимизации прог для соответствующих процев, ну и т.д.

Так, где вы говорите здесь уравнение ? :-)

>А в чём проблема?

В непрочтении info gcc ;)

>У меня тоже такое сочетание (плюс -msse2), пока что не жалуюсь.

На что не жалуетесь ?

Часто пользуете v4sf __builtin_ia32_loadaps (float *) blah-blah-blah ? :)

>> -msse -mmmx -m3dnow

>И как вы _это_ используете ? ;)

Это полезно дополнительно указывать для того, чтобы -mfpmath=sse работал, т.к. иногда скрипты в некоторых пакетах стрипают -march, а потом компилятор ворнинги бросает на mfpmath=sse

Читал, естесственно. Вы имеете в виду, что одно указание этих опций не заставляет gcc использовать расширенные наборы инструкций? Судя по man/info это не так:

`-mmmx' `-msse' `-msse2' `-msse3' `-m3dnow'

These switches enable or disable the use of instructions in the MMX, SSE, SSE2 or 3DNow! extended instruction sets.

...

These options will enable GCC to use these extended instructions in generated code, even without `-mfpmath=sse'.

> Intel С имеет хорошую математическую библиотеку

Точно. Но кстати, в gcc 4.3 собираются улучшить математику, и не только. http://gcc.gnu.org/gcc-4.3/changes.html там всё понятно. Быстрей бы, а то год наверное ждать...

>Это полезно дополнительно указывать для того, чтобы -mfpmath=sse работал, т.к. иногда скрипты в некоторых пакетах стрипают -march, а потом компилятор ворнинги бросает на mfpmath=sse

Пожалуй единственное применение ;) если не юзать встроеные векторные функции вручную ;)

А сейчас точная цитата из мана ;)
--------
  -mmmx
       -mno-mmx
       -msse
       -mno-sse
       -msse2
       -mno-sse2
       -msse3
       -mno-sse3
       -m3dnow
       -mno-3dnow
           These switches enable or disable the use of ___built-in_functions___(sic!) that allow direct
           access to the MMX, SSE, SSE2, SSE3 and 3Dnow extensions of the instruction set.

           To have SSE/SSE2 instructions generated automatically from floating-point code, see
           -mfpmath=sse.

Нет, пожалуй всё же у вас либо неправильный ман, либо старый GCC. А цитату я привёл точную. Вот полностью:

       -mmmx
       -mno-mmx
       -msse
       -mno-sse
       -msse2
       -mno-sse2
       -msse3
       -mno-sse3
       -m3dnow
       -mno-3dnow
           These switches enable or disable the use of instructions in the MMX, SSE, SSE2 or 3DNow! extended instruc‐
           tion sets.  These extensions are also available as built-in functions: see X86 Built-in Functions, for
           details of the functions enabled and disabled by these switches.

           To have SSE/SSE2 instructions generated automatically from floating-point code (as opposed to 387 instruc‐
           tions), see -mfpmath=sse.

           These options will enable GCC to use these extended instructions in generated code, even without -mfp‐
           math=sse.  Applications which perform runtime CPU detection must compile separate files for each supported
           architecture, using the appropriate flags.  In particular, the file containing the CPU detection code
           should be compiled without these options.


$ gcc -dumpversion
4.1.1

>4.1.1

3.4.6

но это сути не меняет

почувствуй разницу между _enable_use_ и _generated_automatically_

Почувствуй разницу между "instructions generated automatically" и "will enable GCC to use these extended instructions in generated code".

rpm -qa | grep gcc-4.1 gcc-4.1.3-29

Из коробки.

В смысле:

rpm -qa | grep gcc-4.1
gcc-4.1.3-29

Из коробки.
Долбаное форматирование.

Заипали словом "open source".

>>А что лучше по производительности GCC 4.x или Intel compiler? >INtel. но он только для соответствующих процов.

А вот и неправда. Для AMD он тоже очень хорош!

>Почувствуй разницу между "instructions generated automatically" и "will enable GCC to use these extended instructions in generated code".
---
Держи пример:
----------
#!/bin/bash
cat << CODE > /tmp/test.c
int test() {
int a,b,c,d,e,f,g,h,i,r;
a=b=c=d=e=f=g=h=r=5;
for(i=0;i<10;i++) {
 a++;
 b++;
 c++;
 d++;
 e++;
 f++;
 g++;
 h++;
 r=a+b+c+d+f+g+h;
 }
 return r;
}
CODE
gcc -mmmx -c /tmp/test.c -S -o /tmp/test_mmx.S
gcc -c /tmp/test.c -S -o /tmp/test.S
diff -uN /tmp/test_mmx.S /tmp/test.S
-----------

PS: сказаное тобой верно только для -msse/-msse2/-msse3

>> -msse -mmmx -m3dnow
>И как вы _это_ используете ? ;) 

а где в мане или инфо написано что -march=athlon-xp подразумевает -mmmx и прочее? нигде.
------
       -mtune=cpu-type
           Tune to cpu-type everything applicable about the generated code, except for the ABI and the set of available instructions.  The
           choices for cpu-type are:
........
           athlon-4, athlon-xp, athlon-mp
               Improved AMD Athlon CPU with MMX, 3dNOW!, enhanced 3dNOW! and full SSE instruction set support.
........
       -march=cpu-type
           Generate instructions for the machine type cpu-type.  The choices for cpu-type are the same as for -mtune.  Moreover, specifying
           -march=cpu-type implies -mtune=cpu-type.
------

а если не документировано, значит может и поменятся в какой-нибудь версии. 
хотя конечно если запустить 
gcc -march=athlon-xp -v -Q test.c
то напечатает:

....
options passed:  -v -march=athlon-xp -auxbase
options enabled:  -falign-loops -fargument-alias -fbranch-count-reg
 -fcommon -feliminate-unused-debug-types -ffunction-cse -fgcse-lm -fident
 -finline-functions-called-once -fivopts -fkeep-static-consts
 -fleading-underscore -floop-optimize2 -fmath-errno -fpcc-struct-return
 -fpeephole -fsched-interblock -fsched-spec -fsched-stalled-insns-dep
 -fsplit-ivs-in-unroller -ftrapping-math -ftree-loop-im -ftree-loop-ivcanon
 -ftree-loop-optimize -fvar-tracking -fzero-initialized-in-bss -m80387
 -mhard-float -mno-soft-float -mieee-fp -mfp-ret-in-387
 -maccumulate-outgoing-args -mmmx -m3dnow -msse -mno-red-zone
 -mtls-direct-seg-refs -mtune=athlon-xp -march=athlon-xp
....

в любом случае хуже от этих ключиков не будет.

> Держи пример:

> gcc -mmmx -c /tmp/test.c -S -o /tmp/test_mmx.S

Пардон, где в приведённом Вами примере можно применить MMX ?

>в любом случае хуже от этих ключиков не будет.

Угу. От них ничего не будет ;)

>Пардон, где в приведённом Вами примере можно применить MMX ?

Ну напиши свой ;)

Хорошо, оставим в покое уравнение. У вас есть наборы исходных текстов и соответствующие им наборы машинных кодов. Вам нужно указать правило, по которому исходному тексту ставится в соответствие машинный код. Проще говоря, у вас есть черный ящик, которому вы скармливаете исходный текст, а он вам выдает машинный код. Нужно узнать алгоритм, по которому фунциклирует этот ящик. Я правильно понимаю задачу?

/ сказаное тобой верно только для -msse/-msse2/-msse3

Ну, в высмеянном тобой наборе флагов -msse тоже есть. Насчёт MMX/3DNow
я вообще не уверен, если GCC его где-то применяет и какие выражения он
при этом заменяет. Внятного примера по SSE у меня не получится, т.к.
мой GCC врубает -msse и -msse2 для всех архитектур. Но, например,
-mno-sse благополучно вырубает использование SSE и код отличается от
собранного с дефолтными флагами. Т.е. то, что код не отличается вне
зависимости от присутствия флага -msse, означает лишь то, что GCC его
использует по умолчанию.

$ cat test.c
int main()
{
        double a = 12345.6789;
        a += 987675.12345;
        a *= a;
        a /= 987876123.;
        return 0;
}

$ gcc test.c -S -o test.s
$ gcc test.c -S -mno-sse -o test_nosse.s
$ diff test.s test_nosse.s
22,34c22,32
<       movlpd  -8(%rbp), %xmm1
<       movlpd  .LC1(%rip), %xmm0
<       addsd   %xmm1, %xmm0
<       movsd   %xmm0, -8(%rbp)
<       movlpd  -8(%rbp), %xmm0
<       mulsd   -8(%rbp), %xmm0
<       movsd   %xmm0, -8(%rbp)
<       movlpd  -8(%rbp), %xmm1
<       movlpd  .LC2(%rip), %xmm0
<       movsd   %xmm1, %xmm2
<       divsd   %xmm0, %xmm2
<       movsd   %xmm2, %xmm0
<       movsd   %xmm0, -8(%rbp)
---
>       fldl    -8(%rbp)
>       fldl    .LC1(%rip)
>       faddp   %st, %st(1)
>       fstpl   -8(%rbp)
>       fldl    -8(%rbp)
>       fmull   -8(%rbp)
>       fstpl   -8(%rbp)
>       fldl    -8(%rbp)
>       fldl    .LC2(%rip)
>       fdivrp  %st, %st(1)
>       fstpl   -8(%rbp)

>Ну, в высмеянном тобой наборе флагов -msse тоже есть

Зацепил при копировании ;)

он как раз влияет на дефолтовую кодогенерацию, особенно при -mfpmath=sse

Насчёт -msse "по дефолту" читай info gcc ;)

hint: добавь -m32 ;)

А в чём проблема? У меня тоже такое сочетание (плюс -msse2), пока что не жалуюсь.

А вы в курсе, что "-msse -mmmx -m3dnow" плюс "-msse2" лишь открывает возможность использования SIMD, но gcc их автоматически не использует? Можете сами проверить objdump -d путь_к_бинарю|grep mm. gcc прописывает SSE/MMX команды если ему говорят -mfpmath=sse либо -ftree-vectorize, либо пишут ассемблерную вставку, явно использующую SIMD, либо явно используют векторные расширения(что весьма редко). Т.е. без "-mfpmath=sse" и "-ftree-vectorize" для абсолютного большинства программ gcc ВООБЩЕ не использует MMX/SSE.

> Ты же не будешь кричать, что гцц во всем виноват, если ты скомпилил что-нить с march=k8 и запускаешь на PIII.

Не буду.

> А этим флагом(ftree-vectorize) ты задаешь ему принудительную векторизацию. По идее он сам векторизует, если может определить, что данные выровнены, и не векторизует, если не выровнены(при прочих равных условиях). Другое дело, что в мане это криво написано, отсюда и непонятки.

Этот флаг дает команду векторизовать данные, при этом gcc в любом случае должен собирать рабочий код для той архитектуры, под которую этот код собирается и на которой этот код запускается. Адрес для MOVAPD, команды, которую сам же компилятор и вставил ДОЛЖЕН БЫТЬ ВЫРОВНЕН по границе 128 бит, 16 байт(размер XMM-регистра) иначе - аппаратное исключение. То, что адрес не выровнен - вина компилятора - он собрал НЕРАБОЧИЙ код. Для невыровненных данных есть более медленная команда MOVUPD, которую gcc мог бы использовать.

> То, что адрес не выровнен - вина компилятора - он собрал НЕРАБОЧИЙ код. Для невыровненных данных есть более медленная команда MOVUPD, которую gcc мог бы использовать.

Я не вижу bug report'a.

>А вы в курсе, что "-msse -mmmx -m3dnow" плюс "-msse2" лишь открывает возможность использования SIMD, но gcc их автоматически не использует?

строго говоря даже с -mfpmath=387 код с -msse будет на копейку но другой, но как правильно замечено, автоматическую векторизацию по всему коду _сам_по_себе_ он не включает

> Т.е. то, что код не отличается вне зависимости от присутствия флага -msse, означает лишь то, что GCC его использует по умолчанию.

Именно. На архитектура x86_64 gcc также использует -mfpmath=sse, это и заставляет его генерировать SSE-код вместо FPU-кода.

GCC 2.95 forever. Точка.

.file "test.c" .text .p2align 4,,15 .globl test .type test, @function test: pushl %ebp movl $105, %eax movl %esp, %ebp popl %ebp ret .size test, .-test .ident "GCC: (GNU) 4.1.1 (Gentoo 4.1.1-r3)" .section .note.GNU-stack,"",@progbits

http://gentoo-wiki.com/HOWTO_ICC_and_Portage

> GCC 2.95 forever.

Каретные экипажи с лошадями forever. Точка.

Мир меняется, пора к этому привыкнуть.

Да, кстати, как вы собираете послдение версии KDE, Mplayer, Xine, kernel, glibc?

>-test .ident "GCC: (GNU) 4.1.1 (Gentoo 4.1.1-r3)"

Гента и тут отличилась ;)))))))

Если б тока на Си писали, а то ведь и С++ всё норовят...

> Проще говоря, у вас есть черный ящик, которому вы скармливаете исходный текст, а он вам выдает машинный код. Нужно узнать алгоритм, по которому фунциклирует этот ящик. Я правильно понимаю задачу?

Нет. Чёрный яшик - это процессор. Компилятор ведь тоже можно дизассемблировать. Не алгоритм нужно узнать, а ход мыслей создателей icc.

>Не трудитесь компилировать ядро icc. Даже если вы его скомпилируете (для этого придется чуть подправить несколько mакe-файлов), кроме "Uncompressing Linux....." вы ничего не увидите. Эта задача _сложная_ (потому как ядро - программа весьма специфическая), и необходимость ее решения вовсе не очевидна.

а я-то уже заинтересовался =) давно уже использую беслатный ifc под Линукс. Быстрый, зараза =)

>> Пардон, где в приведённом Вами примере можно применить MMX ?

> Ну напиши свой ;)

Честно говоря, не представляю, как это сделать без асма

>Честно говоря, не представляю, как это сделать без асма

http://gcc.gnu.org/onlinedocs/gcc-4.1.2/gcc/Vector-Extensions.html#Vector-Ext...
http://gcc.gnu.org/onlinedocs/gcc-4.1.2/gcc/X86-Built_002din-
Functions.html#X86-Built_002din-Functions

А также все SIMD-макросы(ftp://download.intel.com/support/performancetools/c/linux/v9/intref_cls.pdf) в нотации ICC также реализованы (ls /usr/lib/gcc/.../include/{emm*,mm*,xmm*}.h)

А что макросы это не тот же асм, оформленный по другому?

> А что макросы это не тот же асм, оформленный по другому?

Не совсем, там используются gcc-шные builtin-функции. По сути то и C -тот же высокоуровневый ASM, "оформленный по-другому".