Gentoo Linux - optimalizácie

15. 2. 2006 | Matej Gagyi | Systém | 9080×

Viete prečo je lepšie skompilovať si programy vlastnoručne alebo nechať Portage, aby to urobilo za vás? Pretože binárne balíky nie sú optimalizované pre váš procesor a sú badateľne pomalšie. Dnes si porozprávame o tom, ako zo systému vyťažiť maximum.

CFLAGS, CXXFLAGS

Premennú prostredia CFLAGS používa gcc pri kompilácii zdrojových kódov v jazyku C. V Gentoo túto premennú nastavujeme v súbore /etc/make.conf a Portage ju pred kompiláciou balíčka prečíta a nastaví. Premenná CXXFLAGS funguje rovnako, ale pre jazyk C++.

Ak nemáte problém s diskovým priestorom, ani s časom potrebným na kompiláciu, môžete bezpečne použiť nasledujúcu hodnotu CFLAGS a CXXFLAGS:

CFLAGS="-O3 -fomit-frame-pointer -pipe"
CXXFLAGS="$(CFLAGS)"

Výsledný program však nebude ušitý na mieru vášmu procesoru a bude využívať iba inštrukčnú sadu procesora i386 (samozrejme ak vlastníte procesor založený na tejto architektúre).

Ako funguje GCC

Najprv by sme si mali povedať pár slov o tom, ako pracuje GCC. Ako už možno viete, GCC obsahuje viac kompilátorov naraz - kompilátory pre jazyky C, C++, Objective C, Fortran a Javu, ale aj ďalšie. Kompilátor GCC sa skladá z dvoch častí - frontend a backend.

Každý jazyk má vlastný frontend. Frontend načíta (preparsuje) a spracuje samotné zdrojové kódy. Výstupom frontendu je reprezentácia zdrojového kódu v jazyku RTL (Register Transfer Language). Dá sa povedať, že RTL je abstraktný štruktúrovaný assembler. Je to veľmi všeobecný a zložitý jazyk zároveň, preto nemá zmysel ho používať pre bežné programovanie.

Strom RTL sa pri kompilácii nachádza v pamäti len v binárnej forme. V binárnej forme vstupuje do backendu kompilátora GCC, ktorý je všeobecný pre celý kompilátor. Backend generuje z RTL stromu kód assemblera pre určený procesor. Backend tiež vykonáva optimalizácie nad RTL stromom a aj pri generovaní assemblera.

Backend vie vykonať niekoľko desiatok rôznych optimalizácií a nie všetky sú vhodné v každej situácii. Preto sú rôzne druhy optimalizácií roztriedené do skupín, aby ich bolo možné jednoducho zapínať - o chvíľku si o nich povieme.

Zostali vám nezodpovedané otázky? Ak vás zaujíma, ako vyzerá RTL, skúste skompilovať jednoduchý program s parametrom -dr:

gcc -dr zvyšné parametre

Ak chcete vedieť, ako prebiehajú rôzne optimalizácie v backende kompilátora GCC, prečítajte si článok The GNU Instruction Scheduler z roku 1989 (podstata GCC sa nezmenila).

Optimalizácia

Najdôležitejší je parameter optimalizácie -Ox. Určuje, ktorú skupinu optimalizácií chceme pri kompilovaní použiť. Písmeno x treba nahradiť číslom, alebo písmenom želanej skupiny. Popis jednotlivých skupín optimalizácií:

-O0

Neoptimalizuj. Kompilátor GCC nevykoná žiadne optimalizácie, kompilácia je najrýchlejšia a výsledný program je najpomalší.

-O1

Optimalizuj. Kompilátor vykoná optimalizácie, ktoré zmenšia a zrýchlia výsledný program a pritom príliš nepredĺžia čas kompilácie a jej nároky na pamäť.

-O2

Optimalizuj ešte viac. Kompilátor zapne všetky optimalizácie, ktoré urýchlia program a pritom priveľmi nezväčšia jeho veľkosť. Kompilácia je pomalšia a vyžaduje viac pamäte. Táto voľba sa používa najčastejšie.

