Clang 17 je v průměru o 5 % rychlejší než GCC 13 na Meteor Lake
Server Phoronix včera přinesl testy kompilátorů GCC 13 a Clang 17 na notebookovém procesoru Intel Meteor Lake Core Ultra 7 155H. V průměru byl Clang rychlejší o asi 5 %.
Předchozí testy Phoronixu také potvrzují, že Clang je v poslední době o něco rychlejší než GCC a to také na AMD Zen4 (o 4 %), tak i na Intel Raptor Lake (o 5 %).
(zdroj: phoronix)
ICC je teď Intel Compiler Classics, Intel už ho moc netlačí. Nový Intel oneAPI Compiler je založený na LLVM.
ICC jako takový už není podporovaný a postupně je vyhazovaný z různých projektů (třeba Qt) - jejich nový compiler je založený na LLVM a nedefinuje ani __INTEL_COMPILER makro. ICC je dávno mrtvý, Intel sám píše "Intel C++ Compiler Classic (icc) is deprecated and will be removed in a oneAPI release in the second half of 2023."
Teď je jen otázka, kdy se přídá Microsoft a z MSVC udělá jen clang frontend :)
No vzhledem k tomu jaké featury upřednostňuje C++ committee se není moc čemu divit. Miliony člověkohodin se spálí jen na moduly, které jsou úplně na nic a běžnému člověku přinesou akorát problémy a nové wtf zážitky.
Ale to byl jen příklad. Když ono stačí použít knihovny a potom čekání na nějaký nový C++ standard nedává smysl.
Edit: toto byla reakce, která se z njakého důvodu postnula jinam...
5. 1. 2024, 13:12 editováno autorem komentáře
My (toolchain team v SUSE) samozrejme GCC vuci clangu pravidelne benchmarkujeme. Nam GCC vychazi lepe (napriklad SPECint2017, standardni benchmark na kterem se prekladace testuji, je o 9% rychlejsi s -march=native -flto -Ofast a PGO, s -O2 je rozdil mensi, cca 4%).
S Phoronixem je potiz, ze neustale meni sadu benchmarku a velkou cast ma spatne nakonfigurovanou (provnava jabka s hruskama). GCC ma tracking bug kde se overuji a pripadne opravuji rozdily
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79704
Koncem roku jsem treba fixnul bug, co vyrazne zpomaloval jpegxl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109811
a hele, u novych vysledku Larabel jpegxl vynechal :)
To je fakt, že ty benchmarky mění a že některé testy jsou divné. Ale zrovna v tomto posledním srovnání je ze 128 (náhodně?) vybraných testů Clang rychlejší ve 100 z nich (78 %).
Myslim si, ze nevybira testy nahodne. Chce aby clanek byl clickbait a vybira testy tak, aby to vyslo prekvapive.
Obcas zase vybere testy tak, aby vyhralo gcc..
Zatim jsem zkusil tri testy.
Z toho se mi reprodukuje jeden https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113235
GCC binarka jde dvojnasobne zryhlit zvetsenim limitu pro unrolling (coz je celkem snadna vec). To je zajimave a mozna to zkusim zmenit v defaultu. Ostatni dva testy byly sum.
Zase z takové fikanosti bych ho nepodezříval :) Ale možná udělá testů víc a které se mu nehodí, tak ty tam nakonec nedá.
To co běžně používám běžně v práci (lammps) je stále rychlejší v GCC než v Clang a tak to má i Michael.
Nemůže ten unrolling zase v některých případech škodit? To bude těžké naladit univerzálně. Neřeší to elegantně PGO? Ale lidi to zatím moc nepoužívají.
Jinak děkujeme za práci, co pro GCC děláte :)
Já jsem dlouho věřil, že to je náhoda, ale bavím se o tom s Michaelem (Larabelem) léta. Ty testy nejsou vybrány náhodně a nejedná se o chyby. Pokud člověk najde problém, Phoronix chybu nepřizná, neopraví a publikuje nesmysl dál.
Mně dlouhodobě zajímají testy, které nejsou standardní SPEC. Pracuju na link-time optimalizaci a na to potřebuju setup podobnější cílovému nasazení.
Testovat zodpovědně překladače není lehké. Velká část benchmarků vyjde naprosto stejně v obou překladačích, protože oba si s interní smyčkou poradí dobře. Hodně benchmarků je memory bound, tráví čas v knihovnách a nebo mají větší šum, než je rozdíl v datech.
Tak třeba ten jeden test, který vybral aby GCC jednou pořádně vyhrálo, cray, je naprostý nesmysl. Michael ho uvédí jako multithreaded raytracer, ale je to kraťoučký prográmek co umí posílat paprsek na kouli. Trávi všechen čas tím, že počítá průsečík (ray_sphere). GCC má chytřejší inliner a přijde na to, že paprsek se sice mění ale koule zůstává a když se zinlinuje relativně velký ray_sphere, tak velká část výpočtu je invariantní ve smyčce.
To je sice hezké, ale o výkonu skutečného raytraceru to nic nevypovídá.
Jinak na letošním mentoru GSoC jsem se o benchmarkování měl slot, kde byly vývojáři z google a applu. Diskuze se svezla na Phoronixi benhcmark suite. (Oni ho považují za úplně neužiterný a zaujalo je, že se na něj dívám). Dozvěděl jsem se jednu zajímavost. LLVM s -O2 s už netuní na stavbu celé distribuce a Apple používá na většinu kódu -Os. Google je na tom podobně pro mobilní buildy. Interní velké appky zase používají -O3 a profile feedback.
Výsledek je, že tunění -O2 i -v -Os v LLVm je jiné než u nás. GCC definuje -O2 jako ten mód kterým je dobré postavit většinu distra (má dobrý tradeoff mezi výkonem a velikostí kódu). -Os je nejmenší možný kód.
Takže LLVM s -Os generuje větší kód co není pomalý a je to vlastně obdoba našeho -O2. Funkci našeho -Os pak nahrazuje LLVMkové -Oz. -O2 v LLVM pak má vpodstatě úkol dávat pokud možno lepší výkon než -O2 v GCC, ale nebere se v úvahu velikost kódu. LLVM tak může víc inlinovat, a vektorizovat. Taky unrolluje by default.
Velká část benchmarků v Phoronixu má špatně nastavené předávání flagů skrz build systém. Protos se pak staví s -O2. Protože GCC a LLVM má jinou definici -O2, tak LLVM -O2 vyjde rychlejší. Časy kompilace a velikosti binárek Larabel přestal uvádět.
Jpeg-XL knihovna například v cmakesouboru vybírá flagy, kterýma přepisuje flagy nastavené z command line. Přidávala nakonec -O2.
To opravili https://github.com/libjxl/libjxl/issues/2970
Podobná situace je častá, viz diskuze v tracking bugu o jiných testech.
Takže Phoronixí testy jsou užitečné na hledání anomálií, které často mají triviální fix. Ale je škoda, že to prezentuje jako vyrovnané srovnání výkonu, což to není. Také je škoda, že testusite neopravuje. Otevřená varianta pro SPEC by se hodila.
6. 1. 2024, 10:30 editováno autorem komentáře
Já třeba používám clang kvůli ergonomii.
Dám příklad, mám codebase, kde nechci aby některé cykly byly unrollované, protože vím, že budou mít jen pár nebo dokonce žádnou iteraci. Tak si udělám makro
#define PRAGMA_NOUNROLL _Pragma("nounroll")
GCC to má trochu jinak, tak musím napsat:
#define PRAGMA_NOUNROLL _Pragma("GCC unroll 1")
Problém je, že GCC začne házet warningy, že pragma byla u některých cyklů ignorovaná a tyto warningy nejde vypnout... Další věc je třeba funkční __builtin_assume v clangu, atd...
Já vím, že to jsou fakt maličkosti, ale člověka to za nějakou dobu přestane bavit a začne používat jen clang a podporu GCC má jen pro ostatní aby se jim to zkompilovalo, kde tyto vychytávky jsou vyplé.
