Vlákno názorů k článku
Clang 16 je v průměru o 5 % rychlejší než GCC 13 na Raptor Lake od hubicka - Problém toho benchmarku je, že GCC a Clang...

Problém toho benchmarku je, že GCC a Clang nejsou stejně konfigurované. Při benchmarkovaní PIC kódu je třeba použít -fno-semantic-interposition a také u některých benchmarků používá GCC -O2 a clang -O3 -march=native

Podívmám se na to ale podrobněji :)

Od podrobnějšího sledování phoronixu jsem před lety odešel hlavně proto, že mi (v podstatě všechny) články přišly psané jen s velmi povrchním porozuměním.

Tím nemyslím, že nemá smysl je sledovat, jen že to chce vzít v úvahu při dělání závěrů – například toho typu jako v titulku této zprávičky.

Mi to spíš přijde, že clang umí líp autovektorizaci. Třeba ten GraphicsMagick benchmark je úplně jasný. Ze zkušenosti vím, že pokud překladač zvektorizuje jen část nějaké smyčky (nebo nic), tak je to obrovský problém v porovnání s překladačem, co to zvládne celé. Druhá věc může být i jiný limit pro inlining. Jestli je clang třeba agresivnější než GCC ale nevim - když chci inline, tak __attribute__((al­ways_inline)) a nemusím to řešit :)

Obecně na -O3 je GCC agresivnější v inliningu i vektorizaci. Celkem pravidelně to měříme na SPEC a TSMC benchmarku, kde GCC v průměru vede.

Díval jsem se zatím na jpegxl, kde je rozdíl největší. Překládá se to pomocí cmake a explicitně přidávají na konec CMAKE_CXX_RELE­ASE_FLAGS -O2 takže i když člověk nastaví -O3 z command line tak se to přepne na -O2. Překladač pak volá jako -O3 ... -O2 -DNDEBUG, což GCC interpretuje jako -O2

Na -O2 má clang agresivnější nastavení vektorizéru: dovolí si generovat větší kód ale víc vektorizuje. Možná je to tím. Mrknu na to.

Problém Phoronixu je, že se moc nesnaží udělat benchmarky zodpovědně. Jde hlavně o to vyrobit článek, co na který lidi kliknou.

V tom případě mě zajímá, jak by si vedl ICC se svou autovektorizací.