Nedávno Intel odhalil plán (či návrh) pročištění platformy procesorů x86 o určité legacy funkce – tzv. architekturu x86-S. Vypadá to, že k ní se teď přidává další plán na modernizaci tradiční instrukční sady používané v osobních počítačích. Budoucí CPU dostanou rozšíření Intel APX (Advanced Performance Extensions), které prolamuje některé historicky dané limity této 40leté instrukční sady a do určité míry je přibližuje novějším architekturám.
APX: Víc registrů
Rozšíření APX neboli Advanced Performance Extensions se týká prakticky všech programů, čímž se liší od rozšíření přidávajících SIMD nebo jiné specializované instrukce (i v těch teď Intel chystá novinky, ale tomu se budeme věnovat zvlášť). APX je v podstatě v určitém smyslu překopáním fungování všech instrukcí, ale tak, aby to fungovalo současně se starými aplikacemi napsanými pro x86 a x86–64 coby nadstavba. Režim APX je aktivován umístěním prefixu REX2 (ten je nově zavedený pro tento účel) před instrukce, které mají být zpracovány v režimu APX.
Programy běžící s rozšířením APX dostanou k dispozici dvojnásobek obecných pracovních registrů (GPR), tedy 32 proti jen 16, které jsou dostupné v 64bitovém režimu architektury x86. Jde o Extended GPRs označené R16 až R31.
Počet 16 byl menší proti třeba ARMu nebo Power (ale s APX se jim už x86 vyrovná), ale už to bylo rozšíření proti původním pouhým osmi obecným registrům v 32bitovém režimu. Dostupnost více pracovních registrů omezí nutnost načítat a zpětně ukládat data z registrů do paměti tehdy, když registry nestačí. Zvýšením počtu registrů by tedy měl být zlepšen výkon procesoru na 1 MHz frekvence. Podle Intelu je při zkompilování programu v režimu APX typicky eliminováno 10 % operací load (načítání z paměti) a 20 % operací store (ukládání do paměti).
APX: 3-operand formát
Druhá změna v APX je, že všechny běžné celočíselné instrukce se mohou chovat jako tříoperandové. Původní instrukční sada x86 pracovala tak, že operace měly jen dva operandy, tedy dva registry, které instrukce mohla specifikovat jako vstupy. Nebylo možné specifikovat výsledek do třetího registru (operandu), takže vždy přepisuje jeden ze vstupů. Toto bylo původně asi motivováno zmenšením binárek (což je důležité i proto, aby se vešly do instrukční cache), ale zase nutí programátora či kompilátor, aby do programu vkládal instrukce kopírování hodnot mezi registry (instrukce MOV), pokud přepisovanou vstupní hodnotu potřeboval použít znovu ještě někde jinde.
V režimu APX se tříoperandovými instrukcemi tedy z kódu zmizí ona nadbytečná kopírování mezi registry. Podle Intelu by to minimálně v některých případech, které udává jako příklad, mělo vykompenzovat nárůst kódu kvůli prefixům navíc. Ty sice zvětšují průměrnou délku instrukcí, ale zase je ve výsledné binárce asi o 10 % instrukcí méně. Tento tříoperandový režim se aktivuje pomocí prefixu EVEX (který byl zaveden už s instrukcemi AVX-512).
Více registrů a tříoperandový formát mají sice popisované dopady na efektivitu, ale je třeba upozornit, že výkonnostní zisky nemusí vždy být velké. Procesory se totiž naučily s těmito omezeními pracovat a obcházet je. Problém dvooperandových instrukcí obchází technika MOV Elimination, která dovoluje tyto operace přeskakovat (přesněji řečeno, jsou provedeny jednoduše na úrovni fyzického souboru registrů ve fázi přejmenování registrů). Takto lze provést několik MOVů za cyklus bez toho, aby se zaměstnaly ALU procesoru. Tyto operace proto pro programátora často mohou být „zadarmo“, pokud tedy nezahltí kapacitu procesoru v předchozích fázích (fetch, decode…). MOV Elimination a tříoperandové operace jsou tak trochu konkurenční zlepšováky, oba těží výkon z jednoho zdroje.
Nadbytečný pohyb dat mezi procesorem a RAM (respektive nejdřív pamětmi cache) nebo aspoň jeho dopad na výkon kvůli omezenému počtu registrů zase omezují techniky jako load-to-store a store-to-load forwarding a přejmenování registrů, kdy CPU interně operuje s mnohem větším počtem použitelných registrů, než je definováno instrukční sadou. Tyto optimalizace působí v procesoru automaticky, a zase tedy už dodávají část onoho nárůstu výkonu, který by APX samo o sobě realizovalo.
Přínos navíc tedy u nového režimu často nemusí být zas tak velký, i když asi pořád nějaký bude (soudě podle toho, že se s tímto rozšířením Intel obtěžuje). Na druhou stranu APX ale reálně dohání některé staré deficity instrukční sady x86, které byly (i přes právě zmíněné) asi oprávněně považované za slabiny, což je určitě pozitivní. A navíc je to díky (pravda komplikované) realizaci přes prefixy bez toho, aby se musela přerušit kompatibilita a začínat od začátku s novou instrukční sadou.
Historické procesory x86 Intel a AMD
Load-store pár a podmíněné instrukce
Vedle toho APX přidává ještě další novinky. Inspirací z instrukční sady ARM je zřejmě přidání instrukcí PUSH2/POP2. Ty ukládají do paměti nebo načítají z paměti současně dva registry (hodnoty v paměti musí, zdá se, následovat po sobě) najednou v jedné instrukci. Jde o jeden z nápadů architektury ARMv8, které sice moc neodpovídá ortodoxní koncepci RISC, ale tyto operace se ukázaly hodně užitečné, protože zvládnou stejné množství práce s použitím méně instrukcí. Nyní tedy něco podobného bude možné používat i na procesorech x86.
APX také přidává podmíněné verze některých instrukcí. Už od Pentia Pro jsou takovými instrukcemi CMOV/SET, nyní se k nim přidají podmíněné operace load, store a compare/test. Vedle toho lze také vypnout zapisování flag bitů některými běžnými instrukcemi. Tyto volby budou realizovány opět pomocí prefixu přidaného před danou instrukci (tedy třeba load, compare), v tomto případě to bude zase prefix EVEX.
Intel si v prezentaci APX neodpustil jedno rýpnutí do kritiků instrukční sady x86. Té se vyčítá, že komplikuje například paralelní dekódování instrukcí tím, že nemá proti architekturám vzniklým z koncepce RISC konstantní délku instrukcí (typicky 32 bitů), ale proměnlivou, což je dědictví z éry klasických CISC procesorů ze 70. a 80. let. Nicméně právě tento rys umožňuje přidávat instrukcím různé prefixy, jako to dělá APX, a měnit tak jejich fungování, což by u RISC (či lépe řečeno architektury s 32bitovými instrukcemi) spíše vyžadovalo specifikování nových instrukcí. Je třeba říci, že v instrukční sadě x86 je těch prefixů už opravdu košatě a přinášejí svou vlastní komplexitu, takže je otázka, do jaké míry se tím dá chlubit.
Kompatibilita
Výhodou tohoto způsobu ale je, že by mělo být možné na procesoru podporujícím APX míchat po libosti kód používající jen tradiční formu instrukcí s tímto novým režimem. Programátor může APX využít čistě skrze automatické překompilování existujícího kódu, ale v řadě algoritmů asi bude možné získat další zrychlení přepsáním (ručním optimalizováním) kódu přímo na míru novým poměrům.
Pro APX by například mohly být zkompilované matematické knihovny nebo backend FFmpeg a podobné výpočetně náročné komponenty, které by ale mohly normálně interagovat se softwarem zkompilovaným postaru – nebo i se starým softwarem, který o existenci APX nic netuší. Mělo by asi být možné mít v programu namixovaný kód pracující bez prefixů v tradičním režimu s instrukcemi provedenými v režimu APX.
Ale aby takový kód běžel i na starších procesorech, bude muset používat detekci CPUID a rozšíření procesoru a binárka bude muset mít alternativní „codepath“ pro CPU bez APX.
Procesor Intel Meteor Lake pro notebooky
Kdy?
Zatím není úplně jasné, v jakých procesorech se APX poprvé objeví. Intel zatím neuvádí, ve které budoucí generaci procesorů budou poprvé implementovány, jako první by to mohla asi být generace Granite Rapids v serverových Xeonech a možná architektury Meteor Lake a/nebo Arrow Lake v klientských procesorech Core. Ale také to může být až v architekturách pozdějších. Intel toto asi odhalí, až když začne dané procesory podrobněji prezentovat. Něco bychom se možná mohli dozvědět během akce Intel InnovatiON v září (19. až 20. 9.).
Specifikace instrukcí si ale už můžete nastudovat v tomto dokumentu.
Jiná otázka je, kdy a zda podporu pro toto rozšíření přidají také konkurenční procesory x86, tedy zejména AMD, ale také čínský Zhaoxin. Protože specifikaci vymyslel Intel a již před jejím zveřejněním asi pracoval na implementaci, bude logicky mít náskok. Implementace v procesorech AMD se proto asi může dostavit dost opožděně.
Zdroj: Intel
