LINUXSOFT.cz Přeskoč levou lištu

ARCHIV



   

> GCC vs. CLANG 4

Vliv kompilačních voleb na rychlost kódu

4.8.2010 00:00 | Radim Kolář | Články autora | přečteno 5727×

Jak kompilační volby ovlivňují rychlost kódu

Rozhodl jsem se prozkoumat jaký vliv mají jednotlivé volby kompilátoru na rychlost výsledného kódu obou překladačů.

Jako test jsem použil Linuxový port BYTE benchmarku verze 2. Jde o mixovaný benchmark, kde jsou testovány jak floating point operace tak integer operace a taky je zohledněna práce s pamětí. Jednotlivé testy odpovídají reálným úlohám, nejsou to tedy čistě syntetické benchmarky.

Testování probíhalo pod operačním systémem FreeBSD 8.1 s GCC 4.2.1 20070719 (poslední GCC verze co byla pod GPLv2, novější jsou pod GPLv3). Jako typ CPU pro GCC byl použit Intel prescott, protože core2 architektura v době napsání překladače ještě nebyla. Tento systém běžel virtualizován ve VMware. Přesto doby běhu testů byly konzistentní a lišily se v důsledku virtualizace a zátěží způsobované ostatními aplikacemi až v třetí platné číslici, tedy v jednotkách procent, což víceméně odpovídá přesnosti měření i v nevirtualizovaném prostředí.

V první tabulce se podíváme na GCC. Použijeme 3 sady kompilačních voleb. První a nejpomalejší jsou default kompilační volby používané ve FreeBSD. Druhá sada odpovídá volbám použitým při překladu většiny linux distribucí a třetí sada odpovídá agresivnější -O3 optimalizaci, která se ale moc často v praxi nepoužívá protože naneštěstí GCC často generuje s touto volbou chybný kód nebo kód co je pomalejší než při -O2.

GCC

TEST-O2 -march=prescott -fno-strict-aliasing-O2 -fstrict-aliasing -fomit-frame-pointer -march=prescott-march=prescott -O3 -fomit-frame-pointer -funroll-loops
NUMERIC SORT10901139.3982.44
STRING SORT95.3196.14696.948
BITFIELD4.8991e+084.838e+084.8311e+08
FP EMULATION118.45122.67212.62
FOURIER188451881419202
ASSIGNMENT31.61733.29640.036
IDEA44364586.35680.9
HUFFMAN2116.42148.82321.8
NEURAL NET30.58329.2590.76538
LU DECOMPOSITION1447.71465.71612.5
MEMORY INDEX15.34115.58816.614
INTEGER INDEX14.60215.07517.929
FLOATING-POINT INDEX23.79523.5307.260
Větší číslo v tabulce znamená lepší výsledek.

Zásadní rozdíl mezi první a druhou volbou je volba -fomit-frame-pointer. Touto volbou uvolníme jeden registr za cenu toho, že nám nebude správně fungovat backtrace při debugování. Z crashdump core souborů se pak nedá spolehlivě zjistit v které funkci to spadlo. Registr navíc způsobí zvýšení výkonu protože se nemusí tak často přistupovat do pomalé paměti, ačkoliv na dnešních 64-bitových procesorech již není tak výrazné jako bývalo na 32-bitových Pentium II. Tam uvolnění toho registru znamenalo i 15% nárůst výkonu. Optimalizační volba -O3 přináší oproti -O2 určité, ačkoliv ne výrazné zlepšení. Jak je vidět z výsledků tak -O3 způsobilo u některých testů propad výkonu.

Clang

Stejné testy jaké byly provedené s GCC jsou nyní zopakovány s překladačem Clang. Optimalizujeme pro CPU core2, protože ho Clang zná, neboť se jedná oproti starému GCC o současný překladač.

