Procesory AMD s architekturou Zen 4 už budou podporovat AVX-512 (a další rozšíření)

14

Procesory AMD také konečně dostanou podporu pro 512bitové instrukce AVX-512: spolu s BFloat16 přijdou s architekturou Zen 4. Máme také velikosti čipů, z kterých vyplývá, že IO čiplet bude asi na modernějším výrobním procesu.

Včera jsme tu měli zprávu o prosáknutí některých informací o serverových procesorech AMD s architekturou Zen 4, které také budou už vyráběné na 5nm procesu. Dostanou nový socket, 12kanálové paměti DDR5 a 96 jader, které budou v 12 čipletech. Krátce poté přicházejí další dokreslující informace k Zenu 4. Například příjemná věc, že AMD údajně konečně přidá podporu 512bitových SIMD instrukcí AVX-512.

Tato informace se objevila na fóru Chiphell a je doložena výřezem z dokumentu, který má být slajdem od AMD – samozřejmě nemůžeme vědět jistě, že je to není „fake“. Informace o tom, že Zen 4 podporuje AVX-512, ale je prý pravdivá podle předchozího leakera ExecutableFix, což by mohlo podporovat i pravost ostatních informací na tomto útržku.

Co tam tedy je dále? Potvrzeno je „víc než 64“ jader, ale ne přímo číslo 96. Současně je zde jasně uvedeno, že jádro Zen 4 má pořád jenom dvě vlákna na jedno jádra (tedy SMT je jenom dvoucestné jako dosud). Také je řečeno, že procesory Epyc této čtvrté generace budou pořád podporovat maximálně jen dvousocketové (2S) servery a desky.

AMD na údajném slajdu uvádí, že jsou podporovány instrukce „AVX3-512“ (AVX3 bylo dříve se objevující předběžné označení pro AVX-512). Není řečeno, jaké subsety AVX-512 bude Zen 4 podporovat, což je dost důležité, ale aspoň se základy by tedy asi měl být kompatibilní. Zen 4 by tedy mohl dorovnat tuto dílčí výhodu, kterou má Intel od vydání architektury Skylake-X/Skylake-SP. Ovšem také nemusel. Bude záviset na tom, s jakým výkonem bude výpočet probíhat. Pokud by například byly pořád použité 256bitové jednotky SIMD a 512bitové operace probíhaly ve dvou průchodech, nemusí se výkon proti AVX/AVX2 téměř vůbec zlepšit a podpora by pak měla hlavně cenu kompatibility.

Leak k architektuře Zen 4 v procesorech Epyc 7004 Zdroj Chiphell
Leak k architektuře Zen 4 v procesorech Epyc 7004 (Zdroj: Chiphell)

Kromě AVX-512 bude jádro také podporovat výpočty s hodnotami BFloat16, což je 16bitový formát čísel uzpůsobený pro trénování neuronových sítí. Obsažené ale mají být i další instrukční rozšíření. Není řečeno jaká, takže nemáme žádnou představu, zda se pod tímto skrývají jen drobnosti nebo něco významnějšího.

Zen 4 má podle těchto informací mít vylepšený výkon a energetickou efektivitu – a to jak samotným architektonickým návrhem, tak 5nm výrobním procesem. Ale nic jiného se asi ani nečekalo. Také je uvedeno, že CPU bude podporovat 52bitové fyzické adresování RAM zatímco virtuální adresy budou podporované 57bitové.

Velikosti čipletů: lepší proces pro IO křemík?

Kromě informací o nových instrukcí je tu také ještě něco k fyzické podobě procesoru. Včera jsme ukazovali „koncept“ toho, jak by měl procesor podle leakera vypadat. ExecutableFix pak potvrdil že ač jde o nepravou podobu (ručně „naphotoshopovanou“ z obrázku procesoru Epyc druhé generace), polohy a velikosti čipů na ní sedí s tím, jak vypadá reálné schéma.

