GCC a optimalizace s profilerem

8.5.2007 13:30 | Přečteno: 2520× | Programování |

ve flamu na rootu jsem nasel krasnou vecicku o niz jsem ani netusil, ze ji gcc umi -- optimalizace podle vysledku profileru. pri beznych optimalizacich nema tradicni prekladac (nemlouvim ted o JIT kompilaci) sanci zjistit, jak ktere casti kodu budou volany casto, z jakych mist a podobne... a proste jen hada a tipuje. nicmene, pomoci vcelku zastrcenych direktiv prekladace -fprofile-generate a -fprofile-use jde situace velice hezky zmenit a hodne pozitivnim smerem.

k "na dren" skompilovanemu projektu vedou nasledujici kroky:

• nejdriv je potreba skompilovat cely projekt s direktivou -fprofile-generate (aby se mohly generovat profilacni informace)
  
• pak je nutne spustit program v typicke uloze (aby profiler mohl nasbirat data o behu programu)
  
• vymazat stare binarky
  
• spustit preklad s direktivou -fprofile-use (aby se vyuzily optimalizace)
  

v Makefile jsem si na to udelal novy cil "optimal" a vypada to nejak takto:

CFLAGS+=${PROFILE_ARGS}

...

optimal:
       make clean
       make PROFILE_ARGS=-fprofile-generate
       make test0 PROFILE_ARGS=-fprofile-generate
       make clean
       make PROFILE_ARGS=-fprofile-use
       rm *.gcda
       rm *.gcno

vysledky jsou opravdu "vau!":
jako test jsem pouzil svuj interpretr schemu s temito dalsimi nastavenimi:

-Wall -Winline -O3 -std=c99 -pedantic -finline-limit=100000 --param large-function-growth=100000

30 fibonacciho cislo:

• bez optimalizaci -- 3.163
  
• s optimalizacemi -- 2.580
  
• zrychleni -- cca 19%
  

33 fibonacciho cislo:

• bez optimalizaci -- 13.378
  
• s optimalizacemi -- 10.778
  
• zrychleni -- cca 20%
  

btw. chudaci uzivatele gentoo ... s takovou by meli kompilovat cely system na dvakrat ;-]        

Komentáře

[Luboš Doležel (Doli)]

btw. chudaci uzivatele gentoo ... s takovou by meli kompilovat cely system na dvakrat

Já bych to pro těch pár procent klidně udělal

[andree]

...uz je len otazka, co je typicka uloha pre taky kernel, KDE, zlib alebo ssh :o)

[deda.jabko]

proste tyden, to budete pouzivat (pobezi to sice pomalu), ale jak se to po tom tydnu prekompiluje, tak to bude rychle jak blesk ;-]

[Kyosuke]

Vždyť to není tak složité. Třeba v Gentoo se bude GCC kompilovat tak, že se zkompiluje s -fprofile-generate, pak se s ním zkompiluje kernel s -fprofile-generate, pak se bude kernel chvíli používat, pak se kernel zkompiluje pomocí -fprofile-use a v tu chvíli budeš mít v GCC nasbíraný vhodný profil, aby sis GCC mohl zkompilovat s -fprofile-use.

[Kyosuke]

"btw. chudaci uzivatele gentoo ... s takovou by meli kompilovat cely system na dvakrat ;-] "

U OpenOffice.org se to ale vyplatí, ne?

[Michal Vyskočil]

btw. chudaci uzivatele gentoo ... s takovou by meli kompilovat cely system na dvakrat ;-]

Spíše natřikrát. V prvním kroku se zdrojáky prostě spustí/přeloží pomocí tcc (aby člověk nemusel čekat na doběh kompilace). Potom se na pozadí spustí kompilace s -fprofile-generate a nakonec třetí kompilace tentokrát už s -fprofile-use. Ještě by to chtělo nějakého démona, který pozná špatně profilovanou binárku a na pozadí ji rekompiluje

BTW: nezkoušel někdo tcc trochu důkladněji?

[marbu]

a az by to bylo napotreti prelozene tak by uz byla venku dalsi verze ;)

[Spike]

Spíš by to uživatelé Gentoo kompilovali jen jednou, protože informace pro profiler by se mohly distribuovat třeba s ebuildy.

