Vlákno názorů k článku
Linus Torvalds je proti zavedení úrovní architektury x86-64 v1–v4 do jádra od RDa - Ano, idealni stav by by, kdyby jadro a...

Ano, idealni stav by by, kdyby jadro a system/appky byly pouze 32bit nebo 64bit, a veskere optional instrukcni sady se vyuzivali na bazi runtime detekce.

Takze je porad micek na strane glibc, ktere ma co delat v tomto smeru - namisto toho fixovani se na imaginarni urovne.

Runtime detekce ti zere pamet i vykon cpu, takze dost casto tim, ze ve finale vyberes "lepsi" cestu kodem nic neziskas. To bys leda musel v ramci startu provadet jeste nejakou rekompilaci. Coz by prozmenu zapricinilo, ze boot by netrval (nekdy) desitky minut ale klidne hodiny. A setrvale by se to zhorsovalo s tim, jak pribyvaji dalsi a dalsi varianty.

Nehlede na to, ze specielne v kernelu si dovolim predpokladat spoustu kodu, u ktereho chces aby se provadel presne tak, jak je napsany.

To co zere vykon, je nevhodne zvolena granularita. Nebudes prece vetvit v ramci vnitrni smycky. A pokud variace nema prakticky prinos (instrukce se nepouzije ve smycce), tak je uz od pocatku zbytecne takovou instrukci pouzivat.

Jenze tohle ty principielne nemuzes vedet, dokud ten kod nespustis. Ty v dobe kompilace nevis, jestli ta vetev pobezi 1x nebo milionkrat. A nevis to ani v okamziku, kdy se rozhodujes jestli pouzit variantu A nebo B. Jiste, muzes tam zavist sofistikovanejsi algoritmus rozhodovani, ale to te bude stat jeste vic.

Ale no tak, nedelejte naivu, co ocekava, ze vsechny problemy za nej vyresi automaticky pouze prekladac.

K uspesnemu produktu je potreba trocha autorske spoluprace - vemte si za priklad treba memcpy - runtime mate parametr o velikosti kopirovane oblasti, od ktere si muzete odvodit runtime narocnost a vetvit podle kategorie, zda se jedna o malou nebo velkou kopii. V pripade velke kopie pak muzete vetvit podle velikosti dostupnych vektoru na mmx/sse/avx/avx512.

Takto to ma uz jen jedinou runtime nevyhodu - ze pouziti vetsich vektoru znamena jednak prodlevu pro zapnuti dane casti cipu (nevim zda se tyka i integer, nebo jen float cest), a druhak podtaktovani jadra (casto u avx).

Prakticky vzato - ani pouziti zdanlive optimalni instrukcni sady vam nemusi zajistit vyssi vykon, a libc by klidne mohlo zustat u konzervativnich instrukcnich sad. Moderni cpu si skrze uops s tim poradi.

Takovy runtime variabilni kod existuje v mplayer/ffmpeg (libav?) kde je dct/idct implementace vybrana pri startu podle cpu flagu, a to uz dava vetsi smysl.

Nepouziti runtime optimalizace je jenom lenost tvurce.

Některé aplikace to řeší generovaným sledem instrukcí (JIT). Nebo se natáhne připravený vybraný podkód.

EDIT: Byl jsem pomalejší. K vysvětlení memcpy výše přidám, že takhle funguje i highlevel API na Applu. Tam se neřeší, např. jaký typ stromu se má použít pro data, on si ho vybírá a předělá sám podle obsahu (jak se časem mění).

5. 12. 2024, 20:05 editováno autorem komentáře

Jenže na tenhle přístup se strašně špatně dělá support, když musíte testovat všechny možné kombinace (jestli SW dobře funguje), a pak ještě když se řeší problémy. Samozřejmě na domácí použí je to skoro jedno, ale máme tady komerční distribuce, kde si zákazník ten servis platí.

Pokud se bavime o appkach.
Loader ti muze loadnout binarku i dle mikroarchitektury. Ty headery v binarkach a rozdilne pojmenovani nejsou pro srandu kralikum. Bez rekompilace. Je mozne distribuovat x variant binarek a loader si vybere dle headeru i specifickou mikroarchitekturu.
Linuxaci tohle objevili docela pozde (na rozdil treba ehm od solarisu a blahe pameti isaexec - kompletne stranny pohled:) nebo widlim PE) ale LDcko uz to nejaky ten patek umi.

Jestli chceš někoho popíchnout, musíš napsat, že Apple tohle používá od roku 1994 a použil to zatím skoro ve všech svých výměnách procesorů (68kPPC, PPCi386, i386x64, x64aarch64, osobně jsem měl v ruce binárku se 4 architekturami PPC32, PPC64, i386, x64)). Jasně, že Solaris to měl ještě o pár let dříve ale nikoho tím nedojmeš ;-)