Názory k článku
Výkonnostní vliv -O3 -march=native je spíš záporný
-
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.
-
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.
-
Dodám že jsem to měřil přes hyperfine, nejmenší počet vzorků byl 20, rozptyl nepřesáhnul 1 % času.
-
Novinářství level Ježek. Nedá pro jistotu odkaz na ten Phoronix a raději přehlédne i diskuzi na Phoronixu, kde kupříkladu někdo upozornil na skutečnost, že GCC s -march=native neumí optimalizovat pro targety, které mají různá jádra a různě velké cache.
Pro připomenutí: i5-12900K má 6 performance jader a 4 efficient jádra s různě velkými L2 cache.
Článek:
https://www.phoronix.com/scan.php?page=news_item&px=Linux-5.19-O3-March-NativeNo a co se mezitím nestalo? Máme tu GCC12, které už má patch pro nesymetrický Alder Lake. Viditelně to v testech zvyšuje výkon. Bohužel zatím nikdo netestoval kernel...
https://www.phoronix.com/scan.php?page=article&item=gcc-12-alderlake&num=1 -
Uplne nerozumim tomu, proc pres nejaky #define nejsou v kernelu oznacene fce, ktere by melo smysl optimalizovat "jinak" nez standardne. Slo by pak volit strategie pro co je kernel urcen, jestli pro server ktery ma obrovskou cache a chceme rychle I/O, apod., nebo to je nejaky lowend pocitac, kde ma smysl mit -Os :).
