[2Sylvia or megabaks][GCC] Флаги и кеши.

>-msse4.1 включает все остальные

да, кроме -mmmx ( -msse -msse2 -msse3 -mssse3 -msse4.1 )

--param l1-cache-line-size=32

вы уверены что 32 ?

скомпильте hello_world
с gcc -v -march=native -O2
все --param будут в выводе

Еще насчет mfptath=sse,387 Этот оставлять

-mfpmath=sse,387 оставлять, ничего плохого.

// почему в talks ? и...

$cc44 -v -O2 -march=native ~/wrk/hello.c
Using built-in specs.
...
/usr/local/gcc-4.4/libexec/gcc/i586-sylvia-linux/4.4.5/cc1 -quiet -v /home/sylvia/wrk/hello.c -march=core2 -mcx16 -msahf -msse4.1 --param l1-cache-size=32 --param l1-cache-line-size=64 --param l2-cache-size=6144 -mtune=core2 -quiet -dumpbase hello.c -auxbase hello -O2 -version -o /tmp/cc5IXfLL.s

$uname -p
Intel(R) Core(TM)2 Duo CPU E8400 @ 3.00GHz


-march=native развертывается в
--param l1-cache-size=32 --param l1-cache-line-size=64 --param l2-cache-size=6144
-march=core2 -mcx16 -msahf -msse4.1 -mtune=core2

по кешам сказал

--param l1-cache-size=32 --param l1-cache-line-size=64

-march=core2 -mcx16 -msahf -msse4.1

-mcx16 оставить? У меня еще там

-fomit-frame-pointer -ftree-vectorize -pipe

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

Опередили :)

> -mcx16

CMPXCHG16B на 32 битных платформах не используется, флаг не мешает, но и не используется cmpxchg8b
что это такое можно почитать тут http://ru.wikipedia.org/wiki/%D0%A1%D1%80%D0%B0%D0%B2%D0%BD%D0%B5%D0%BD%D0%B8...

для cmpxchg8b отдельного флага нет, возможно что используется -march

-fomit-frame-pointer

если не нужна отладка ( x86 )

-ftree-vectorize

на ваш риск (проблемы стабильности), хотя в Gentoo наиболее капризные пакеты игнорируют небезопасные флаги

-pipe

если много памяти, для многопоточной сборки C++ с большими тяжелыми исходниками лучше -pipe в CXXFLAGS не задавать, только в CFLAGS, лучше использовать tmpfs для /tmp

не завершила мысль,
замена cmpxchg16b на 32 битных платформах - cmpxchg8b

Спасибо. /tmp уже в tmpfs.

--param ggc-min-heapsize=262144

лучше вот такой параметр попробуйте подставить )

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

Раз уж разговор зашёл..

Собираю bzip2 так:
gcc -march=k8 ...
по быстродействию уровни оптимизации отличаются так(в порядке увеличения)
O3 < O2 < Os

Если добавить -fno-inline, получаем наоборот, те
Os < O2 < O3
Те O2 и O3 быстрее с -fno-inline.

Однако, добавление -funroll-loops в _каждом_ случае даёт ускорение.

Задание размера кэша, аналогично тому, что задаётся автоматом при -v -O* -march=native, не даёт ничего, бинарники идентичны.

Код не влазит в кэш? gcc неверно определяет размер кэша?

Собственно, проц:

processor	: 0
vendor_id	: AuthenticAMD
cpu family	: 17
model		: 3
model name	: AMD Sempron(tm) SI-42
stepping	: 1
cpu MHz		: 1050.000
cache size	: 512 KB
fpu		: yes
fpu_exception	: yes
cpuid level	: 1
wp		: yes
flags		: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 syscall nx mmxext fxsr_opt rdtscp lm 3dnowext 3dnow constant_tsc rep_good nonstop_tsc extd_apicid pni cx16 lahf_lm extapic cr8_legacy 3dnowprefetch osvw skinit
bogomips	: 4199.82
TLB size	: 1024 4K pages
clflush size	: 64
cache_alignment	: 64
address sizes	: 40 bits physical, 48 bits virtual
power management: ts ttp tm stc 100mhzsteps hwpstate