-O3

Optimalizuj čo najviac. Toto je najnáročnejšia optimalizácia. Výsledný program je najväčší, ale aj najrýchlejší. Ak máte dobrý procesor (500MHz a viac) a potrpíte si na rýchlosť behu aplikácií, je to pre vás ideálna voľba.

-Os

Optimalizuj pre veľkosť. Zapne všetky optimalizácie parametru -O2, ktoré nezväčšia veľkosť výsledného programu a pridá ďalšie optimalizácie pre veľkosť výsledku. Rýchlosť a nároky na pamäť sú podobné, ako pri -O2.

Ak špecifikujete viac parametrov -Ox naraz, použije sa iba posledný.

Parameter -fomit-frame-pointer znemožní debugovanie (používateľ to nepotrebuje) a zmenší veľkosť binárky.

Parameter -pipe urýchli kompiláciu, pretože gcc nebude medzivýsledky ukladať na disk, ale ponechá ich v pamäti.

Inštrukčné sady

Každý typ procesora má vlastnú inštrukčnú sadu - inštrukcia je jeden úkon, ktorý procesor dokáže vykonať. V assembleri nepoužívame príkazy, ale priamo inštrukcie procesora. Z toho vyplýva, že program v assembleri je závislý na procesore, pre ktorý je určený a nedá sa spustiť na inom.

Našťastie nové procesory poznajú všetky inštrukcie starších procesorov a inštrukčnú sadu len rozširujú o ďalšie inštrukcie. Túto vlastnosť majú procesory z radu Intel x86 - procesory bežných PC (i386, i486, Pentium atď.).

Ako som už povedal, kompilátor GCC generuje z RTL kódu kód assembleru a potrebuje teda vedieť, pre ktorý procesor má assembler vygenerovať. Na platforme x86 generuje predvolene pre procesor i386 a ten je možné použiť na ktoromkoľvek vyššom procesore.

Parameter -march=architektúra určuje inštrukčnú sadu procesora, na ktorom má program fungovať. Ak chceme, aby program fungoval aj na starších procesoroch, ale chceme ho optimalizovať pre svoj procesor, môžeme použiť jeden z parametrov:

• -mcpu=architektúra (gcc verzie 3.3 a nižšie)
• -mtune=architektúra (gcc verzie 3.4 a vyššie)

(Verziu gcc zistíme pomocou prikazu: gcc -v.)

Za slovo architektúra dosaďte označenie procesora, pre ktorý kompilujete. Označenia všetkých procesorov nájdete v manuálovej stránke GCC. Ak kompilujete pre procesor typu x86, hľadajte sekciu Intel 386 and AMD x86-64 Options (jednoduchšie je nechať vyhľadať na manuálovej stránke reťazec athlon).

LDFLAGS

LDFLAGS používa linker (program, ktorý spája časti zdrojových kódov do spustiteľného súboru, alebo knižnice). Bezpečná hodnota premennej LDFLAGS je:

LDFLAGS="-Wl,-O1"

Ak chcete dostať zo systému maximum a ste ochotný trochu riskovať:

LDFLAGS="-Wl,-O1 -Wl,--sort-common -z -combreloc -Wl, \
--enable-new-dtags -Wl,--relax"

V niektorých prípadoch sa pri kompilácii glibc môžu vyskytnúť problémy. Je lepšie nepoužívať v hodnote LDFLAGS parameter -Wl,--relax:

LDFLAGS="-Wl,-O1 -Wl,--sort-common -z -combreloc -Wl,--enable-new-dtags"

Problémy pre kompilácii robia aj OpenOffice.org a GStreamer. Tu sa odporúča radikálne riešenie - nepoužívať žiadnu hodnotu LDFLAGS:

LDFLAGS=""

V týchto špeciálnych prípadoch si môžete usporiť námahu s editovaním súboru /etc/make.conf a premenné určiť priamo z príkazového riadku:

# LDFLAGS="" emerge gstreamer
# LDFLAGS="" emerge openoffice        

Komentáře

[oxymoron]

