[2Silvy]GCC

Хм, тогда уж в догонку: как себя ведёт gcc c -march/mtune=native в 32бит системах, если проц 64? И как поглядеть эффективыне флаги, с которыми gcc будет всё собирать? Где-то ведь это проскакивало, да вот запамятовал =\

> -march=native -mtune=native -O3 -pipe -mmmx -msse -msse2 -msse3 -mssse3 -mfpmath=sse,387 -maccumulate-outgoing-args -msseregparm -minline-stringops-dynamically -fomit-frame-pointer -funsafe-loop-optimizations -ftracer -g0 -s -fmerge-all-constants -fira-region=one -fprefetch-loop-arrays -fforce-addr -fpeel-loops -ftree-loop-im -fsee -fsched-spec-load-dangerous -fsched2-use-superblocks -frename-registers -fivopts -fgcse-las -fgcse-sm -ftree-loop-linear -floop-interchange -floop-strip-mine -ftree-loop-distribution -ftree-loop-im -ftree-loop-ivcanon -fvect-cost-model -fvariable-expansion-in-unroller -fselective-scheduling2 -fsel-sched-pipelining -fsel-sched-pipelining-outer-loops -fmodulo-sched -freschedule-modulo-scheduled-loops -fmodulo-sched-allow-regmoves -fno-defer-pop -fno-ident -freorder-blocks-and-partition -fgcse-lm -fbtr-bb-exclusive -fira-coalesce -ffast-math -fno-math-errno -funsafe-math-optimizations -combine -funroll-loops -fgraphite-identity -floop-parallelize-all

Подозреваю, что в -march=native -mtune=native -O3 уже входит часть этих флагов. И -O3 часто генерирует очень большой по объёму код, который из-за этого тормозит =).

gcc -Q --help=target и так далее

Собирает 32 битный код, не используя преимуществ 64 бит

>входит часть этих флагов

Судя по проверкам, не входит.


>-O3 часто генерирует очень большой по объёму код, который из-за этого тормозит

Слышал про это, но у меня уже давно -O3 ненамного быстрее, чем -О2

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

Никто не знает, есть ли смысл собирать с -Os на последних версиях компилятора?

-march=core2 ( mtune избыточен, если равен march )
-O3
-mmx -mssse3 (либо -msse4.1 для Penryn) младшие sse включаются автоматом
-mfpmath=sse (both может создавать некоторые проблемы с несбалансированным использованием различных регистров SSE и FPU 387)

вот все -f - это на ваш страх и риск )
я использую только эти
-fomit-frame-pointer -floop-interchange -floop-strip-mine -ftree-loop-distribution -ftree-vectorize
иногда -ffast-math

>как себя ведёт gcc c -march/mtune=native в 32бит системах, если проц 64
нормально себя ведет )

смотря что собирать с -Os

я Qt4 + KDE 4 собираю с -Os (KDE - форсированно)
результат вполне хороший по снижению потребления памяти, скорость... местами заметно, хотя чаще нет

>gcc -Q --help=target

в багзилле обсуждалось, там неактуальные флаги

нужно

gcc -fverbose-asm -Q --help=target

и еще, если нужно из чего-то выжать максимум,
лучше воспользоваться Intel C/C++ с PGO (на IA32)
чем мучать GCC

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

-O2 (-Os) -fomit-frame-pointer -march= -msse? -g0 -mfpmath=sse

-floop-interchange -floop-block -floop-strip-mine -ftree-loop-distribution ( GCC 4.4)
-ftree-vectorize ( для -O2)

just IMHO

Насколько хороший?
Просто вроде вплоть до 4.3 О2 увеличивал размер кода не так уж значительно, особенно если разворачивать приходилось мало.
Да и в Qt по моему, хоть и небольшому опыту, больше жрёт память не код, а буфера под отрисовку например.

>Intel C/C++ с PGO (на IA32)

PGO в генте затруднительно сделать, да и никогда не знаешь, как профилировку осуществлять лучше.

> -floop-block

В 4.5 пока не реализовано, к сожалению.

>just IMHO

Ну ваше имхо это вполне авторитетное на ЛОРе мнение.

>Насколько

