Benchmark kompilátorů GCC, LLVM-GCC, DragonEgg a Clang

Phoronix vydal velký benchmark kompilátorů GCC, LLVM-GCC, DragonEgg a Clang. Testuje se zde jak rychlý kód různé kompilátory generují tím, že sada programů byla zkompilována pokaždé jiným kompilátorem a pak byl otestován a porovnán jejich výkon.

8.11.2010 11:51 | David Watzke | Zajímavý článek

Komentáře

[Jaques Pascal]

na FPC nema ani jeden...

[Mti.]

No jo, jenze tezko porovnavat kompilatory, kdyz nejsou stejne. Zejmena, pokud maji jazyky jine vyjadrovaci moznosti. Takhle to vyzni jen jako "ani ne tak vtipny" flame.

Osobne si taky casto placam veci, ktere potrebuji napsat brzo ve fpc/lazarusu (protoze sem v pascalu stravil mladi), ale nedelam si u nich naroky na prenositelnost na jiny stroj a na citelnost nekym jinym uz vubec ne)...

[Bedňa]

Ono keď vymeníš {} za begin a end môžeš to skompilovať cez fpc :) Keď som kedysi písal jeden projekt, tak som sa rozhodoval medzi Pascalom a C, spravil som pár testov na rýchlosť vykonávania programu, obidva dopadli skoro na stotinu rovnaku, tak som to naklepal v Pascale. Dnes to ľutujem že som na tom stratil toľko času, môhol som byť v Céčku guru :)

[default]

Ono keď vymeníš {} za begin a end môžeš to skompilovať cez fpc :)

A když jseš i na ty náhrady dostatečně línej, tak to nahraješ do Oraclu jako Package a taky to bude fungovat.

[Jardík]

Ano, FPC opravdu kompiluje rychle, horší je to s velikostí výsledných binárek, které poměrně rychle rostou. Rychlost výsledného kódu však nemůžu posoudit, nikdy jsem v tom neprogramoval žádnou aplikaci náročnou na rychlost běhu.

[kralyk z abclinuxu]

Ve smyslu rychlosti kompilace? Může být.
Ve smyslu kvality výsledného kódu? To už je poněkud složitější otázka...

[Jardík]

Tak kód je celkem hezký, pokud použijete inline assembler Akorát u x86-64 assembleru to občas emitne nějakej ten špatnej opcode

[kralyk z abclinuxu]

Tak kód je celkem hezký, pokud použijete inline assembler

To mě neznáš

[JoHnY]

Priznam se, ze jsem cekal mnohem horsi vysledky Clangu, ale prijemne me prekvapil. S trochou snahy byl se moh vykonove popasovat s GCC 4.5 nekdy behem pristiho roku, coz je velmi peknej vysledek. Kompatibilita je holt horsi, ale co si budem povidat 90% GNU softu je napsana na miru GCC, takze to neni prekvapujici.

[Jardík]

Já byl naopak překvapen zlepšením GCC 4.6. Jak říkáte za rok, tak v té době sice třeba předežene GCC 4.5, ale už tu bude 4.6 (i když do extrémě zastarávajících distribucí typu ubuntu se dostane až za 5 let).

[Ladicek]

No, tak si ale vezmi, jakou rychlostí se vyvíjí Clang (a potažmo celé LLVM) a jakou rychlostí se vyvíjí GCC. To je nebe a dudy, fakt by mne zajímalo, jak to ti chlapi dělají, že za plus mínus tři roky (Clang opensourcován 2007) dali dohromady překladač C++, který si dovolují označit za production-ready! (Přeloží sám sebe, chromium, boost a určitě spoustu dalších věcí, o kterých jsem neslyšel.) A vedle toho mají slušný statický analyzátor kódu, libclang, pracují na implementaci c++kové standardní knihovny, vlastního debuggeru, a já už fakt nevím.

[Jiří Svoboda]

Pan Ponkrác to vidí jinak.

[Miloslav Ponkrác]

Pan Ponkrác pouze doporučuje si pár let počkat.

Nemá už sílu vysvětlovat, že zatímco když uběhnete 100 m za 30 sekund, snadno to zrychlíte o desítky procent. Zatímco zaběhnete-li 100 m za 11 sekund, nemůžete už velké procentuální zrychlení čekat.

Tedy, pokud se Clang BLÍŽÍ rychlosti gcc, pak každé další přiblížení ho bude stát mnohonásobek času, sil a energie co předchozí krok stejně jako toho běžce na 100 m.

Clang má nevhodnou architekturu a návrh, zato velmi vhodnou a dobře programovatelnou. Dobře se nad ní programuje. Trochu se podobá tomu člověku, který ztratil prsten na trávě, ale hledá ho na chodníku pod lampou, protože je to jednodušší, je tam světlo. Clang má architekturu, na které se dobře pracuje, neudivuje mně, že to jde kupředu. Ale nevhodnou pro dobré výsledky jako C/C++ kompilátor.

Clang má jediné štěstí a smůlu zároveň. Že gcc je mizerně optimalizující kompilátor. Pokud pominu borlandy, hůře optimalizující kompilátor, než gcc nenajdete. Pokud nový kompilátor clang se dokáže porovnávat a ještě zaostávat za nejhůře optimalizujícím kompilátorem, něco to také o něm říká.