je mozne pouzit namiesto -Wl,-O1 -Wl,-O3 ??

[Martin Beránek]

Rekl bych ze autor pozapomel na parametr -march ktere pouzivaji bezne distribuce misto -mcpu. Existuji "objektivni testy" mezi temito rezimy?

[Robert Krátký]

Parameter -march=architektúra určuje inštrukčnú sadu procesora, na ktorom má program fungovať.

[kavol]

hm, rád bych viděl nějaký doklad tvrzení v perexu o optimalizaci a rychlosti ...

pokud se mluví o nějakých LDFLAGS, nebylo by od věci říct, co znamenají, zvlášť když se doporučuje za určitých okolností některé vynechat ... ostatně ani ty CFLAGS nejsou vysvětlené ... já vím, máme man, ale když už někomu něco doporučuju a píšu o tom článek, aspoň jedna větička proč mu doporučuju zrovna tohle by neškodila ...

[J]

Pokud si pamatuju, v minulym dile nekdo postnul vysledky testu pri ruznych nastavenich. Rozdil byl velmi znatelny. Ovsem treba v pripade OO asi nema mnoho smyslu nejaka brutalni optimalizace, tam je mozna lepsi zvolit variantu rychle kompilace. Vyplati se to pro veci jako trebas mplayer.

[kavol]

$ mplayer
MPlayer 1.0pre7-4.0.1 (C) 2000-2005 MPlayer Team
CPU: Intel Pentium M Banias (Family: 6, Stepping: 5)
Detected cache-line size is 64 bytes
CPUflags:  MMX: 1 MMX2: 1 3DNow: 0 3DNow2: 0 SSE: 1 SSE2: 1
Compiled with runtime CPU detection - WARNING - this is not optimal!

... no nezdá se mi, že by v mojí binární distribuci byl mplayer zkompilován zcela bez optimalizací

[Trained.Monkey]

He, tohle co ukazujes je CPU runtime detection kterou mplayer dela sam. Kdyby jsi mel pentium I tak nezapne ani mmx

[Lukáš Zapletal]

No mě se zase zdá, že to, co tady vidíme, je jen detekce procesoru. To samý získáte výpisem /proc/cpuinfo (IMHO).

[kavol]

No mě se zase zdá, že to, co tady vidíme, je jen detekce procesoru.

ovšem výsledkem této detekce se pak mplayer řídí a používá kód optimalizovaný pro dané možnosti ... což jaksi vyvrací názor, který se snaží článek vsugerovat, a to že binární distribuce optimalizace nepoužívají ...

[Yin]

... binární distribuce optimalizace nepoužívají ...

To som nikdy nepovedal! Povedal som, že binárne distribúcie nie sú prispôsobené každému procesoru na mieru, ale len pre nejakého spoločného predchodcu väčšiny procesorov.

A tento príklad je zmätočný, pretože sa týka iba jedného programu (mplayer) a nie celej distribúcie.

[kavol]

... binární distribuce optimalizace nepoužívají ...

To som nikdy nepovedal!

ano, takto doslovně ne, na druhou stranu já jsem neřekl, že jsi napsal přímo toto, takže mi taky taky nepodsouvej něco, co jsem neřekl!

inkriminovaná věta zní:

"Pretože binárne balíky nie sú optimalizované pre váš procesor a sú badateľne pomalšie."

mezi "přebásněním" slov "nie sú optimalizované pre váš procesor" na "optimalizace nepoužívají" je z významového hlediska pouze jediný rozdíl, a to že jsem si dovolil zobecnit "ne pro váš procesor" na "pro žádný procesor", jelikož sjednocení množin {váš procesor} v případě čtenářů ábíčka zahrnuje nejspíš téměř všechny architektury, na kterých Linux běhá - pokud s tím nesouhlasíš, měl bys dokázat, že průnik množin {všechny modely procesorů, pro které jsou některé balíky v různých binárních distribucích optimalizovány} a {všechny modely procesorů, na kterých čtenáři provozují Linux} je prázdný