субьективно, бенчмарки не запускала особенно
все в пределах 10-20% как память, так и падение производительности,

>PGO в генте затруднительно сделать
ну это проблемы пакетного менеджера, если честно я только архиваторы с PGO собираю, ну и сам GCC (make profiledbootstrap)

>> -floop-block
>В 4.5 пока не реализовано, к сожалению.

это ключ 4.4.х , в 4.5 могли наверное временно отключить

>Ну ваше имхо это вполне авторитетное на ЛОРе мнение.

я не занимаюсь программированием ;) ирония, правда? просто хорошо учусь у других, если их мнения правильны конечно, или выглядят таковыми

Мне бы найти дистр, который умеет собирать пакеты с PGO, можно конечно в Арче шаманить с PKGBUILDами но как то не спортивно для половины софта билды править

>я не занимаюсь программированием

Я тоже. Ни капельки. Абсолютно не творческий человек.
В основном только и делаю, что ковыряюсь с настройкой.

Ладно, попробую на сейчас выделить раздел и собрать генту с KDE и -Оs

>пакеты с PGO

Слака или LFS?

на слаке самое удобное,
да и нет смысла весь дистрибутив с PGO собирать,
наиболее жадные до процессора приложения только

А почитать на эту тему ничего не посоветуешь?
А то про опции оптимизации и их влияние на производительность нигде нормально не сказано.

Да и про сборку на ноуте хочется больше узнать.

>И -O3 часто генерирует очень большой по объёму код, который из-за этого тормозит =).

плюсую. У меня из-за медленной дисковой подсистемы код O2 визуально работал быстрее.

>медленной дисковой подсистемы

Reiser4 + Gzip и в разы меньше проблем.

У меня reiser 3.6 в то время был.

Кроме того, я допустил ошибку - собрал всю систему с такими флагами.

Ещё минус - слишком много оперативной памяти расходуется.

Вот почему я больше из скриптовых языков ни ногой…

У вас свой GNU/Linux, написанный целиком на скриптах?

Я про написание мной, весь линукс я на скрипты переводить не собираюсь, вестимо :)

О, и если можете, мне подскажите:
Проц AMD Turion X2 Ultra Dual-Core Mobile ZM-82
gcc version 4.3.2 (Gentoo 4.3.2-r3 p1.6, pie-10.1.5)

В данный момент оптимизации такие: -march=native -O2 -pipe
Думаю разбавить/заменить этими: -march=k10 -mmmx -msse -msse2 -msse3 -m3dnow

Что еще стоит добавить с учетом моего процессора?

1) обновить GCC до 4.3.4 ) там исправили некоторые ошибки в том числе и с оптимизацией

-msse -msse2 -msse3 = -msse3 , младшие - излишни

-fomit-frame-pointer если не используете отладку
-mfpmath=sse , для 32 бит (на 64 - по умолчанию)


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

>Слака или LFS?
А я видел патч для emake, но мне чето ссыкотно стало его применять.

25,47c25
< # Backup of old make string
< #exec ${MAKE:-make} ${MAKEOPTS} ${EXTRA_EMAKE} "$@"
<
< PORTAGE_BIN_PATH="${PORTAGE_BIN_PATH:-/usr/lib/portage/bin}"
< PORTAGE_PYM_PATH="${PORTAGE_PYM_PATH:-/usr/lib/portage/pym}"
< source "${PORTAGE_BIN_PATH}/isolated-functions.sh" &>/dev/null
<
< # New implementation with profiling on compilation support
< if [[ $WANT_PROFILING == 1 ]] ; then
< if [[ $PROFILE_STAGE == 1 ]] ; then
< einfo "Compiling with profiling data usage."
< ${MAKE:-make} CFLAGS+="${CFLAGS_PROFILE} -fprofile-generate -fprofile-arcs -fprofile-values -fprofile-dir=${PROFILE_DIR}" LDFLAGS+="${LDFLAGS} -fprofile-arcs -lgcov" ${MAKEOPTS} ${EXTRA_EMAKE} "$@"
< elif [[ $PROFILE_STAGE == 2 ]] ; then
< einfo "Compiling binaries with profiling data gathering support."
< ${MAKE:-make} CFLAGS+="${CFLAGS_PROFILE} -fprofile-correction -fprofile-use -fbranch-probabilities -fprofile-values -fprofile-dir=${PROFILING_DIR}" ${MAKEOPTS} ${EXTRA_EMAKE} "$@"
< else
< die "Wrong argument of variable PROFILE_STAGE."
< fi
< elif [[ $WANT_PROFILING == 0 ]] ; then
< exec ${MAKE:-make} ${MAKEOPTS} ${EXTRA_EMAKE} "$@"
< else
< die "Wrong argument of variable WANT_PROFILING. Check your make.conf file."
< fi
---
> exec ${MAKE:-make} ${MAKEOPTS} ${EXTRA_EMAKE} "$@"

