Премини към съдържанието

Препоръчан отговор


Тъй като в форума има предимно убунтувци, и няма много хора като мен с Gentoo/Gentoo Базирани системи, реших да направя тази тема която би била от помощ за някои бъдещи генту потребители със сходен процесор.

 

Обръщаме внимание на оптимизациите на GCC (CLANG дава по-добри резултати но все още има силно зависими от GCC пакети като Glibc).

 

/etc/portage/make.conf

CFLAGS="-O2 -march=bdver2 -mtune=bdver2 -mprefer-avx128 -mvzeroupper -pipe"CXXFLAGS="${CFLAGS}"

Малко променен от мен дизайн.

Препоръчвам добавянето на "-mprefer-avx128" (не е добавен по подразбиране, нито е отбелязан като препоръчителен), но имайки в предвид по-особения FPU дизайн на процесорите AMD FX подобрява FPU производителността.

 

"-mvzeroupper" не винаги би могъл да даде прираст в производителността на системата (даже по някога пасив), но от друга страна подобрява производителността на определени приложения като ffmpeg например.

 

"-march=bdver2" Препоръчвам тази настройка за -march и -mtune (Много хора биха казали че е най-добре да се използва -march=native но от опит казвам че не е по-добре защото)

gcc -march=native -E -v - </dev/null 2>&1 | grep cc1 /usr/libexec/gcc/x86_64-pc-linux-gnu/4.9.0/cc1 -E -quiet -v - -march=bdver2 -mmmx -mno-3dnow -msse -msse2 -msse3 -mssse3 -msse4a -mcx16 -msahf -mno-movbe -maes -mno-sha -mpclmul -mpopcnt -mabm -mlwp -mfma -mfma4 -mxop -mbmi -mno-bmi2 -mtbm -mavx -mno-avx2 -msse4.2 -msse4.1 -mlzcnt -mno-rtm -mno-hle -mno-rdrnd -mf16c -mno-fsgsbase -mno-rdseed -mprfchw -mno-adx -mfxsr -mxsave -mno-xsaveopt -mno-avx512f -mno-avx512er -mno-avx512cd -mno-avx512pf -mno-prefetchwt1 --param l1-cache-size=16 --param l1-cache-line-size=64 --param l2-cache-size=2048 -mtune=bdver2

Претрупването с прекалено много флагове от native (повечето от които са подходящи за Интел процесор), не дават прираст а само пасив.

root@CLDX [ 9:07:17 ] [ 07/20/14 ] [ pts/6 ] ~ # gcc -march=bdver2 -E -v - </dev/null 2>&1 | grep cc1 /usr/libexec/gcc/x86_64-pc-linux-gnu/4.9.0/cc1 -E -quiet -v - -march=bdver2root@CLDX [ 9:08:31 ] [ 07/20/14 ] [ pts/6 ] ~ #                         

Това е препоръчания от мен вариант с -mprefer-avx128 и -mvzeroupper

 

Така изглежда моя make.conf

root@CLDX [ 9:10:47 ] [ 07/20/14 ] [ pts/6 ] ~ # cat /etc/portage/make.conf# Compiler# Graphite LTO GCC 4.8.2 or newer# GRAPHITE="-floop-interchange -ftree-loop-distribution -floop-strip-mine -floop-block"# CFLAGS="-flto=8 ${GRAPHITE} -ftree-vectorize -O2 -march=bdver2 -mtune=bdver2 -mprefer-avx128 -mvzeroupper -pipe"# LDFLAGS="-Wl,--no-keep-memory"# LDFLAGS="${CFLAGS} -fuse-linker-plugin -Wl,--no-keep-memory"# Graphite# DefaultCFLAGS="-O2 -march=bdver2 -mtune=bdver2 -mprefer-avx128 -mvzeroupper -pipe"CXXFLAGS="${CFLAGS}"# Default# LLVM#CC="/usr/bin/clang"#CXX="/usr/bin/clang++"#LDFLAGS="-Wl,--as-needed"# LLVMMAKEOPTS="-j9 -l18"WANT_MP="true"# Compiler