[Kyosuke]

A nebyla by na každé architektuře profilovací data mírně odlišná? A navíc podmíněný překlad a tak.

[Spike]

Detaily. Určitě by se to dalo vyřešit.

[cynik]

Zajimavy, o tehle moznosti jsem nevedel. Ale kdyz jde o rychlost, pak je asi lepsi to optimalizovat rucne prave na zaklade informaci profileru.. to aspon v mych kodech dela nekolikanasobne zrychleni. Clovek se v tom ovsem musi vyznat.

Nicmene, 20% neni nic moc. Asi se to ani nevyplati. Mnohem ucinejsi pochopitelne bude kompilace lepsim prekladacem (icc) nebo se specifikaci procesoru na ktery se to kompiluje.

[deda.jabko]

ten kod na kterem jsem to testoval, je rucne optimalizovany snad na maximum (agresivni inlining, optimalizace na predavani argumentu pres resgistry,....) ... takze tech 20% je hezke cislo.... i kdyz na jinem kodu to muze byt jinak....

problem informaci z profileru je takovy, ze kdyz se z nich da neco vycist, tak ty informace muzou byt k nicemu... protoze, aby se odhalil opravdovy beh programu, tak je potreba mit zaple optimalizace a s optimalizacemi zase nejde videt, ktera cast programu prave probiha, protoze binarni kod neodpovida zdrojovemu kodu ;-] (problem jak z kvantove fyziky ;-])

[Kyosuke]

Třeba tím chtěl naznačit, že bys měl začít psát rovnou kompilátor...

[deda.jabko]

doufam, ze to brzo prijde... ;-] do zacatku srpna musim mit kompletni paralelni interpretr schemu (mozna dopisu i posledni kapitolu toho serialu) a pak kdo vi?! ...mozna prijde i ten prekladac, dle hesla "bodly compile what no man has compiled before!" ...ale vsechno postupne... ;-]

[Luk]

problem jak z kvantove fyziky

Ono už to, že se nějaký profiling dělá, značně mění podmínky. Zvlášť u programů, kde je něco časově kritického.

[peter_h]

Neviem ci ta dobre chapem, ale to sa tam nezaratava.
Ale lepsi postup je imo najst s oprofile hotspod a zoptimalizovat len ten.

[peter_h]

s/hotspod/hotspot/

[Luk]

Nejde o to, co se tam započítává. Jde o to, že profiling zdržuje a neumožňuje příliš odhalit, kde se čeká na HW, jaký má vliv přepínání kontextu apod. Prostě klasický problém změny podmínek tím, že se jev pozoruje.

Zrovna takový problém teď řeším, konkrétně neúnosně velké vytížení procesoru. Jde o to, že spolupracují tři procesy, a jakmile se některý z nich profiluje, situace se změní natolik, že problematický jev není pozorovatelný.

[Josef Kufner]

ten kod na kterem jsem to testoval, je rucne optimalizovany snad na maximum (agresivni inlining, optimalizace na predavani argumentu pres resgistry,....) ...

Ale to není ručně optimalizované vůbec. Zkus kouknout, co žere nejvíc času a přepsat to efektivněji, i kdyby se měl kód zesložitit. Pak se začnou dít zázraky a stovky procent budou jen lítat.

[deda.jabko]

Ale to není ručně optimalizované vůbec.

a ze si jste tim tak jisty! ;-] jenom nekolik clovekodni jsem stravil pri hledani vhodne struktury pro zasobnik -- a ze jich bylo a ze jsou mezi nema rozdily ;-]

btw. vsechno zere vicemene jedna velka smycka, ktera prehazuje hodnoty z jednoho zasobniku na druhy, protoze tam nic jineho neni ;-] (viz moje predchozi posty)

ta hranice, kdy se jedna jeste o optimalizaci a kdy o jiny algoritmus, je opravdu hodne nezretelna.... brano ad absurdum, tak nejlepsi optimalizaci by to bylo prepsat z interpretru na prekladac... ;-] ale to uz by nebylo ono, protoze s tim delam dalsi divociny ;-]

[Josef Kufner]