Takto nějak by měl procesor Genoa vypadat jde jen o montáž ne reálnou podobu
Takto nějak by měl procesor Genoa vypadat. Jde jen o montáž ne reálnou podobu (Zdroj: ExecutableFix)

Současně s tím také zveřejnil reálné velikosti čipletů, z kterých vyplývá, že IO čiplet zřejmě dostane novější výrobní technologii, což by mohlo zlepšit efektivitu. U 7nm procesorů Epyc (Rome i Milan) má IO čiplet nějakých 416 mm²; u Epycu Genoa bude menší s 396,64 mm². Není to o moc – podle obrázku to vypadalo na větší rozdíl – ale procesor bude mít místo PCIe 4.0 už konektivitu PCIe 5.0, bude podporovat komunikaci s o 50 % vyšším počtem CPU čipletů a také o 50 % víc kanálů paměťového řadiče, navíc s podporou DDR5. Pravděpodobně je proto použitý lepší výrobní proces s vyšší hustotou a snad také lepší energetickou efektivitou.

U 5nm CPU čipletů lepší proces je už jasný, ale jak jsme zmínili minule, kvůli udržení počtu jader na osmi jsme měli trošku strach o jejich velikost. Při malé ploše by se totiž procesory s jedním nebo dvěma čiplety (tedy Ryzeny pro desktop) špatně chladily. Velikost těchto 5nm křemíků je nakonec skutečně menší, mají jen 72,225 mm². Není to ale už o moc méně, než měly 7nm čiplety s jádry Zen 2, pro ty se uvádí 74 mm². Snad se tedy teploty těchto procesorů nezhorší o moc.

Jinak je pravděpodobné, že stejný výrobní proces, jako bude použitý u IO čipletu Epycu Genoa, bude také využitý v IO čipletu procesorů Raphael pro desktopový socket AM5. A to kvůli ušetření nákladů na vývoj dvou těchto čipů.

Roadmapa serverových procesorů AMD s jádry Zen až Zen 4 (AMD Financial Analyst Day 2020) Zdroj: AMD

Galerie: Uniklé či zveřejněné dokumenty k architektuře AMD Zen 4

Zdroje: Chiphell, ExecutableFix (1, 2), VideoCardz

Procesory AMD s architekturou Zen 4 už budou podporovat AVX-512 (a další rozšíření)
Ohodnoťte tento článek!
5 (100%) 10 hlasů

