LINUX.ORG.RU

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

 


0

1

Нужен совет познавших дзен. Имеется проц E8400 с таким набором доступных флагов

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 lm constant_tsc arch_perfmon pebs bts aperfmperf pni dtes64 monitor ds_cpl vmx smx est tm2 ssse3 cx16 xtpr pdcm sse4_1 xsave lahf_lm dts tpr_shadow vnmi flexpriority
и
clflush size	: 64
cache_alignment	: 64
на каждое ядро.

Почитал тут некоторые треды и вобщем то запутался. -msse4.1 включает все остальные? (mmmx, mssse3..etc) А то в каком то треде прочитал что они вообще не работают. Теперь про кэши:

Раньше было так

--param l1-cache-size=32 --param l1-cache-line-size=32
Сейчас надо писать --param l1-cache-size=64 --param l1-cache-line-size=64 или как? Еще насчет mfptath=sse,387 Этот оставлять? P.S. Gentoo x86, GCC-4.4.4-r2

★★★

>-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 ? и...

Sylvia ★★★★★
()
Ответ на: комментарий от Sylvia

$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

Sylvia ★★★★★
()
Ответ на: комментарий от Sylvia

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

--param l1-cache-size=32 --param l1-cache-line-size=64
Флаги с нативом такие
-march=core2 -mcx16 -msahf -msse4.1

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

-fomit-frame-pointer -ftree-vectorize -pipe
были их тоже оставить лучше?

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

partyzan ★★★
() автор топика
Ответ на: комментарий от partyzan

> -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



Sylvia ★★★★★
()
Ответ на: комментарий от Sylvia

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

Sylvia ★★★★★
()
Ответ на: комментарий от partyzan

--param ggc-min-heapsize=262144

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

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

Sylvia ★★★★★
()
Ответ на: комментарий от Sylvia

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

Собираю 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
gcc определяет L1=64 L2=512

anon_666
()
Ответ на: комментарий от anon_666

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

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

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


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

Sylvia ★★★★★
()
Ответ на: комментарий от anon_666

-funroll-loops

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

partyzan ★★★
() автор топика
Ответ на: комментарий от Sylvia

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

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

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

anon_666
()
Ответ на: комментарий от partyzan

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

anon_666
()
Ответ на: комментарий от anon_666

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


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


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

Sylvia ★★★★★
()
Ответ на: комментарий от partyzan

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

Sylvia ★★★★★
()

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

linuxfan
()
Ответ на: комментарий от anon_666

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

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


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

madcore ★★★★★
()
Ответ на: комментарий от Sylvia

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

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

-march=k8 -O3 -funroll-loops -fno-inline
Проверял ~15 раз ;)

anon_666
()
Ответ на: комментарий от linuxfan

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

partyzan ★★★
() автор топика
Ответ на: комментарий от linuxfan

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

Sylvia ★★★★★
()
Ответ на: комментарий от Sylvia

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

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

anon_666
()
Ответ на: комментарий от Sylvia

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

anon_666
()
Ответ на: комментарий от anon_666

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


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

Sylvia ★★★★★
()
Ответ на: комментарий от anon_666

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

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

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

Sylvia ★★★★★
()
Ответ на: комментарий от Sylvia

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

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

//fix

anon_666
()
Ответ на: комментарий от anon_666

и вправду чуть быстрее, проверила на 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


Sylvia ★★★★★
()
Ответ на: комментарий от Sylvia

ну и чтобы было не скучно - 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

Sylvia ★★★★★
()

У меня практически такой же процессор (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

Insomnium ★★★★
()
Ответ на: комментарий от Insomnium

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

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

Sylvia ★★★★★
()
Ответ на: комментарий от Insomnium

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

Sylvia ★★★★★
()
Ответ на: комментарий от Insomnium

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

Sylvia ★★★★★
()
Ответ на: комментарий от Insomnium

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

partyzan ★★★
() автор топика
Ответ на: комментарий от partyzan

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

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


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

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

наверное

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


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

Sylvia ★★★★★
()
Ответ на: комментарий от Sylvia

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

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

devl547 ★★★★★
()
Ответ на: комментарий от devl547

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

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

Sylvia ★★★★★
()
Ответ на: комментарий от Sylvia

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

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"

partyzan ★★★
() автор топика
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.