TEST-O2 -march=core2-O2 -fstrict-aliasing -fomit-frame-pointer -march=core2-O3 -fstrict-aliasing -fomit-frame-pointer -march=core2
NUMERIC SORT1320.11362.91359.3
STRING SORT90.12290.6295.615
BITFIELD4.4253e+084.4415e+084.3236e+08
FP EMULATION217.42224.03223.89
FOURIER131551385913933
ASSIGNMENT30.23231.26130.735
IDEA49245128.95017.2
HUFFMAN18881788.41832.2
NEURAL NET28.48628.86128.937
LU DECOMPOSITION1405.51423.61392.6
MEMORY INDEX14.34014.54514.593
INTEGER INDEX17.78618.00217.997
FLOATING-POINT INDEX20.41120.94920.852

Z tabulky je vidět že Clang generuje pomalejší kód než GCC, ale rozdíl je okolo 10 procent. Clang s -O3 negeneruje oproti -O2 rychlejší kód. Důležitější ale je, že negeneruje v některých případech s -O3 narozdíl od GCC kód pomalejší, takže je volba -O3 u Clang bezpečnější než u GCC. Integer operace umí Clang optimalizovat stejně dobře jako GCC, mírně zaostává při práci s pamětí a ve floating point operacích.

Stack protector

V GCC existuje od verze 4.1 modul ProPolice, který dělá ochranu před buffer overflow útoky. Ochrana není stoprocentní, protože již byly objeveny postupy jak exploitnout i program takto chráněný, ale ne vždy se dá tento postup použít. Pro více informací doporučuji shlédnout prezentaci z projektu OpenBSD.

ProPolice modul byl již dlouho použit v OpenBSD a to dávno v době kdy ještě nebyl oficiální součástí balíku GCC. Druhou distribucí která ho nasadila bylo Ubuntu a pak následovalo DragonFly BSD a NetBSD a FreeBSD-8.

Zajímalo mne jak se tato ochrana projeví na výkonu. ProPolice má dva režimy ochrany v standardním chrání jen fukce volající alloca a funkce s bufferem větším než 8 bajtů. V druhém režimu chrání všechny funkce. Podle materiálů projektu OpenBSD v druhém režimu způsobí ProPolice zhruba 2% zpomalení.

TEST-fno-stack-protector-fstack-protector-fstack-protector-all
NUMERIC SORT1125.91130.51063.5
STRING SORT95.44796.09595.53
BITFIELD4.8104e+084.8367e+084.8313e+08
FP EMULATION121.45122.38108.15
FOURIER186701888918859
ASSIGNMENT33.20833.37532.583
IDEA4535.24536.54133.7
HUFFMAN2133.32243.22167.5
NEURAL NET30.01130.35430.796
LU DECOMPOSITION1443.514411436.6
MEMORY INDEX15.50715.59615.436
INTEGER INDEX14.92415.15814.021
FLOATING-POINT INDEX23.54923.71623.794

Z tabulky vidíme, že rozdíl mezi volbami -fno-stack-protector a -fstack-protector je pod hranicí chyby měření. U -fstack-protector-all již zpomalení pozorujeme. Zde ale závisí na použitém testu kolik je v něm voláno funkcí. Pokud se funkcí volá hodně, tak pokles může být až 20 procent.

Vliv CPU typu na rychlost

Překladače jazyka C umí optimalizovat program pro daný procesor. Default volba je optimalizovat pro Intel 386. Používat ji není příliš šťastné řešení protože Intel 386 byl vyroben v roce 1986 a dneska se s ním setkáte jen v embedded zařízeních a to ještě velmi velmi zřídka, protože Intely 386 nebyly nikdy oblíbené - místo nich se používala 32-bitová Motorola 68000.

Novější Intel procesory umí nejen nové instrukce, které dokáží nahradit několik starších instrukcí - tedy provedou se rychleji, ale umí zpracovávat i více instrukcí současně za dodržení určitých podmínek - instrukce musí být na sobě nazávislé a požadovaná jednotka procesoru zpracovávající příslušnou operaci musí být volná. Optimalizace kompilátory pro procesor tedy spočívají ve vhodném výběru a řazení instrukcí.