Я как программист авторитетно могу тебе сказать, что -O3 достаточно для всего, остальные флаги либо ничего не дают либо дают такой мизер, что невооруженным глазом заметить его нельзя.

Лучше чем задрачивать флаги компилятора перейди на 64 бита и планок памяти добавь, тогда прирост будет ощутим.

Алсо описание

Необходим gcc версии 4.4.0 и старше. Проверок переменных файла make.conf и раскидывание информации профолировщика по отдельным папкам для каждой программы будет позже.

Какие переменные надо добавить в make.conf:
CFLAGS_PROFILE="-funroll-loops -fvpt -ftracer -fpeel-loops" # Флаги оптимизации, на которые воздействует профилирование
PROFILING_DIR="/var/cache/profile" # Каталогб куда пихается информацияб выдаваемая при профилировании
WANT_PROFILING=1 # Включение/отключение сабжа
PROFILE_STAGE=1 # Номер этапа

Abstract
При первой компиляции создаются исполняемые файлы, которые в процессе своего выполнения сохраняют информацию о его ходе в каталог PROFILING_DIR. При повторной компиляции "PROFILE_STAGE=2 emerge ..." информация, полцченная в ходе работы программы используется для создания ее оптимизированной версии.

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

>Я как программист авторитетно могу тебе сказать, что -O3 достаточно для всего, остальные флаги либо ничего не дают либо дают такой мизер, что невооруженным глазом заметить его нельзя.

Я бы сказал так, что для того, чтобы оптимизация была заметна невооружённым глазом необходимо понижать порядок сложности алгоритма, это даёт самые ощутимые результаты, и это то, что компиляторы очень редко умеют. То бишь главный оптимизатор это всётаки человек. А задача компилятора это как можно сильнее понизить накладные расходы.

у GCC PGO на самом GCC дает прирост к скорости компиляции на 7-8%

>приблизится по скорости к icc это наверное круто

GCC итак неплох, особенно 4.4
тут где то тестик по обработке исключений выкладывали,
icc сильно отстал , 64 бита , говорят, хуже производительность

ну и если брать pgo, то у icc pgo обычно лучший результат дает , и если честно - большинство поползновений по оптимизации не стоят затраченного времени )
Только отдельные пакеты, остальное работает как есть и хорошо, главное это стабильность полученного кода

Но насколько я знаю PGO же не совершает никаких опасных операций, Firefox же под Виндой им собирают, что в итоге он в Вайне работает быстрее, чем нативный, и вроде не сегается

не совершает,
но pgo это существенные затраты времени, добавляются этапы
сбора статистики
перекомпиляции
+ тесты производительности, насколько вообще было оправдано все это

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

>перейди на 64 бита и планок памяти добавь

Уже 64 бита и памяти больше в ноут не запихаешь.
Но максимум из железа выжать охота.

А что там на счет graphite?

Так сам gcc стОит с PGO собрать? А то я смотрю тут ебилд 4.4.1 нарисовался. core2duo, 32 бит система.

флаги -mmx -mssse3 -mfpmath=sse бессмысленны на 64х битах

>бессмысленны

Разработчики gcc об этом и не догадываются.

вместо того чтобы спорить посмотри лучше листинг ассемблера, на x86_64 по умолчанию fpu не используется, поэтому флаги смысла не имеют

gcc -m64 -fverbose-asm -march=native -Q --help=target

?

-mfpmath=sse точно должно быть