Názory k článku
Clang 17 je v průměru o 5 % rychlejší než GCC 13 na Meteor Lake

A kde se schovalo ICC ?

ICC je teď Intel Compiler Classics, Intel už ho moc netlačí. Nový Intel oneAPI Compiler je založený na LLVM.

https://en.wikipedia.org/wiki/Intel_C%2B%2B_Compiler

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 :)

Škoda, že člověk musí vybírat kompilátor zejména s ohledem na to, na kterém již schváleném standardu C++20(!) ten který kompilátor (ne)selhává.

5. 1. 2024, 12:53 editováno autorem komentáře

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

Na problém modulů chystám krátké zamyšlení v podobě blogpostu zde na rootu, snad se dokopu k tomu to dopsat :)

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