Aha, tak to jsem si to asi vyložil jinak, než jsi to myslel. Vyznělo mi to jako ladění voleb překladače místo úprav kódu

ad btw: A co to přepsat jen tak na půl?

[deda.jabko]

argumenty prekladace nejsou nijak slozite ladene ... "jenom" "-O3" a zvetseny limit na inlinovani funkci (viz clanek), abych misto maker mohl pouzivat hezci a bezpecnejsi inline-funkce.... a na zaklade toho je tam nechany prostor pro prekladac, aby si mohl radu veci udelat podle sebe....

ad tak napul -- ono je to pomale prave kvuli tomu, ze se to "preklada do mezijazyku", ktery se proste projizdi ve smyckach ;-] (a ten mezijazyk neni nijak optimalizovany na vykon... spis, aby se s nim daly delat dalsi experimenty...) reseni by bylo v prekladu pomoci JIT. ....pouziti JIT je zajimava myslenka se kterou si delsi dobu pohravam a v plt scheme dava velice zajimave vysledky. jenomze co jsem se dival na spoustu implementaci jazyku s vlastnimi JIT, tak proste jsou dnes nepouzitelne, protoze casto podporuji jenom jeden typ procesoru, ktery zrovna mel dotycny v pocitaci... presto uvazuji o gnu lightning... ale docasu! ;-]

[martink]

A co LLVM?

[deda.jabko]

dik za tip, mrknu na to.

[Jiří Němec]

Tak teď by to už jen chtělo nějaký systém k výměně těch souborů s profily. Pro 20% nárustu výkonu nechám procík zkompilovat systém klidně 20x, ale nikdo mě nedonutí spouštět každý program.

Mimochodem podobným postupem se na jistých datech zvýšil výkon aircracku tuším až o 500%, ale byl použit kompilátor icc.

[Roman Schulz]

Ahoj, díky za super návod. Vůbec jsem o této možnosti optimalizace neměl tušení a myslím že ji časem určitě využiju...

[stativ]

Bacha, kdysi se mi stalo, že třeba blender nešel s touto volbou přeložit. Nevím jak je na tom teď.

[deda.jabko]

tak to bude vzdycky, ze neco zlobi.... sice je to malinko z jineho soudku... ale ted jsem mel treba problemy prelozit php 5.2.cosi s "make -j2", to same minesota mapserver a najdou se dalsi.... ale co je dneska idealni?!

[nula]

Prima tip, díky. Zkusil jsem si to na svém počítacím prográmku a zrychlení jsem naměřil cca 15%, což mě rozhodně potěšilo.

[zde]

Zkusil jsem přeložit jednoduchý program se zapnutým profilováním.

$ more x.c
test(a) {
        if (a & 1) return fun_1(a);
        return fun_2(a);
}

Moc se ale nevyznám ve výstupu. Evidentně LPBX1 je 32 byte, které fungují jako čtyři 64-bitové countery, které počítají průchody čtyřmi základními bloky oné funkce. LC0 je taky jasné, jméno modulu. trojka a čtverka by mohly být čísla řádků... Ostatní se mi ale jeví jako binární šum bez špetky logiky..

        .local  .LPBX1
        .comm   .LPBX1,32,32
        .section        .rodata
.LC0:
        .string "x.gcda"
        .data
        .align 4
.LC1:
        .long   3
        .long   1555776990
        .long   4
        .align 32
        .type   .LPBX0, @object
        .size   .LPBX0, 52
.LPBX0:
        .long   875573616
        .long   0
        .long   1901502412
        .long   .LC0
        .long   1
        .long   .LC1
        .long   1
        .long   4
        .long   .LPBX1
        .long   __gcov_merge_add
        .zero   12
        .text
        .type   _GLOBAL__I_0_test, @function
_GLOBAL__I_0_test:
        pushl   %ebp
        movl    %esp, %ebp
        subl    $8, %esp
        movl    $.LPBX0, (%esp)
        call    __gcov_init
        leave
        ret
        .size   _GLOBAL__I_0_test, .-_GLOBAL__I_0_test
        .section        .ctors,"aw",@progbits
        .align 4
        .long   _GLOBAL__I_0_test
        .align 4
        .long   _GLOBAL__I_0_test