Velké rozšíření jádra je potvrzeno, Zen 5 má paradoxně subset AVX-512, který Intel nepodporuje
Letos (snad v třetím kvartále) vyjdou procesory AMD s novou architekturou Zen 5. Bude to opět velká změna, zatímco předchozí Zen 4 byl v podstatě evoluce Zenu 3, a podle různých nepřímých náznaků, mezi nimiž jsou i výroky architekta Mike Clarka, by to prý mohla být vůbec nejzajímavější architektura AMD od prvního Zenu. Je zajímavé, že až dosud o ní byly informace z jediného youtuberského zdroje. Právě ale byly oficiálně potvrzeny přímo z AMD.
Všechny konkrétní informace o povaze jader Zen 5 (snad vedle toho, že desktopová CPU budou používat 4nm čiplety) pocházejí z tohoto úniku youtubera Moore’s Law Is Dead. Ten odhalil jednak schéma jádra, ale jak si jistě pamatujete, také nástřel nárůstu výkonu na 1 MHz frekvence. Ten se podle těchto slajdů má zlepšit o 10–15+ % (ono plus asi má říkat, že 10–15 % je konzervativní spodní mez).
Zatímco na výkon ještě budeme dál napnutí, AMD nyní poslalo patch do kompilátoru GCC, používaného pro překlad zejména open source softwaru ze zdrojových kódů, který do něj přidává podporu optimalizace pro procesory Zen 5. Patch je pro nás zajímavý, protože popisuje řadu aspektů jádra a sedí s tím, co před časem ukazovaly slajdy publikované Moore’s Law is Dead. To znamená, že nejspíš doložil jejich pravost, a můžeme se o ně tedy s poměrně slušnou mírou jistoty teď opírat.
Tip: Uniklé dokumenty AMD ukazují IPC Zenu 5 a 6 i detaily architektury
Rozšířené jádro: víc ALU a AGU
Patche pro GCC potvrzují rozšíření jádra Zen 5. Od první až po čtvrtou generaci tyto architektury zachovávaly hodně podobnou základní strukturu se čtyřmi aritmeticko-logickými jednotkami (ALU), které provádějí většinu nejtypičtějších instrukcí, byť u Zenu 3–4 jsou tři jednotky AGU (u Zenu 1–2 pouze dvě), které provádějí operace zápisů do paměti a čtení z ní. Toto je v kontrastu s vyšším počtem jednotek u jader Intelu, nemluvě o jádrech ARM, kde Cortex-X4 například ALU už obsahuje osm.
Bylo zajímavé, že AMD dokázalo z tohoto konkrétního počtu vytěžit relativně vyšší výkon než konkurenti, Zen 5 ale konečně v tomto parametru povyšuje. Patch potvrzuje, že jádro má šest ALU a čtyři AGU. To by mohlo provázet značné zvýšení IPC, i když z počátku nemusí být využití těchto jednotek navíc tak vysoké a další pokroky v IPC mohou být těžené až postupně v dalších generacích, podobně jako Zen 2, 3 a 4 dokázaly postupně dostat víc a víc výkonu ze čtyř ALU již přítomných v Zenu 1.
Zatím není úplně jasné, zda mají load/store pipeline (jednotky AGU) zvětšenou šířku z 256 bitů na 512 bitů, aby dokázaly v jednom cyklu číst a zapisovat 512bitový vektor pro instrukce AVX-512.
Naopak je jedna oblast, kde rozšíření není. Počet instrukčních dekodérů zůstává čtyři. Procesory x86 včetně architektur Zen ale mají jako alternativní řešení tzv. uOP cache, která ukládá již dekódované instrukce. Procesor by měl většinu času brát instrukce z uOP cache, která dokáže dodat výrazně více instrukcí za cyklus než čtyři dekodéry a současně je energeticky efektivnější. Tudíž počet dekodérů není tak důležitý jako u ARM procesorů bez uOP cache.
Tip: ARM uvádí rekordně výkonné jádro Cortex-X4 s osmi ALU
Nativní 512bitové AVX-512
Jednotka FPU (která ale zejména zpracovává i SIMD instrukce), zdá se, nemá přidané pipeline navíc proti Zenu 3 a 4, v FPU zřejmě opět bude čtveřice pipeline pro různé operace. GCC ale potvrzuje, že Zen 5 má poprvé fyzicky 512bitové SIMD jednotky. Podporuje tak zpracování většiny instrukcí AVX-512 v jediném cyklu, zatímco Zen 4 má jednotky 256bitové jako jádra Zen 2 a Zen 3 (která uměla jen 256bitové AVX2).
Předchozí jádro proto 512bitové instrukce AVX-512 provádělo ve dvou průchodech, které vypočítávaly vždy polovinu šířky vektoru. Tomuto rozšíření SIMD v Zenu 5, zdá se, odpovídá přidání druhého portu pro operace Foating-point store. FP store jednotky jsou ale patrně stále 256bitové, takže 512bitové operace provádí sdružením obou jednotek.
Samo rozšíření šířky SIMD jednotek na 512 bitů znamená, že se teoretický výpočetní výkon udávaný ve FLOPS (ale totéž platí pro operace pracující s celočíselnými datovými typy) zdvojnásobí. Tímto by Zen 5 měl dohnat hrubý výkon jader Intelu ve všech parametrech, takže použití AVX-512 by například v serverech nyní mělo přinést výhodu AMD, zatímco doteď dávalo Intelu šanci dohnat vyšší celkový výkon procesorů Epyc (Intel by mohl mít ještě výhodu v odlišných maticových instrukcích AMX).
Patche pro GCC ale ukazují, že došlo k dalším zlepšením. V jednotkách SIMD nyní mají schopnost zpracovat operace typu shuffle (permutace) tři pipeline místo dvou, takže lze provést místo dvou tři tyto operace za cyklus. Došlo, zdá se, k redistribuci některých operací mezi porty v FPU. Floating-point sčítání má latenci sníženou ze tří na dva cykly, což by mělo přímo zlepšovat výkon, protože na sebe navazující výpočty mohou být zpracovány rychleji.
Nějaká zlepšení tohoto druhu má i celočíselná část. Vypadá to, že dvě nově přidané ALU umí víc než jen nejjednodušší operace, nebo AMD posílilo již existující ALU. Zatímco dosavadní jádra uměla zpracovat CMOV a SETCC jen na dvou ze tří ALU, Zen 5 podle patche do GCC tyto instrukce dokáže zpracovat ve čtyřech ze svých šesti ALU, tedy až čtyři za cyklus.
Dále se v patchi nachází informace, že by mělo být zrychleno dělení a výpočty druhé odmocniny, tyto instrukce mají sníženou latenci o jeden nebo více cyklů pro většinu datových typů.
Zen 5 bude umět některé instrukce AVX-512, které Intel ztratil (nebo zatratil?)
Z patche lze také vyčíst, že jádro Zen 5 bude navíc umět některé instrukce AVX-512, které Zen 4 ještě nepodporuje. Tato skupina instrukcí má totiž poměrně rozvětvenou (a kritizovanou) množinu subsetů. Zen 4 podporuje značnou část, ale nikoliv instrukce MOVDIRI, MOVDIR64B, PREFETCHI a AVXVNNI – ta bude užitečná pro AI, ale jde o 256bitovou verzi instrukce VNNI, jež byla přidána pro E-Core, zatímco Zen 4 ji umí v původní 512bitové verzi. AVXVNNI bude užitečné hlavně pro kompatibilitu s big.LITTLE procesory Intel. Tyto instrukce Zen 5 přidává.
Kromě nich také Zen 5 podporuje rozšíření s dlouhatánským názvem AVX512VP2INTERSECT (AVX-512 Vector Pair Intersection to a Pair of Mask Registers), které je zajímavě obskurní. Tyto instrukce u Intelu přidaly procesory Tiger Lake (architektura Willow Cove), ale pak si to zřejmě Intel rozmyslel, nebo nalezl v implementaci nějaké problémy, protože následné architektury, včetně aktuálních serverových procesorů Intel Sapphire Rapids, už zase AVX512VP2INTERSECT nepodporují.
Je možné, že se AVX512VP2INTERSECT ještě u Intelu vrátí. Vše po Tiger Lake má Intel stále založené na jedné architektuře Golden Cove, takže je možné, že AVX512VP2INTERSECT je rozbité jen v ní, respektive v její serverové verzi. Je zajímavé, že klientská CPU Alder Lake a Raptor Lake snad tuto instrukci podporují, dokud jim tedy Intel AVX-512 na sílu nevypnul. Ovšem zase nedávno prezentované plány na reorganizaci 512bitových instrukcí pod pláštík AVX10 s tímto rozšířením zatím nepočítají, takže je možné, že už se s implementací znovu nepočítá.
Tip: Místo AVX-512 přichází AVX10. Už i pro big.LITTLE procesory
Možná tak vznikne legrační situace, kdy AMD opět jako v případě instrukcí FMA4 podporuje něco, co Intel nemá. Otázka je, zda to Zenu 5 prospěje, nebo to bude spíš nevýhoda. Tato instrukce totiž bude spotřebovávat tranzistory, které Intel bude moci ušetřit, ale software ji raději kvůli nepodpoře na Intelu možná nebude chtít používat. Toto je nevýhoda, se kterou se menší konkurenti často musí potýkat.
Není to ovšem tak, že by Zen 5 celkově uměl více instrukcí AVX-512 než jádra Intelu. Měl by mít větší pokrytí než desktopové a notebookové procesory (Ice Lake, Rocket Lake, Tiger Lake), ale serverové procesory Sapphire Rapids a nové Emerald Rapids mají několik dalších instrukcí, které Zen 5 ještě neumí.
Zdroje: GCC / AMD, AnandTech Forum (1, 2)
Jan Olšan, redaktor Cnews.cz
⠀
- Contents
- Velké rozšíření jádra je potvrzeno, Zen 5 má paradoxně subset AVX-512, který Intel nepodporuje
Pridavani dalsich a dlasich instrukci znamena zeslozitivani navrhu procesoru, a nutnost pouzit vice tranzistoru.
Tim vznika historicky batoh, ktery si kazdy novejsii procesor nese s sebou. Je zrejme ze tato technika vede pri dlouhem vyvoji do stavu, kdy je monstrozne obri CPU vetsinu casu vetsinu kremiku nepouziva. Jednoduse receno, prjdete do mekace, objednate si normalizovanz hambac – snite jen tu sekanou. kilo zeleniny, dresingu, housky a kdovijakeko blebajzu kolem proste vyhodite.
Vysvetli mi nekdo jak je mozne, ze graficke karty jdou na zvysovani vykonu opacne ?
Jeednoducha „jadra“ skladana po tisicich tvori vykon.
No ale grafiky jsou používané na úplně jiné úlohy. Paralelizovatelné operace, „throughput“. O CPU se někde říká, že je to „latency engine“, ale v podstatě se tím taky myslí něco podobného, jako optimalizace na jedno vlákno. Když má program nějakou smyčku, ve které funguje a v každé iteraci nějak reaguje na podmínky/vstupy, které třeba i závisí na předchozím kroku, tak to nejde udělat tak, že 1000 kroků té smyčky najednou pustíte na GPU-like výpočetních vláknech v jednom cyklu. Pro GPU jsou úlohy typu „tady je tisíc pixelů, zvýšit jas u všech o 1.5x“. Jednotlivé pixely na sobe nezávisí, takže krásně paralelizovatelné.
GPU taky nedrží instrukční sadu, ale pořád ji mění, a neběží na nich zkompilovaná aplikace – jaký kolik spuštěný software je nejdřív zkompilovaný ovladačem.
To s množstvím jednoduchých jader („A“) je teda asi trochu ortogonální k tomu, že se kód překompilovává a stabilní API/ABI pro aplikace je až na softwarové vrstvě („B“), oproti tomu, jak na CPU běží všechno „na železe“ se zaručenou kompatibilitou.
Ten první rys „A“ se u CPU asi nedá udělat v té paralelní formě. Druhy úloh, pro které CPU je dělané a pro které je třeba, nejdou tak krásně paralelizovatelné, jsou plné datových dependencí a algoritmů, které jsou +-jednovláknové.
Pokud teda pomineme paralelizaci a budeme se bavit jenom o tom jednoduchém jádru, tak to je RISC koncepce, no. Považovala se za cestu v před v 80. a 90. letech, ale ukázalo se, že jedna věc je teorie a druhá praxe. Úplně čistý RISC byl třeba i bez instrukcí pro dělení nebo dokonce i pro násobení (dělal to kompilátor), neměl mikrokód, takže komplexitu, kterou skrývá dnešní CPU v mikokódu, měl exponovanou a taky ji musel řešit kompilátor/programátor. Jeden z důsledků bylo, že programy byl větší, zabíraly víc míst v RAM a instrukční L1 cache a tohle snižovalo výkon.
Pokud přijmeme, že v praxi se testuje, co funguje a praxe tedy ukazuje, co se ukázalo být životaschopné, tak praxe ukázala, že tenhle puristický RISC přístup nezafungoval. Proti předchozím CISC procesorům měl výhody, ale celkově nebyl ideálně, ukázalo se, že ty komplexnější instrukce a mikrokód mají smysl. A tak se do procesorů se vrátily, i když teď už to byly CPU založené na elementech RISC konceptů. Prostě se ukazuje, že má smysl, aby procesor měl různé speciálnější instrukce, pokud mu to dovolí „udělat jednou instrukcí víc práce“, protože to zvedá IPC a výkon.
ARM se někdy považuje za RISC, ale ARMv8 právě je instrukční sada, která vůbec nejde slepě podle konceptu „čím jednodušší, tím lepší“, ale má úplně pragmaticky spousty komplexnějších instrukcí, protože někdo nasimuloval, že to bude užitečné. Například instrukce load pair of registers. Naproti tomu RISC-V je instrukční sada, která je o dost víc podle toho puristického konceptu. Asi to dovoluje mít menší implementaci jádra, ale výkon RISC-V je horší a obecně se ta ISA považuje za horší než ARMv8.
Jinak na základě toho argumentu „proč nejsou CPU raději jednodušší“, by se dalo eliminovat použití out-of-order execution, protože to je lepší jako u GPU udělat v softwaru. A vznikne vám Itanium, které se ukázalo být slepou uličkou překonanou konvenčníma CPU.
Kdybyste chtěl ten druhý rys GPU aplikovat na CPU („B“, tedy že CPU nemá fixní instrukční sadu, ale je nad ním SW vrstva, která program nějak přechroustá a zadá flexibilnímu jednoduchému hardwarovému backendu), tak to teoreticky jde.
Takhle to dělala Transmeta a Nvidia u jejich jader Project Denver a Carmel. Nicméně ta jádra nebyla schopná výkonnostně konkurovat, což naznačuje, že model, kdy je hardware komplexnější a nemusí nad ním být ta další SW vrstva funguje přece jenom lépe (z hlediska výkonu, ale třeba i energetické efektivity).
——————————————
Něco jednoduchého se k tomu asi říct nedá, no. Z části to může dávat smysl, z části asi ale ne.
Důvod, proč se nakonec do CPU přidá tolik různých speciálních instrukcí, je asi jako u toho ARMv8 – protože to pak v praxi bude mít lepší výkon než bez nich. Taky by se dalo říct, že CPU nepotřebuje 512bitové SIMD, protože ty tranzistory navíc se dají investovat do zrychlení 256bitového, které pak bude dělat stejnou práci. Ale nejspíš v praxi vychází, že pro nezanedbatelnou část úloh bude to 512bitové SIMD efektivnější a nějak se to celkově vyplatí.
Pro AI aplikace se taky vyplácí přidat úplně nové jednotky, které v podstatě jsou něco jako extrémně široké SIMD s velmi malou flexibilitou (takže se dají použít jen na AI a ne na moc jiného). Přitom by se pro AI daly použít existující SIMD jednotky a nemusely by se investovat tranzistory navíc. Ale přesto se vyplatí tam ty speciální jednotky přidat.
Ještě možná jednodušeji by se to dalo ilustrovat na tomhle.
V podstatě platí, že u jakéhokoli algoritmu nebo problému platí, že když ho napíšete v programovacím jazyku a zkompilujete a pustíte na CPU, tak to bude mnohem pomalejší a méně efektivní, než když se pro něj navrhne speciální hardware, který ho provede (tzv. ASIC).
Nevýhoda je, že ASIC pak neumí nic jiného. CPU je míň efektivní, ale provede úplně cokoliv.
Tyhle různé specializované instrukce jsou v podstatě o tom, že si do CPU integruju takové malé „ASIC“ akcelerátory pro úlohy, u kterých mi vyjde, že se mi vyplatí mít ten rychlejší specializovaný hardware.
GPU a různé ty specializované instrukce na CPU včetně SIMD jsou někde uprostřed na ose mezi tím obecným CPU a ASICem a jejich smysl je v tom, že dodávají různý kompromis mezi tím výkonem/efektivitiou a flexibilitou.
GPU je asi trochu blíž ASICu. Taky je sice programovatelné, ale lze s ním řešit menší skupinu problémů, než na CPU. SIMD instrukce na CPU jsou flexibilnější. Můžete je použít v rámci jakéhokoli programu běžícího na CPU a bez latence navíc. Jsou teda součástí „latency engine“, ale dokáží zpracovávat paralelizované problémy mhohem rychleji a efektivněji než to obyčejné jednoduché CPU. Proto se je vyplatí mít v CPU, i když jsou to tranzistory a obří komplexita navíc.
Občas si lidi myslí, že by se daly nahradit právě tím GPU. Jenže GPU právě nemá stabilní instrukční sadu, cokoli na něm chcete spustit, se musí prohnat ovladačem, a musí se s tím běžet na GPU po PCIe nebo nějaké jiné sběrnici. Takže když si v tom programu běžícím na CPU chcete vyřešit paralelní problém, tak si musíte zavolat na GPU jako na jinou pobočku firmy, říct co chcete, čekat na výsledek… Kdežto když máte SIMD, uděláte si to hned.
GPU má vyšší výkon, takže se vyplatí to na ně poslat když výpočet bude bežet třeba minutu a déle. Pokud ten výpočet bude trvat 10 milisekund, tak se vám to nevyplatí, je lepší udělat to na SIMD, která má menší výkon, ale taky menší režii okolo. (Čísla jsou jenom pro ilustraci).
To je cely clanek. Diky.
Svrbí vás vyrážka na pohlaví, pane žurnalisto?