Povedal som, že binárne distribúcie nie sú prispôsobené každému procesoru na mieru, ale len pre nejakého spoločného predchodcu väčšiny procesorov.

kde se toto tvrzení v článku vyskytuje?

A tento príklad je zmätočný, pretože sa týka iba jedného programu (mplayer) a nie celej distribúcie.

zmatečná je jedině tvoje reakce, kolega J, na kterého jsem reagoval, psal o tom, že optimalizace má smysl u jednotlivých programů a uvedl: "Vyplati se to pro veci jako trebas mplayer.", v dané souvislosti je tedy nesmysl mluvit o celé distribuci

[J]

Compiled with runtime CPU detection - WARNING - this is not optimal!

No, nezda se ze by tady nekdo umel cist.

[kavol]

No, nezda se ze by tady nekdo umel cist.

ok, až se to naučíš, tak začni od článku a pokračuj mojí první reakcí, pak třeba pochopíš, proč jsem na tvoji zmínku o mplayeru reagoval takto (případně si přečti ještě moji odpověď lzapovi)

[David Watzke]

CPU detection je lepší zakázat, zpomaluje. Ale co jinýho zbyde tvůrcům balíčků, že jo...

$ mplayer
MPlayer dev-CVS-060102-08:04-3.4.5 (C) 2000-2005 MPlayer Team
CPU: Advanced Micro Devices Athlon 64
 Newcastle,Winchester,San Diego,Venice; Sempron Palermo
 (Family: 15, Stepping: 0)
CPUflags:  MMX: 1 MMX2: 1 3DNow: 1 3DNow2: 1 SSE: 1 SSE2: 1
Přeloženo pro CPU x86 s rozšířeními: MMX MMX2 3DNow 3DNowEx SSE SSE2

[kavol]

Ale co jinýho zbyde tvůrcům balíčků, že jo...

nu sláva, zdá se, že konečně jeden to pochopil - máš u mě malé nevýznamné, takřka záporné, plus

[Michal Kubeček]

To byly ovšem výsledky analytického benchmarku, navíc benchmarku s velmi pochybným způsobem vyhodnocování výsledků. Pro odpověď na otázku, jak optimalizační příznaky ovlivní rychlost aplikací v distribuci, to má téměř nulovou vypovídací hodnotu.

[Michal Vyskočil]

Zdá se, že některé mýty, třeba o zrychlování aplikací pomocí CFLAGS, jsou hojně rozšířené a to především mezi lidmi používající jistou kompilovanou distribuci. Já se obávám, že vetšina aplikací, které běžně používám by ocenila spíše poloviční přístupovou dobu na disk , anebo nějakou jinou, super rychlou paměť (stačilo by tak o řád pomalejší jak RAM).

[Jan Grmela]

S tím bych souhlasil, dost lidí totiž ještě nepochopilo, že tato nejmenovaná distribuce je o možnostech customizace a jedoduchosti správy, nikoli o výkonu (i když ten s customizací může souviset).

[Jiri Slaby]

Ach jo. Urcite je O3 "aj najrychlejsi"? Urcite omit-frame-pointer znemozni debug na vsech platformach? IMHO nejde tak ani o to, ze to zmensi kod, ale spis, ze se uvolni jeden registr.

[Peter Golis]

a je aj bezpecny? napriklad pre PPC G4 je nestabilny, aspon tak tvrdi gentoo-wiki.org

[Marek 'marx' Grác]

Keep in mind that -O3 enables optimizations that generally make code worse, not better. Use it only if you know it will improve your code.

A občas sa stane, že kvôli tomu niečo padne. V každom prípade použitie kompilátoru od Intelu má omnoho lepší efekt :)

[jm]

V každom prípade použitie kompilátoru od Intelu má omnoho lepší efekt :)

To bezesporu, jen maloco dokaze tak zprznit vysledek jako ICC...

[Yin]

Ok, priznávam, že -O3 nemá vo väčšine prípadov tie najlepšie výsledky, ale aj tak sú tie najhoršie prípady takmer rovnaké ako pri -O2 (vyvracajúci dôkaz ocením).

