V dnešním testu srovnám klasický starý dobrý překladač GCC s překladačem LLVM. Test se bude týkat míry optimalizace celočíselných aritmetických výpočtů. Představení obou produktů :

GCC : Balík GNU Compiler Collection (GCC) je součástí projektu GNU. Překladač GCC se stal ve světě svobodného softwaru de facto standardem. Rovněž se těší značné popularitě i na nesvobodných platformách; např. ve Windows prostředí Dev-C++, portování svobodného softwaru s pomocí CygWin…, na Mac OS např. vývojové prostředí XCode…

Vývoj GCC započal v roce 1985. Návrh kvalitního kompilátoru patří mezi vůbec nejkomplikovanější praktické výzvy. Například vlastní kompilace v GCC probíhá velmi zjednodušeně tímto způsobem:

• Zdrojový kód se převede na abstract syntax tree (AST).
• Dále se převede do na programovacím jazyku již nezávislé formy GENERIC a GIMPLE.
• GIMPLE se rozbije na tvar static single assignment (SSA).
• Nyní se v několika rundách aplikuje série optimalizačních algoritmů. (Samozřejmě drobné optimalizace probíhají i v ostatních krocích.)
• Z elementárního SSA je kód znova složen do kódu v jazyce Register Transfer Language (RTL).
• Zdrojový kód v jazyce RTL je zkompilován do assembleru (resp. strojového kódu) cílové architektury.

Postupem času se GCC výrazně zlepšoval. V kvalitě generovaného kódu se GCC dnes přinejmenším vyrovná komerčním kompilátorům jako Intel C++ Compiler. V čem GCC předbíhá konkurenci je podpora různých procesorových architektur a to včetně různých pokročilých možností jednotlivých platforem (např. vektorizace za použití sady instrukcí/registrů typu SIMD). Podle Wikipedie GCC podporuje nejméně 53 cílových procesorových architektur, pro dalších 16 existují rozšíření a navíc GCC podporuje i některé architektury virtuálních strojů (např. Java bytecode). Pochopitelně mnohé z těchto architektur již vyhynuly; obecně však lze říci, že GCC podporuje všechny důležité mikroprocesory. To kontrastuje např. s konkurenčním Intel C++ Compiler. Návrh algoritmů GCC umožňuje mimo jiné kvalitní optimalizaci pro jakoukoli podporovanou architekturu.

(Poznámka : Pochopitelně pro různé architektury dokonalá optimalizace vede k různým algoritmům. Např. architektury s vysokým počtem základních aritmetických registrů (např. Itanium nabízí 128 registrů) mohou na rozdíl od architektur s nízkým počtem registrů (např. x86) vyhodnocovat delší výrazy, aniž by museli vícenásobně číst tutéž hodnotu z paměti. Proto u architektur s nízkým počtem registrů bude optimalizace směřovat k snižování Horton–Strahlerova čísla u vyhodnocovaných výrazů.)

LLVM : V roce 2005 byla vydána první verze kompilačního příslušenství Low Level Virtual Machine (LLVM). Tvůrce University of Illinois uvolnil LLVM pod licencí ve stylu BSD. Tvůrci systémů z rodiny *BSD koketují s možností využívat LLVM. Připomenu, že takovéto licence podporují tvorbu odvozeného proprietárního softwaru; proto se o LLVM zajímají i tvůrci nesvobodného softwaru (např. Apple). Vedle originálního frontendu Clang existuje i frontend GCC-LLVM, který jsem použil při testu. Na rozdíl od GCC je dnes tržní podíl LLVM zanedbatelný a LLVM je využívám téměř výhradně nekomerčním způsobem.

Návrh datových struktur využívaných v LLVM je méně sofistikovaný než v případě GCC. Jako výhoda LLVM je pak uváděna výrazně vyšší rychlost kompilace a nižší paměťová náročnost. Někteří příznivci LLVM tvrdí, že generovaný kód je oproti GCC více optimalizovaný.

Způsob provedení testu

Test jsem provedl v podstatě stejným způsobem jako v příspěvku Optimalizace v GCC. Jednoúčelovým programem v Javě jsem vygeneroval množství náhodného zdrojového kódu v jazyce C v rozsahu několika desítek tisíc řádků, který jsem vložil do kostry programu. (Způsob generování kódu téměř vylučuje aritmetické chyby jako dělení nulou nebo přetečení proměnných.) Nad rozsah dřívějšího příspěvku jsem vytvořil druhou odvozenou verzi, která generuje zdrojový kód, který na cílové architektuře x86 půjde jen stěží optimalizovat. Tento kód budu označovat jako “neoptimalizovatelný” v kontrastu s prvním “optimalizovatelným” kódem.

Jak jsem slíbil založil jsem si svou pracovní prezentaci a na ní vytvořil sekci pro různé přílohy k tomuto blogu. Konkrétně přílohu k tomuto článku naleznete zde. (Pozor, stránky jsou stále ve výstavbě.)

Při sestavování skutečných aplikací by byl vliv optimalizace při kompilace menší, protože například spouští i kód (sdílené knihovny, jádro), který není vytvořen při kompilaci aplikace. Testy vlivu volby kompilátoru na výkon aplikací najdete např. na serveru Phoronix.

Výsledky měření

Přesné velikosti změřených hodnot najdete v protokolu z měření dostupného na zmíněné  stránce. S pomocí přílohy si můžete test také zkusit s různými parametry.

Závěr

V případě kompilací bez optimalizace (přepínač -O0) bylo LLVM více jak šestkrát rychlejší než GCC a i vygenerovaný kód byl lepší. Při kompilací s nejnižší úrovní optimalizace výrazně dominuje LLVM. Při vyšších úrovních optimalizací však vede GCC. Na nejvyšší úrovni optimalizace (bez použití profileru) vede GCC v rychlosti kompilace i v rychlosti generovaného kódu.

Při produkčním nasazení jde především o kvalitu přeloženého programu. Výnosy ze zrychlení běhu aplikace jsou nesrovnatelně větší než náklady na delší kompilaci. Takže za celkového vítěze považuji GCC.

Štítky: profesionální aplikace, Testy

Komentáře v diskuzi

Přidat komentář

Jméno

E-mail, nebude zveřejněn

Web

Ochrana proti spamu: (povinné)*
Opište prosím text z obrázku.