14 KOMENTÁŘE

        • Pro Linux samotný a jeho vývoj ty SIMD rozšíření nejsou moc podstatné – proto taky asi je L.T. tak skeptický/kritický (podle mě přehnaně) k jejich významu. Jejich užitečnost je až v aplikační vrstvě…

          • No, tak predne kernel se pri prepinani procesu musi postarat o zachovani tech aplikacnich registru, ktere zachovat ma, cili je to trosku naloz. A za dalsi, v kernelu se SIMD pouzivaji kuprikladu v kryptografickych aplikacich. Takze pouziti maji i v kernelu.

            • Jo ale je to relativně minoritní věc, myslím že kernel se obecně snaží být spíš obecnější a Linus sám je zřejmě toho názoru, že nejspíš stačí 128bitový SIMD a místo větších šířek by se mělo v CPU investovat do výkonu jinde (takže 256bit možná ještě OK ale 512bit zbytečnost).

              Jenže stačí, když někdo zase dělá multimediální kód nebo podobné výpočetně intenzivní operace (ať už nad obrazovýma datama nebo v HPC) a nejednou to mají lidi přesně obráceně a někdy je vyloženě zajímá SIMD a nic jiného.

            • Pane Olsane, Linux se predevsim snazi z zeleza dostat maximum i kdyz to nekdy muze jit proti jinym projektovym zamerum (treba bezpecnosti). Linux je proste zavodni formule. Cili jestli je nejake zelezo k dispozici a ma funkci v dane aplikaci, pouzije se. Jeden priklad za vsechny: MD (software raid) v linuxu pocita rychlost pro ruzne rozsireni ISA pri kazdem bootu. Na W-22xx zkriplene pouzitim jen 2 RDIMMu (cili nizsi propustnost pameti) to muze vypada takto:

              [ 1.972473] kernel: raid6: avx512x4 gen() 52464 MB/s
              [ 2.020475] kernel: raid6: avx512x4 xor() 20061 MB/s
              [ 2.068174] kernel: raid6: avx512x2 gen() 43025 MB/s
              [ 2.116117] kernel: raid6: avx512x2 xor() 24714 MB/s
              [ 2.164063] kernel: raid6: avx512x1 gen() 35451 MB/s
              [ 2.212006] kernel: raid6: avx512x1 xor() 19833 MB/s
              [ 2.259950] kernel: raid6: avx2x4 gen() 32650 MB/s
              [ 2.307895] kernel: raid6: avx2x4 xor() 21471 MB/s
              [ 2.355838] kernel: raid6: avx2x2 gen() 32239 MB/s
              [ 2.403782] kernel: raid6: avx2x2 xor() 20119 MB/s
              [ 2.451727] kernel: raid6: avx2x1 gen() 25682 MB/s
              [ 2.499670] kernel: raid6: avx2x1 xor() 18275 MB/s
              [ 2.547616] kernel: raid6: sse2x4 gen() 12241 MB/s
              [ 2.595559] kernel: raid6: sse2x4 xor() 8075 MB/s
              [ 2.643503] kernel: raid6: sse2x2 gen() 12124 MB/s
              [ 2.691449] kernel: raid6: sse2x2 xor() 7602 MB/s
              [ 2.739395] kernel: raid6: sse2x1 gen() 10874 MB/s
              [ 2.787335] kernel: raid6: sse2x1 xor() 6162 MB/s
              [ 2.787335] kernel: raid6: using algorithm avx512x4 gen() 52464 MB/s
              [ 2.787336] kernel: raid6: …. xor() 20061 MB/s, rmw enabled
              [ 2.787336] kernel: raid6: using avx512x2 recovery algorithm

              Takze vidite, ze pro RAID6/MD se pouzije prave AVX512, protoze to z benchmarku vyslo jako nejlepsi.

              Toto je asi tak nejzrejmejsi priklad, proto opomijim veci jako ZFS a nebo crypto.

            • O tom RAIDu zrovna vím, ale to jsou ty úzce zaměřené a dobře ohraničené věci. Co jsem tím chtěl říct je, že to není tak, že by vektorizace byla rozesetá v kernelu všude i na jen drobné optimalizace (ono by to vyžadovalo všude mít vektorizované a fallback cesty…). A vzhledem k portovatelnosti/udržovatelnosti je to tak asi určitě správně.

              Jinak ohledně toho, že Linus je „zaujatý“ (jak sám říká) proti SIMD a moc ho nemá rád: https://www.realworldtech.com/forum/?threadid=193189&curpostid=193203

              Holt jádro operačního systému má mnohem víc obecného kódu než těch úloh s charakterem DSP, kde je SIMD nedocenitelné, proto je Linus zaměřený na ty obecné ne-SIMD operace a považuje je za nejdůležitější (je to úplně pochopitelné).

          • (ne)rozšíření AVX má na svědomí hlavně Intel, který se touto sadou snažil dělit svou produktovou řadu, a tím ji taky efektivně pohřbil.

            Dnes už neobstojí hlášky typu „abyste mohli náš CAD provozovat, musí být váš PC vybaven matematickým koprocesorem“ jako tomu bylo v 80. a 90. letech.

            • Jojo, ono cela ta dlouha leta kdy nebyla AMD konkurence schopna, kdy ARM by jeste nikde (z pohledu vypocetni sily) a POWER/SPARC si hajili svoje domeny se proste nejak podepsat musela. Nicmene ignorujice moznou vyjimku v podobe Amber Lake, snad se i v Intelu blizka na lepsi casy — kdyz uz i notesy maji AVX512…