ПС: Теста е правен с FX8320 но важи за всички модели FX от поколението Замбези и Вишера.

  • Харесва ми 3

Сподели този отговор


Линк към този отговор
Сподели в други сайтове

 

Обръщаме внимание на оптимизациите на GCC (CLANG дава по-добри резултати но все още има силно зависими от GCC пакети като Glibc).

 

Как точно оценяваш резултатите, само по производителност на приложенията или включваш и времето за компилирането им?

 

В тази статия се правят също тестове и се оказва, че най-бързото компилиране се получава при брой процеси равни на ядрата на процесора -j=брой ядра, а не с едно повече.

 

Спомням си за флага --fomit-frame-pointer, който също подобрявал нещата. За някои програми флага -O3 също води до увеличение на производителността в някаква степен.

 

Накратко казано, най-добрите резултати се постигат след като се тестват конкретни програми с различни настройки за компилиране, което обаче изисква доста време. Версията на компилатора GCC също има значение. Старите версии не поддържат оптимизации за новите процесори.

Сподели този отговор


Линк към този отговор
Сподели в други сайтове

Това са моите 

 

#OpenMP Оптимизацияexport OP="-fopenmp"#Без дебъг ;)export DEBUG="-g0 -ggdb0 -gstabs0 -s"export CFLAGS="-march=native -O2 -pipe -fstack-protector-strong --param=ssp-buffer-size=4 -D_FORTIFY_SOURCE=2 -mprefer-avx128 ${DEBUG} ${OP} -flto=8 -fuse-linker-plugin -fomit-frame-pointer"export CXXFLAGS="${CFLAGS}"export LDFLAGS="-Wl,-O1,--sort-common,--as-needed,-z,relro,-z,lazy ${CFLAGS} -lgomp"

Сподели този отговор


Линк към този отговор
Сподели в други сайтове

Как точно оценяваш резултатите, само по производителност на приложенията или включваш и времето за компилирането им?

 

В тази статия се правят също тестове и се оказва, че най-бързото компилиране се получава при брой процеси равни на ядрата на процесора -j=брой ядра, а не с едно повече.

 

Спомням си за флага --fomit-frame-pointer, който също подобрявал нещата. За някои програми флага -O3 също води до увеличение на производителността в някаква степен.

 

Накратко казано, най-добрите резултати се постигат след като се тестват конкретни програми с различни настройки за компилиране, което обаче изисква доста време. Версията на компилатора GCC също има значение. Старите версии не поддържат оптимизации за новите процесори.

 

За това в make.conf съм написал коментар GCC 4.8.2

-fomit-frame-pointer важи за 32 битова инсталация. -O3 е прекалено агресивна оптимизация която прави компилирането по-бавно, чупи някои пакети, като цяло системата вместо да се оптимизира става по-мудна (-O3 инак се води строга оптимизация).

И тук не говорим за скорост на компилиране, ако искаме скорост на компилиране просто ще спрем оптимизациите с "-O0"

Тук става дума за балансиране на генерирания код, конкретно за AMD FX.

Сподели този отговор


Линк към този отговор
Сподели в други сайтове
публикувано (редактирано)

-fomit-frame-pointer важи за 32 битова инсталация. -O3 е прекалено агресивна оптимизация която прави компилирането по-бавно, чупи някои пакети, като цяло системата вместо да се оптимизира става по-мудна (-O3 инак се води строга оптимизация).

Ако искаш перфектно тунингована система, слагаш флаговете за компилация на ниво пакет, не само на система. И тогава за определени пакети е съвсем допустимо да сложиш O3 и да има ефект, въпреки че за цялата система е глупаво. Въпросът е, колко иска да се занимава конкретният човек с експериментиране и тестване на системата.

Редактирано от flare (преглед на промените)

Сподели този отговор


Линк към този отговор
Сподели в други сайтове

Ако искаш перфектно тунингована система, слагаш флаговете за компилация на ниво пакет, не само на система. И тогава за определени пакети е съвсем допустимо да сложиш O3 и да има ефект, въпреки че за цялата система е глупаво. Въпросът е, колко иска да се занимава конкретният човек с експериментиране и тестване на системата.

 