>Те O2 и O3 быстрее с -fno-inline.

возможно что для данного конкретного кода, возможно из за размеров кеша
в общем случае лучше все ж таки -finline

Однако, добавление -funroll-loops в _каждом_ случае даёт ускорение.

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

-funroll-loops

Когда то было много проблем с разворотом циклов. Особенно мне кажется такой флаг не очень то для процов с малым l2 кешем.

>данного конкретного кода
Эх, хотелось бы разобраться ;)

возможно из за размеров кеша

Отключение выравнивания -fno-align* уменьшает секцию кода,
но не ускоряет, странно.

На архиваторах и на этом проце всегда ускоряет, факт.

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

Отключение выравнивания

конечно уменьшает, nop не вставляются, а то что не ускоряет... на современных процессорах так и должно быть, начиная с Pentium IV (не знаю как точно ситуация с AMD, но и там примерно также должно быть)

если размеры кешей заданы , то почему бы и нет ?

Вот тебе совет: не парься. Из этих флагов можно выжать максимум +1% производительности. Это даже не отобьет время на пересборку мира (если ты гентушник).

>Отключение выравнивания -fno-align* уменьшает секцию кода,

но не ускоряет, странно.

Переход на невыравненный адрес требовал дополнительных циклов еще на 386.

И не замедляет, проверял кучу раз.

на <pentium4 бы замедляло

В общем, сойдёмся на тестировании флагов относительно конкретного приложения.

bzip2 наиболее быстро работает так:

-march=k8 -O3 -funroll-loops -fno-inline

Как тебе сказать. Я не компиляю и не проверяю как с этими флагами быстрее или и как с другими у меня на это просто знаний не хватает так как я не кодер. По моему указать кэши компилятору это вполне нормально. Тем более в Gentoo сам Б*г велел.

Я не спорю же.

на отдельных пакетах конечно можно выжать больше чем 1%, но в целом возня определенно потраченного времени не стоит, и если вернуться еще раз к отдельным пакетам, то «узкие места» обычно все же пишут с использованием более эффективных методов ( SSE*/MMX asm inline) нежели полагаясь исключительно на то, как это сделает компилятор

bzip2 наиболее быстро работает с CC=icc :)

а еще быстрее если заменить его на pbzip2 )

>множества мелких постоянно вызываемых функций там быть особенно не должно

Дык вот в bzip2 как раз немало мест с inline.

У меня места на винте не хватает, чтобы его поставить - 3гига хочет (

Так двухъядерник ещё заказывать придётся, ноут же.

$du -sh /opt/intel11/
96M /opt/intel11/


только ia-32 C/C++, с подчисткой после инсталляции

там то что должно быть в инлайне, так и указано что
static __inline__

а для всего остального - не столь важно

и циклов мелких там много для -funroll-loops

Всё верно, при -fno-inline это игнорируется
Подстановки не происходит - быстрее работает.

На сжатии тарбола ядра -30сек.

//fix

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

$time ./bzip2_O2 < linux-2.6.32.25.tar > /dev/null

real 1m17.373s
user 1m17.133s
sys 0m0.201s

$time ./bzip2_noinline < linux-2.6.32.25.tar > /dev/null

real 1m13.927s
user 1m13.660s
sys 0m0.211s


а это ICC, без -march даже

$time ./bzip2_icc < linux-2.6.32.25.tar > /dev/null

real 1m1.537s
user 1m1.345s
sys 0m0.178s

ну и чтобы было не скучно - clang 2.8

$time /tmp/bzip2-1.0.6/bzip2 < linux-2.6.32.25.tar > /dev/null

real 1m21.039s
user 1m20.787s
sys 0m0.222s

У меня практически такой же процессор (E8500) :

 ┌─root@tower /home/thrash
 └─> cat /proc/cpuinfo | egrep "name|flags" | head -n 2
model name	: Intel(R) Core(TM)2 Duo CPU     E8500  @ 3.16GHz
flags		: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall lm constant_tsc arch_perfmon pebs bts rep_good aperfmperf pni dtes64 monitor ds_cpl vmx smx est tm2 ssse3 cx16 xtpr pdcm sse4_1 xsave lahf_lm tpr_shadow vnmi flexpriority

Флаги следующие:

 ┌─root@tower /home/thrash
 └─> grep CFLAGS /etc/make.conf
CFLAGS="-march=core2 -O2 -pipe -mcx16 -msahf -msse4.1 --param l1-cache-size=32 --param l1-cache-line-size=64 --param l2-cache-size=6144 -mtune=core2"
CXXFLAGS="${CFLAGS}"

Так сказать, пользуясь случаем, тоже хотелось бы узнать авторитетное мнение. :}