Další věc je, že u C/C++ kompilátoru je nutná především spolehlivost a ověřenost. Ponkrác také dobře ví, že poslední rok až dva se za stabilní verzi a tedy produkční prohlásí kdejaká sračka, která by před několika lety nebyla nazvána ani beta verzí. Dnešní open source si s tím hlavu moc neláme.

U kompilátoru C/C++ je nutné ověřit správnost překladu, zároveň dosáhnout rychlý strojový kód (což clang nikdy umět nebude vzhledem k architektuře, jak je navrhnut). Rychlost kompilace je irelevantní a zároveň plus mínus nepřímo úměrná kvalitě výsledného kódu.

Ponkrác už dále nebude clang komentovat, pouze radí si několik let počkat. A pak si položit otázku, kdepak je ten úžasný clang a jaktože se neujal? Jaktože nesplnil očekávání?

A následně si položit po několika letech otázku, proč je linuxová komunita tak nekritická.

[tom]

Delal jsem test rychlosti behu binarek, co lezou z gcc a icc a muzu rict, ze byly srovnatelne. Gcc vytezilo zejmena v prekladu rekurzivnich funkci.

[Miloslav Ponkrác]

Je spousta lidí, co si myslí, že testovat zvládne každý.

Je spousta lidí, co si myslí, že když špatně optimalizující gcc nereaguje nijak zvlášť přepínači na výslednou kvalitu a formu kódu, že kvalitnější překladače rovněž nereagují příliš na na přepínače překladu.

Nicméně, lhát se musí šikovně. To, že gcc a icc vyrábějí srovnatelně rychlý stroják, to je právě ta lež, kterou Vám znalý nezbaští.

Není náhodou, že všechny testy typu gcc, nebo clang se cudně ohlížejí na rychlost kompilace, ale raději příliš neryjí do kvality výsledného kódu, tedy zejména rychlosti. Protože gcc, neřku-li clang by tvrdě zůstal na posledních místech.

Doporučuji Váš test opakovat. Nastavit pečlivě přepínaše jak icc, tak gcc. Icc na přepínače reaguje výrazně, jen brnknete a výsledný kód je jiný. Je to důsledek toho, že kvalitní kompilace je pomalá (z čehož si chytrý čtenář vyvodí, že pokud někdo clang chválí za rychlost kompilace, že výsledkem bude velmi mizerný kód, cokoli jiného fyzikální zákony nepřipouští). Tudíž proto kvalitní kompilátory kvalitní, release překlad umožňují jen pomocí přepínačů.

Dále doporučuji delší kód, trochu delšíé, než je hello world programy.

Pokud Vám gcc a icc vychází srovnatelně, pak je jasné, že jste špatně testoval, případně jste chtěl ovlivnit test ve prospěch gcc.

[tom]

Pokud Vám gcc a icc vychází srovnatelně, pak je jasné, že jste špatně testoval, případně jste chtěl ovlivnit test ve prospěch gcc.

Prekladal jsem tim ruzne implementace jednoho algoritmu pro raytracing a sledoval, co se vyplati optimalizovat rucne a co nechat prekladaci. Upozornim jeste, ze jsem se zajimal o C a ne o C++.

[Bilbo]

icc jsou optimalizované pro Intel procesory. Ve starších icc byly dokonce featury, co běh na AMD procesorech vysloveně mrvily (pokud to detekovalo Intel, použilo se SSE/SSE2/MMX podle potřeby, pokud to detekovalo AMD, tak se spustil "obecný x86 kód", kde nebyly použity SSE, SSE2, MMX ani nic dalšího, i když to ten AMD procesor taky podporoval - a rychlost pak logicky šla dosti dolů)

Teď už to snad nedělají, ale i tak je možné, že na AMD procesorech to co vyleze z gcc předběhne to co vyleze z icc.

Navíc jsou zdrojáky, kde optimalizace moc nezmůžou - např. pokud výsledný kód volá různé knihovny nebo funkce jádra (což může být třeba benchmark zkompilovaného apache, který věčně něco čte z disku a posílá po síti), kde se stráví většinu CPU času a na tom jak moc je optimalizován ten zbytek už pak moc nesejde.

[Martin Mareš]

To, že gcc a icc vyrábějí srovnatelně rychlý stroják, to je právě ta lež, kterou Vám znalý nezbaští.

No především nikdo znalý nikdy nezbaští jakýkoliv cizí benchmark. Po zkušenostech s tím, co o Céčku a překladačích říkáte, Ty Vaše teprve ne.

[Jiří Svoboda]

Ano, můj komentář byl sice rýpanec, ale s ukrytým respektem. Už delší dobu vás vnímám jako člověka s rozsáhlými vědomostmi v některých oblastech a proto považuji vaše příspěvky za hodné přečtení.

[Jardík]

Nevíte náhodou, jak je na tom v tom C++ kompilátoru podpora C++0x? Těch 5 věcí, co zmiňují na webu se mi zdá hodně málo, jestli je to všechno ...

[Ladicek]

Netuším, ale na webu vysloveně píšou

Current Status

Clang is still under heavy development. Clang is considered to be a production quality C, Objective-C, C++ and Objective-C++ compiler when targeting X86-32, X86-64, and ARM (other targets may have caveats, but are usually easy to fix). If you are looking for source analysis or source-to-source transformation tools, clang is probably a great solution for you. Clang does not support C++'0x yet, please see the C++ status page for more information.

Odhaduju, že až bude C++0x finální, bude implementace docela brzo.

Mne zatím zajímala hlavně libclang, o zbytku vím jenom tak co jsem někde přečetl.