Ja som nepovedal, že --omit-frame-pointer znemožní debugovanie na všetkých platformách.

[Marek 'marx' Grác]

Minimálne pred časom, Huffmanova kompresia a programy, ktoré príliš cyklia. Čo je ale hlavné, tak -o3 rapídne zvyšuje pravdepodobnosť pádu programu.

[David Watzke]

Ani jsem si nevšiml... a to tak mám pomalu celej systém.

[Jan Grmela]

Tak si říkám

Nejvíc mi padá stejnak Opera, která je snad jediným binárním programem v mém PC...(ano, OOo si překládám)

[Jiri]

Vyplati se -O3 nebo -Os?

Zatim pouzivam -O3, ale možná by bylo vhodnější kompilovat s -Os. O kolik jsou ty binarky mensi? Zrychli se vyrazne tahani z disku?

[xkesh]

Vyplati se -O3 nebo -Os? Zatim pouzivam -O3, ale možná by bylo vhodnější

Byly doby, kdy jsem nadsene kompiloval s -O3. Od te doby, co jsem redukoval na -02, vyrazne klesl pocet komplikaci pri kompilacich (de facto na 0). Jineho efektu si nejsem vedom. Myslim, ze je to i ve smyslu doporuceni vyvojaru Gentoo, viz prispevek vyse.

[Trinitrotolue Ramapitesca]

Od te doby co jsem system celej prekompiloval s O2 tak se mi na disku objevilo o 15% volnyho mista navic.

[m1c4a1]

To bude tím, že -O3 v binárce rozvíjí inline funkce, čímž se velikost výsledného souboru sice zvětšuje, ale urychluje to provádění programu.

[nardew]

vedel by mi niekto napisat nieco o MAKEOPTS?

ja mam v make.conf MAKEOPTS='-j2', ale neviem co to znamena, pripadne ak by tam bolo dobre pridat nejake dalsie volby, mozte napisat

[jm]

# MAKEOPTS provides extra options that may be passed to 'make' when a
#     program is compiled. Presently the only use is for specifying
#     the number of parallel makes (-j) to perform. The suggested number
#     for parallel makes is CPUs+1.
#MAKEOPTS="-j2"

Zdroj: /etc/make.conf.example

[Yin]

Make bude spustať viac úloh paralélne. V tvojom prípade dve naraz. Využiješ to hlavne ak kompiluješ distribuovane (napr. pomocou distcc), alebo ak máš viacprocesorovú zostavu. Bežne sa odporúča použiť hodnotu: počet procesorov + 1

[David Watzke]

Bežne sa odporúča použiť hodnotu: počet procesorov + 1

To je pro másla 8-)

[Milan Keršláger]

Vy jste takový Brouk Pytlík, pane kolego. Jednak tvůrci binárních distribucí nejsou natvrdlí, aby nepoužili optimální optimalizace tam, kde to má smysl (glibc, openssl) a jednak se alespoň obtěžují reálně vyzkoušet, co má a co nemá *skutečný* vliv. Kromě toho optimalizace pro CPU nemají příliš význam (GCC toho až tak moc nevyužívá a ty extrabuřty nejsou povětšinou až tak úchvatné), protože aplikací, kde se to vyplatí, je jak šafránu.

A nezapomeňte, že dnes mají všichni i686, na což jsou distribuce optimalizované (s výjimkou toho, že jejich kód běží i na pentiích). Optimalizace pro Pentium význam má (procesor funguje úplně jinak), ale systém na Pentiu snad používá jen masochista a na router nejsou optimalizace potřeba (distribuce obvykle mají jádra pro i586).

Pokud vás trápí něco pomalého, pak se spíše zaměřte na prelink, protože to bude mít větší vizuální efekt, než milisekundy ušetřené v GUI za běhu Firefoxu.

[roman]

zaujala mne ta optimalizace LDFLAGS a tak jsem se podiavl na zdrojaky ld

-O nedela VUBEC NIC --sort-common - se snazi jen priblizne setridit symboly combreloc - nedelas VUBEC NIC relax - dela neco

miluju gnu software! :)