P.S.: Gentoo ~amd64

Да, gcc (Gentoo 4.4.5 p1.0, pie-0.4.5) 4.4.5

И наверное давно пора перелазить на -native.

интересно и что вы хотите по ним узнать ? )
нормальные флаги

-O2 -march= -msse* кеши

с учетом того что -march=native даст то же самое ) сэкономите немного места в make.conf и переменных окружения )

Ну так, профит... :} И да, -native таки выдает один в один то же самое.

если какой-то флажок будет статистически давать профит на большом количестве пакетов, если он не будет оказывать влияния на стабильность, то его включат в -O2 , если флажок будет статистически давать профит на >50% пакетов, то возможно что он появится в -O3 , per-package оптимизацию лучше оставлять разработчикам, профилирование и переписывание «узких» мест на asm - им же )
А универсального рецепта не будет.

Перебрался на amd64 почитал несколько тредов в Сильви и Мегабаксом и именно такие флаги сейчас и у меня. Добавил только -mfpmath=sse после него -msse4.1 и funrool-loops. Вроде mfpmath=sse в x86_64 уже включен, но я решил все же решил указать его. Пересобираю систему сейчас. Если будут проблемы, то от разворота циклов наверно надо будет отказаться. Да и еще вопросец, а почему -march=core2 вроде везде советуют -march=nocona ?

>Перебрался на amd64

Добавил только -mfpmath=sse

плохо читали ) -mfpmath=sse работает на amd64 по умолчанию.

Если будут проблемы, то от разворота циклов наверно

наверное

почему -march=core2 вроде везде советуют -march=nocona

еще более старые заметки поищите ) core2 поддерживается только начиная с gcc 4.3 (что разумеется не касается redhat'a с их бэкпортами), а еще nocona это первая -march= для Интел , которая имеет поддержку 64 бит (хоть в железе есть и Pentium IV с 64 битами, но для GCC минимально нужно указывать nocona)

Сильви, что скажешь по поводу -fno-buildin?

Я тут вчера Агнера Фога почитал, он сильно рекомендует вырубать встроенные в компилятор функции и использовать библотечные (у него по тестам до 5 раз прирост скорости)

реально зависит от версий, нужно смотреть по бенчмаркам,
если у кого-то получается для конкретных версий gcc/glibc быстрее с -fno-builtin значит возможно так и есть, но для других версий может быть совсем иначе, в целом если gcc собран для target i486 , а библиотеки используют определение возможностей процессора и asm вплоть до sse 4.2 , то не удивительно насчет того что с -fno-builtin будет быстрее

ядро linux кстати собирается -ffreestanding , т.е. без использования встроенных в gcc функций, и это правильно :)

Пока остановился на этих флагах.

CFLAGS="-O2 -march=core2 -msse4.1 -mcx16 -msahf -g0 --param l1-cache-size=32 --param l1-cache-line-size=64 --param l2-cache-size=6144 -pipe"

да