Trochu odlišná situace panuje ve světě RISC procesorů jako jsou UltraSPARC a POWER. Tam se stává že novější verze CPU již neumí z důvodů zjednodušení designu zpracovávat některé málo využívané staré instrukce. Tyto instrukce se pak softwarově emulují, stejně jako se v dobách Intelu 386 a 486SX emuloval matematický koprocesor. Emulace se buďto zabudovaná přímo v operačním systému, nebo se emuluje v userland knihovně, která se při spuštění starých programů načítá mechanizmem LD_PRELOAD.

TESTGCC i386GCC i686GCC prescott
NUMERIC SORT1062.21077.31139.3
STRING SORT95.86894.496.146
BITFIELD4.8498e+084.4164e+084.838e+08
FP EMULATION71.07122.31122.67
FOURIER184361885918814
ASSIGNMENT32.05533.18833.296
IDEA4077.84497.34586.3
HUFFMAN2073.72205.32148.8
NEURAL NET28.74331.35429.259
LU DECOMPOSITION1427.71438.31465.7
MEMORY INDEX15.39015.01315.588
INTEGER INDEX12.43914.87815.075
FLOATING-POINT INDEX23.03123.94723.530

U GCC platí že pokud vytváříme binární balíčky a nekompilujeme si program pro sebe tak máme kompilovat pro CPU i686 neboli Pentium II CPU. Nárůst výkonu s použitím optimalizace pro vyšší CPU již není tak významný a u zákazníků se mohou čas od času ještě najít starší počítače. Pentium II to sice nebude, ale Celerony kompatibilní s Pentiem III se zřídka zahlédnout dají.

TESTClang i386Clang i686Clang core2
NUMERIC SORT1365.11357.21354.1
STRING SORT89.64889.72289.786
BITFIELD4.4283e+084.4203e+084.4164e+08
FP EMULATION223.15222.61215.48
FOURIER145711456513620
ASSIGNMENT30.58430.331.004
IDEA5114.95108.35074.1
HUFFMAN1822.51815.31779.1
NEURAL NET10.710.66328.844
LU DECOMPOSITION345.92344.411420.3
MEMORY INDEX14.37314.32414.433
INTEGER INDEX18.06518.00417.728
FLOATING-POINT INDEX9.5499.52320.808

U Clangu je situace odlišná. Narozdíl od GCC zde prakticky žádný rozdíl v rychlosti není s vyjímkou floating point operací, které jsou při použití core2 výrazně rychlejší. Pravděpodobně je překladač realizuje pomoci rozšíření SSE.

Závěr

Překvapil mne všeobecně malý vliv optimalizace větší než -O2 na rychlost výsledného kódu. U Clangu je tento vliv ještě menší. S vyjímkou floating point operací bych řekl že je stěží měřitelný.

Verze pro tisk

pridej.cz

 

DISKUZE

Nejsou žádné diskuzní příspěvky u dané položky.



Příspívat do diskuze mohou pouze registrovaní uživatelé.
> Vyhledávání software
> Vyhledávání článků

28.11.2018 23:56 /František Kučera
Prosincový sraz spolku OpenAlt se koná ve středu 5.12.2018 od 16:00 na adrese Zikova 1903/4, Praha 6. Tentokrát navštívíme organizaci CESNET. Na programu jsou dvě přednášky: Distribuované úložiště Ceph (Michal Strnad) a Plně šifrovaný disk na moderním systému (Ondřej Caletka). Následně se přesuneme do některé z nedalekých restaurací, kde budeme pokračovat v diskusi.
Komentářů: 1

