Vlákno názorů k článku
Výkonnostní vliv -O3 -march=native je spíš záporný od RDa - To pak ale znamena, ze kompilator ma spatne...

To pak ale znamena, ze kompilator ma spatne nastavene predpoklady architektury, kdyz vyssi uroven optimalizace znamena ve vysledku nizsi vykon.

Mel jsem za to, ze optimalizaci dela kompilator v mezich ktere dovoluji vzdy zvysit vykon, pouze na ukor citelnosti / debugovatelnosti vysledneho strojoveho kodu.

Nebo je to jenom problem kernelu (specificky z pohledu jak a co funguje.. ze se jedna o kratce aktivni kontexty, vicemene se zakazanym fpu), a pro userspace je tato vyssi optimalizace jiz prinosem?

ano, kernel je dost specifický, -O3 dělá masivně loop unrolling a inlining, což pro hodně programů není vhodné. Linus správně na konci poznamenává, že chce přestat o -O3 přemýšlet jako o novější verzi, ale jen o jiném algoritmu.

V praxi je -O3 poměrně solidí pro např. parsery různých formátů, pro dekódery, už ale není vhodné pro streamování, pro masivní zpracování dat, aspoň takový mám dojem, už ho moc nevídám, náročnost na testování výrazně převyšuje zisk.

Pokud ti -O3 zvektorizuje a inlinuje kód v nějaké hot smyčce, tak právě pro masivní zpracování dat je vhodný. Kernel je ale úplně něco jiného. Jak jednou řekl sám Linus, menší kernel je lepší, jenže s -O3 je kernel vždycky akorát větší.

Bylo by dobré udělat i benchmark s -Os

Přesně. Me by třeba velmi zajímal rozdíl mezi -O2 a -Os.

Otazka je co by mel kernel delat - rekneme - v nekolika do sebe zanorenech smyckach. Jake slozite datove struktury by mel prochazet.
Od kernelu bych spis ocekaval rychle dovnitr a rychle ven. A pametova narocnost dat. struktur v kernelu by mela byt co nejmensi.
A pokud je kod kernelu v cache tak je to urcite lepsi.

Sem tam inline assembly, hodně různých bariér a synchronizací... a hlavně je to v podstatě celé integer aritmetika a logika, která se od první amd64 tolik nezměnila. Hádám (a teď si to úplně tahám z klobouku) že tam O3 přidá pár "nájezdů" do optimalizované cesty (jak byste přeložili "prelude"? ve smyslu inicializační kód) které se ale nakonec nevyužijí, rozbalí smyčky, kód naroste a přestane se trefovat cache.

V Gentoo mám už 20 let (to letí :) -O2 -march=native, udělám si pár benchmarků jak mi to vlastně pomáhá na současném Ryzenu. Naposled jsem to dělal na i7, kde mi to dávalo výrazný boost v encodování videa, něco jako +30 % v libx264.

13. 7. 2022, 15:30 editováno autorem komentáře

Zajímavé :) -march=native jednoznačně zrychluje encoding, ale -O3 je horší než -O2. Mezi CFLAGS Archlinuxu a těmi na Gentoo je výkonnostní rozdíl 20 % ve prospěch Gentoo při encodování H.265 1080p videa (-codec:v libx265 -crf 18 -preset slow).

| CFLAGS            | x264 [s] | x265 [s] | x264 [%] | x265 [%] |
| ------------------| -------- | -------- | -------- | -------- |
| -march=x86-64 -O3 |     87.2 |    413.5 |    102.1 |    103.5 |
| -march=x86-64 -O2 |     85.4 |    399.5 |    100.0 |    100.0 | (arch)
| -march=x86-64 -Os |     83.7 |    356.0 |     98.0 |     89.1 |
| -march=native -Os |     82.1 |    383.6 |     96.1 |     96.0 |
| -march=native -O3 |     78.6 |    324.8 |     92.0 |     81.3 |
| -march=native -O2 |     73.8 |    321.9 |     86.4 |     80.6 | (gentoo)

HP ENVY x360 15" s AMD Ryzen 7 3500U, gcc-12.1.1, ffmpeg-4.4.2, x264-0.0.20220222, x265-3.5. -march=native se expanduje na -march=znver1 -mtune=znver1.

To znamená, že -Os je lepší než -O2? Nebo jsem něco přehlédl/nepocho­pil?

-march=generic -Os je v téhle aplikaci, na tomhle procesoru, s těmito verzemi softwaru rychlejší než -march=generic -O2. Myslím že to nejde zobecňovat.

S -march=native je to naopak, -O2 je výrazně rychlejší než -Os.

14. 7. 2022, 16:58 editováno autorem komentáře

Dodám že jsem to měřil přes hyperfine, nejmenší počet vzorků byl 20, rozptyl nepřesáhnul 1 % času.