Vlákno názorů k článku
Linus Torvalds je proti zavedení úrovní architektury x86-64 v1–v4 do jádra od cc - Podle mě Linus nemá pravdu. Co se týče rozšíření...

Podle mě Linus nemá pravdu.

Co se týče rozšíření tak opravdu x86 nemá žádný standard úrovní rozšíření od výrobců CPU (proč taky, ty nezajímá historie), na druhou stranu dnes nikdo nepíše aplikace tak, že by detekoval každou CPUID feature a program by měl 50 různých implementací nějaké funkce, která by byla pro každou možnou kombinaci instrukcí, která ta funkce dokáže využít.

Příklad: Zrovna ta instrukce CMPXCHG16B byla přidaná hodně brzo (dřív než třeba BMI nebo BMI2) a pokud CPU má BMI2, tak má BMI i CMPXCHG16B.

Není potřeba nic hádat, stačí se podívat na mikroarchitektury nějakých 10-15 let zpět a od toho je možné odvodit úrovně rozšíření, a toto přesně GLIBC dělá. Mám pocit ale, že právě ty v1 až v4 se specializujou hlavně na SIMD, ale třeba CPU s AVX2 má AVX, F16C, CMPXCHG16B, ADX, BMI, BMI2, atd... (a toto lze odvodit právě z těch dostupných mikroarchitektur).

Takže za mě ty úrovně mají právě sjednotit různé mikroarchitektury pod nějakou úroveň aby právě těch kombinací nebylo moc. No a pokud někdo má mikroarchitekturu, která byla zrovně někde mezi v2 a v3 (ale nemá všechno co v3 požeduje) tak prostě bude mít v2.

ARM toto má definované trochu líp (ARM8.X kde X přesně definuje požadované a volitelné rozšíření CPU).

Tohle má smysl řešit z hlediska buildů, pro kterou verzi architektury je zkompilovaná - a souhlas, že výsledkem by mělo být racionální množství knihoven / programů. V jisté době byly třeba populární balíčky I386 a I686.

IMHO Linus spíš mluvil o source code - kde má smysl #ifdef AVX2 ... místo #ifdef x86_64_v2 . Takže pustím-li kompilátor s -mcpu=native, tak mi ten kompilátor přesně předá, co je na tom procesoru k dispozici, nebo s -mcpu=skylake dostanu AVX2 a dvacet dalších, ale rozhoduju se u specifické funkce podle AVX2 (bo potřebuje YMM registry), ne podle vX. Z hlediska build distribuce vyprodukuje několik kopií kódu, které jsou relevantní pro danou vX, tím, že předá daný flag kompilátoru. A pak se buď nainstaluje specifická vX nebo linker v runtime vybere specifickou vX, je-li jich několik.

Tohle by mělo platit pro obecný kód, kde výhody detekce v runtime by byly zanedbatelné nebo kontraproduktivní (cena za detekci převýší cenu za užitek). Některé knihovny (video, obrázky, machine learning, math) mají optimalizovaný kód pro více architektur a vybírá se až v runtime, buď na základě if-else a přiřazení do pointeru nebo chytřeji dynamicky v době symbol resolution).

Jenže toto přesně dostaneš a v tom je to kouzlo.

Pokud třeba použiješ gcc "--with-arch_64=x86-64-v3" tak to __AVX2__ právě bude definované, protože ten v3 level AVX2 vyžaduje. V kódu není potřeba nic upravovat.

6. 12. 2024, 00:09 editováno autorem komentáře

Ale prave v tom by se melo rozlisovat mezi statickou a dynamickou variantou.

A staticky kompilovat neco pro _vX je takove meh, at si to jako tedy delaji distribuce, ktere to lip nedokazou, a v tom je to, proc se Linus certi - protoze jadro to prave dokaze lepe resit v runtime ze co je dostupno (a z urcitych duvodu se pouziti extra registru resi vice explicitneji, viz nize).

Souvisi to s tim, ze jak se pracuje s temi rozsirenymi registry v jadru - musi se to explicitne obsluhovat, takze autor o tom musi vedet / vi o tom, protoze pak nastava jina prace u kontext switchu. Typicky je to duvod proc je pouziti FPU v jadre velke no-no, ale s prichodem uzitecnejsich veci se tam vytvoril urcity famework prave na obsluhu sse/avx/aes-ni - pro zlepseni vykonu sw-raidu nebo sifrovacich algoritmu - to jsou veci kde to autor kodu explicitne vetvi podle dostupnych cpuflags a implementace existuji na ruzne varianty.

TLDR: pokud v jadru chces pouzit sse/avx, tak se musi "odswapovat" obsah tech registru (tedy spis ulozit na stack), protoze by-default se na ne nesaha a nemeni se, a po vykonani optimalizovaneho kernel kodu je zas obnovit. Tohle samotny kompilator nezvladne resit - v jadru to chodi proste jinak.

pouzivas slovo "mikroarchitektura" spatne. Ta opravdu nerika to, ze jake instrukce CPU podporuje, ale resi hlavne JAK se instrukce vykonavaji (z pohledu prejmenovani registru, branch prediction, spekulativniho vykonavatni, atd).

Divej, výbobci x86 CPU k mikroarchitektuře přiřazujou i ty rozšíření a další kýbl věcí, takže nevím proč bych se tu měl teď hádat zrovna o tom, co všechno si lze pod tím slověm "mikroarchitektura" představit. Když řeknu Zen 4 tak každž ví, že ten CPU má AVX-512 a je to právě ta mikroarchitektura, která to podporuje.

Nechápu proč bych tu měl řešit něco takového sorry :)

"Když řeknu Zen 4 tak každž ví, že ten CPU má AVX-512"

No vidis a presne tohle neni pravda. Az se rozhodnou vyrabet nejaky ten atom, tak z toho treba zrovna to avx skrtnou, ale arch bude stejna.

Pokud AMD udělá vlastní "ATOM" tak mikroarchitektura právě stejná nebude...

AVX-512 stejně musí povolit OS, můžeš to odstranit pomocí mikrokódu (tak jak to udělal Intel), ale takto můžeš zmenšit i ten ROB popř. penalizovat nějaké jiné instrukce (třeba dopad nějakých microcode updatů na latenci gather instrukcí u Intelu),.

Kdybych to shrnul, tak jistý si nemůžeš být dnes asi ničím, ale každá mikroarchitektura něco přináší a třeba rozdíl Zen4 a Zen5 ve vykonávání AVX-512 je propastný, a tady jde o uarch (mění se latence, mění se max. IPC, atd...)

Ale AMD už ořezaná jádra na skoro polovinu vyrábí, "c" varianta (Zen 5c, Zen 4c). A stejně jako opravdu malá jádra v ARMu mají plný instruction set. Bez toho by byl křemík ve velkých jádrech navíc jen těžítko jako u Intelu (někdo honosně nazve pro rozvod tepla).