-O3 прави бинарните файлове безбожно големи като обем и по-бавни вместо по-бързи.

Сподели този отговор


Линк към този отговор
Сподели в други сайтове

-O3 прави бинарните файлове безбожно големи като обем и по-бавни вместо по-бързи.

Виждал съм примери и за обратното. Изцяло зависи от конкретния код. Но отделно, никой не те кара да ползваш O3 точно. То е съвкупност от много флагове на компилатора. Може да се сложат само някои от тях и това да доведе до сериозни разлики.

  • Харесва ми 1

Сподели този отговор


Линк към този отговор
Сподели в други сайтове

Виждал съм примери и за обратното. Изцяло зависи от конкретния код. Но отделно, никой не те кара да ползваш O3 точно. То е съвкупност от много флагове на компилатора. Може да се сложат само някои от тях и това да доведе до сериозни разлики.

 

-Ofast но все пак, ако беше толкова добре да се ползват оптимизации над -O2 щеше да го пише.

 

но чета друго.

 

Извадка от Gentoo Wiki

 

 

-O

Next up is the -O variable. This controls the overall level of optimization. This makes the code compilation take somewhat more time, and can take up much more memory, especially as you increase the level of optimization.

There are seven -O settings: -O0, -O1, -O2, -O3, -Os, -Og, and -Ofast. You should use only one of them in /etc/portage/make.conf.

With the exception of -O0, the -O settings each activate several additional flags, so be sure to read the GCC manual's chapter on optimization options to learn which flags are activated at each -O level, as well as some explanations as to what they do.

Let's examine each optimization level:

[*]-O0: This level (that's the letter "O" followed by a zero) turns off optimization entirely and is the default if no -O level is specified in CFLAGS or CXXFLAGS. This reduces compilation time and can improve debugging info, but some applications will not work properly without optimization enabled. This option is not recommended except for debugging purposes.

[*]-O1: This is the most basic optimization level. The compiler will try to produce faster, smaller code without taking much compilation time. It's pretty basic, but it should get the job done all the time.

[*]-O2: A step up from -O1. This is the recommended level of optimization unless you have special needs. -O2 will activate a few more flags in addition to the ones activated by -O1. With -O2, the compiler will attempt to increase code performance without compromising on size, and without taking too much compilation time.

[*]-O3: This is the highest level of optimization possible. It enables optimizations that are expensive in terms of compile time and memory usage. Compiling with -O3 is not a guaranteed way to improve performance, and in fact in many cases can slow down a system due to larger binaries and increased memory usage. -O3 is also known to break several packages. Therefore, using -O3 is not recommended.

[*]-Os: This option will optimize your code for size. It activates all -O2 options that don't increase the size of the generated code. It can be useful for machines that have extremely limited disk storage space and/or have CPUs with small cache sizes.

[*]-Og: In GCC 4.8, a new general optimization level, -Og, has been introduced. It addresses the need for fast compilation and a superior debugging experience while providing a reasonable level of runtime performance. Overall experience for development should be better than the default optimization level -O0. Note that -Og does not imply -g, it simply disables optimizations that may interfere with debugging.

[*]-Ofast: New in GCC 4.7, consists of -O3 plus -ffast-math, -fno-protect-parens, and -fstack-arrays. This option breaks strict standards compliance, and is not recommended for use.

As previously mentioned, -O2 is the recommended optimization level. If package compilation fails and you aren't using -O2, try rebuilding with that option. As a fallback option, try setting your CFLAGS and CXXFLAGS to a lower optimization level, such as -O1 or even -O0 -g2 -ggdb (for error reporting and checking for possible problems).

Сподели този отговор


Линк към този отговор
Сподели в други сайтове

-Ofast но все пак, ако беше толкова добре да се ползват оптимизации над -O2 щеше да го пише.

 

но чета друго.

 

Извадка от Gentoo Wiki

Да де ама всеки код е различен!Един има предимство като е компилиран със 0s друг със 03 .Апропо L1 И L2 кеша на процесра

Сподели този отговор


Линк към този отговор
Сподели в други сайтове
публикувано (редактирано)

Това със стабилността при оптимизация -O3 е доста стара тема. Въпроса е какво е положението сега! Ако -О3 забавя компилирането, то това може да се компенсира с броя на процесите за компилиране (MAKEOPTS="-j?"). Документацията на Gentoo е известна с това, че не е идеална!!!

 

Препоръчителните настройки на make.conf от екипа на Gentoo са такива, които да гарантират успешното компилиране на ВСИЧКИ пакети в хранилищата им. А те не са никак малко. На практика обаче се използват малка част от тях и в този случай е съвсем нормално да се търсят по-добри настройки от тези посочени в документацията или разни WIKI-та.

 

 

Другия въпрос е как да компилираме хем бързо, хем да получим стабилни и бързи приложения. Нали затова компилираме и оптимизираме на собствения компютър. Не е нужно да загърбваме едната цел за сметка на другата. Целта е да постигнем и трите неща за съответното приложение. Изобщо оптимизацията на едномерна функция е лесно, въпроса е как да постигнем добри резултати, когато имаме няколко фактора, които влияят върху тях по различен начин.

 

И аз на времето като се занимавах с Gentoo четох доста теми по въпроса, гледах тестове и колкото повече четях и гледах се обедих, че резултатите зависят от конкретното приложение и версия на компилато.

 

Мен друг въпрос ме вълнува.

Как може да се автоматизира инсталацията на Gentoo, като същевременно се възползваме от възможно най-много оптимизации за инсталираните приложения.

Редактирано от supervas (преглед на промените)

Сподели този отговор


Линк към този отговор
Сподели в други сайтове

Това със стабилността при оптимизация -O3 е доста стара тема. Въпроса е какво е положението сега! Ако -О3 забавя компилирането, то това може да се компенсира с броя на процесите за компилиране (MAKEOPTS="-j?"). Документацията на Gentoo е известна с това, че не е идеална!!!

 

Препоръчителните настройки на make.conf от екипа на Gentoo са такива, които да гарантират успешното компилиране на ВСИЧКИ пакети в хранилищата им. А те не са никак малко. На практика обаче се използват малка част от тях и в този случай е съвсем нормално да се търсят по-добри настройки от тези посочени в документацията или разни WIKI-та.

 

 

Другия въпрос е как да компилираме хем бързо, хем да получим стабилни и бързи приложения. Нали затова компилираме и оптимизираме на собствения компютър. Не е нужно да загърбваме едната цел за сметка на другата. Целта е да постигнем и трите неща за съответното приложение. Изобщо оптимизацията на едномерна функция е лесно, въпроса е как да постигнем добри резултати, когато имаме няколко фактора, които влияят върху тях по различен начин.

 

И аз на времето като се занимавах с Gentoo четох доста теми по въпроса, гледах тестове и колкото повече четях и гледах се обедих, че резултатите зависят от конкретното приложение и версия на компилато.

 

Мен друг въпрос ме вълнува.

Как може да се автоматизира инсталацията на Gentoo, като същевременно се възползваме от възможно най-много оптимизации за инсталираните приложения.

 

Да знам че системата би могла да се компилира и с -О3 но не съм видял ползи от това. Но например с -Оs може да се каже че има някои ползи. За такива с по-слаби компютри. Прави бинарните файлове малки и бързи използват по-малко памет и дисково пространство, но някои от приложенията нямат същата производителност като при -О2.

@tux да в портиж има някои ебилди които по подразбиране са зададени с -О3 но това не означава че всеки ебилд върви с -О3. Предполага се че от Генту са направили -О3 само пакетите които са установили че работят по-добре.

Сподели този отговор


Линк към този отговор
Сподели в други сайтове

Регистрирайте се или влезете в профила си за да коментирате

Трябва да имате регистрация за да може да коментирате това

Регистрирайте се

Създайте нова регистрация в нашия форум. Лесно е!

Нова регистрация

Вход

Имате регистрация? Влезте от тук.

Вход

×

Информация

Поставихме бисквитки на устройството ви за най-добро потребителско изживяване. Можете да промените настройките си за бисквитки, или в противен случай приемаме, че сте съгласни с нашите условия за ползване.