12.11.2018 21:28 /Redakce Linuxsoft.cz
22. listopadu 2018 se koná v Praze na Karlově náměstí již pátý ročník konference s tématem Datová centra pro business, která nabídne odpovědi na aktuální a často řešené otázky: Jaké jsou aktuální trendy v oblasti datových center a jak je optimálně využít pro vlastní prospěch? Jak si zajistit odpovídající služby datových center? Podle jakých kritérií vybírat dodavatele služeb? Jak volit vhodné součásti infrastruktury při budování či rozšiřování vlastního datového centra? Jak efektivně datové centrum spravovat? Jak co nejlépe eliminovat možná rizika? apod. Příznivci LinuxSoftu mohou při registraci uplatnit kód LIN350, který jim přinese zvýhodněné vstupné s 50% slevou.
Přidat komentář

6.11.2018 2:04 /František Kučera
Říjnový pražský sraz spolku OpenAlt se koná v listopadu – již tento čtvrtek – 8. 11. 2018 od 18:00 v Radegastovně Perón (Stroupežnického 20, Praha 5). Tentokrát bez oficiální přednášky, ale zato s dobrým jídlem a pivem – volná diskuse na téma umění a technologie, IoT, CNC, svobodný software, hardware a další hračky.
Přidat komentář

4.10.2018 21:30 /Ondřej Čečák
LinuxDays 2018 již tento víkend, registrace je otevřená.
Přidat komentář

18.9.2018 23:30 /František Kučera
Zářijový pražský sraz spolku OpenAlt se koná již tento čtvrtek – 20. 9. 2018 od 18:00 v Radegastovně Perón (Stroupežnického 20, Praha 5). Tentokrát bez oficiální přednášky, ale zato s dobrým jídlem a pivem – volná diskuse na téma IoT, CNC, svobodný software, hardware a další hračky.
Přidat komentář

9.9.2018 14:15 /Redakce Linuxsoft.cz
20.9.2018 proběhne v pražském Kongresovém centru Vavruška konference Mobilní řešení pro business. Návštěvníci si vyslechnou mimo jiné přednášky na témata: Nejdůležitější aktuální trendy v oblasti mobilních technologií, správa a zabezpečení mobilních zařízení ve firmách, jak mobilně přistupovat k informačnímu systému firmy, kdy se vyplatí používat odolná mobilní zařízení nebo jak zabezpečit mobilní komunikaci.
Přidat komentář

12.8.2018 16:58 /František Kučera
Srpnový pražský sraz spolku OpenAlt se koná ve čtvrtek – 16. 8. 2018 od 19:00 v Kavárně Ideál (Sázavská 30, Praha), kde máme rezervovaný salonek. Tentokrát jsou tématem srazu databáze prezentaci svého projektu si pro nás připravil Standa Dzik. Dále bude prostor, abychom probrali nápady na využití IoT a sítě The Things Network, případně další témata.
Přidat komentář

16.7.2018 1:05 /František Kučera
Červencový pražský sraz spolku OpenAlt se koná již tento čtvrtek – 19. 7. 2018 od 18:00 v Kavárně Ideál (Sázavská 30, Praha), kde máme rezervovaný salonek. Tentokrát bude přednáška na téma: automatizační nástroj Ansible, kterou si připravil Martin Vicián.
Přidat komentář

   Více ...   Přidat zprávičku

> Poslední diskuze

31.7.2023 14:13 / Linda Graham
iPhone Services

30.11.2022 9:32 / Kyle McDermott
Hosting download unavailable

13.12.2018 10:57 / Jan Mareš
Re: zavináč

2.12.2018 23:56 / František Kučera
Sraz

5.10.2018 17:12 / Jakub Kuljovsky
Re: Jaký kurz a software by jste doporučili pro začínajcího kodéra?

Více ...

ISSN 1801-3805 | Provozovatel: Pavel Kysilka, IČ: 72868490 (2003-2024) | mail at linuxsoft dot cz | Design: www.megadesign.cz | Textová verze