Jak to nemá revoluční 2048-bit SVE vektory, tak jako ARMy, tak to prostě nemůže mít výkon. AVX512 je prostě už 6 let zastaralá záležitost, to ví každé malé dítě.
K tomu, k čemu je SSE/AVX/Neon, ale některý lidi nedokážou zpracovat, že různé přístupy mohou být v praxi oba +-stejně použitelné a takhle nějak se to projevuje.
Jinak jsem k tomu něco psal i tady: https://www.cnews.cz/clanky/amd-oficialne-potvrdilo-big-little-procesory-a-apu-phoenix2-se-zenem-4c-meri-137-mm/nazory/278611/
(protože tyhle tapety jsou tu teď pořád).
Vždyť tomu vůbec Olšan nerozumí proboha, žádná virtuální 2048-bit šířka SVE není. Panebože a ještě ty svoje bludy tady prezentuje jako fakta, to je ostuda.
1) ARM CPU může mít fyzicky až 2048-bit šířku registru. Cokoliv v rozsahu 128-bit až 2048-bit s krokem po 128-bitech. Tedy celkem 16 šířek registru (kterých je celkem 32 jak se sluší pro RISC, třeba x86 má jen 16 AVX registrů). Ještě jednou specielně pro pana redaktora, ty šířky registrů nejsou virtuální, ale fyzicky a architektonicky přístupné programátorovi.
2) To čím se liší tyto flexibilní SVE vektory od těch dosavadních fixních (x86 SSE/AVX) je hlavně oddělení šířky vektoru od samotné instrukce. Zatímco fixní x86 AVX má v opcodu instrukce danou i šířku instrukce, tedy SSE je 128-bit, AVX2 je 256-bit etc. a přes to nejede vlak ikdyž se jedná o stejnou operaci třeba FMA.
3) Pro 16 různých šířek vektorů by u fixního přístupu musel ARM implementovat 16 různých verzí jedné a té samé instrukce, což by zapláclo 4 bity z opcodu úplně zbytečně. Inženýři vzali v úvahu fakt, že šířka vektorů (SIMD registrů) zůstává konstantní pro dané CPU a tedy se nepotřebuje měnit za běhu programu. Tak proč plýtvat kódováním pro šířku vektoru? Ono by se tam ty 4-bity ani do 32-bit RISC kódování toho ARMu nevešli, takže k tomu geniálnímu nápadu byli defacto donuceni.
4) SVE naproti tomu má v opcodu zakódované jen co má dělat, nikoliv kolikrát to má udělat (šířka vektoru). SW si přes instrukci zjistí jakou šířku dané CPU umožňuje a podle toho potom zvolí codepath (tzn. podobný přístup jako u fixních vektorů, tudíž je to kompatibilní s fixníma vektorama a umožňuje to bezproblémovou konverzi ručního ASM) nebo se využije nějaká forma autovektorizace, která umožňuje různá advanced kouzla typu SIZELESS typ v C++ (defacto stream dat se rekurzivně zpracovává na SIMD tak dlouho dokud nedojdou data).
5) Když pan redaktor mluví o virtuální šířce vektoru, tak tím že tomu nerozumí tak si plete 2048-bit fyzickou/ISA šířku registru s virtuálně neomezenou šířkou onoho Sizeless typu. Jakkoliv může 2048-bit šířka vypadat fantasticky a svádět nebohé redaktory hrající si na odborníky, aby si mysleli že to je něco virtuálního.
6) SVE řeší spoustu problémů, třeba například Intel pro Alder Lake backportoval některé instrukce z AVX512 (VNNI pro AI akceleraci) do 256-bit AVX2 pro e-jádra Gracemont a tedy vytvořil AVX3, které zase nepodporuje AMD a bůhví kdy bude. Arrow Lake má backportovat dalších několik AVX512 instrukcí, takže bude AVX4.Tento bordel a fragmentaci právě odstraňuje SVE, které má šířku vektoru nezávislou na instrukci. Jedna instrukce existuje automaticky pro všech 16 verzí od 128-bit až po 2048-bit vektory. Geniální.
SVE je defacto zjednodušení fixních vektorů tím, že z nich odebrali šířku. Zjednodušuje a zároveň otevírá úplně nový level možností zpracování vektorů. Od obrovských šířek a výkonů až po vychytávky typu autovektorizace. Já myslím že každý kdo má IQ > 80 chápe že tohle je jednoznačný krok správným směrem. Třeba RISC-V má ještě vychytanější formu SVE, ale vpodstatě je to SVE2.0.
BTW Koho by to zajímalo, tak RVV umí v rámci ISA měnit šířku vektorů vs. počet registrů (tudíž zachovává konstantní objem dat v architekturních registrech, a umí jej přerozděli dle potřeby SW). Umí třeba snížit počet registrů na polovinu a tím zdvojnásobit šířku vektoru (a naopak).
Inženýr-ezoterik za jehož hodinu práce platí zahraniční zákazník 400 EUR/hod a má na starosti zařízení asi za 500 milionů Kč.
Někdy si říkám jestli není lepší být pokrývačem dění, který si může dovolit nadělat jelita ze všech špičkových inženýrů a vědců co na tom SVE roky makali.
A k čemu to reálně je, když stejně není procesor, který by měl širší vektorovou jednotku než 512 bitů a i to je spíš vyjímka. Protože na 512 b jednotce to tedy znamená 4 průchody. Až bude skutečně existovat procesor, který to dokáže na jeden průchod jedinou jednotkou, uznám že to pracuje fakt rychle. Intel nejen že postupně skutečně fyzicky dělá širší jednotky, ale především přidává nové instrukce. S ohledem na to že jsou jen dva významní výrobci x86-64 CPU to není problém.
To co popisuješ dělá AMD Zen 4, kdy AVX512 vektory rozkládá vnitřně pro dvě 256-bit SIMD jednotky. To komplikuje HW samotného CPU, čemuž se ARM chtěl vyhnout.
Tak SVE nefunguje. SVE instrukce neobsahuje šířku vektoru, jen matematickou instrukci. To je na tom to geniální, je to zjednodušení, ale zároveň to umožňuje dělat nevídané kouzla s vektory. Takže kdyby Zen 4 uměl SVE vektory, tak by jeho SIMD podporovala 256-bit SVE a nemuseli by inženýři v AMD plýtvat tranzistory na rokládání AVX512 do 256-bit a pak zase skládat výsledek zpět do 512-bit.
Šířka vektoru SVE může mít 16 různých velikostí od 128-bit až po 2048-bit. Geniální na tom je to, že můžeš mít i ty nejnovější a nejpokročilejší vektorové (nebo instrukce pro maticové operace viz nové SME a SME2 od ARMu) i na tom nejmenším jádru se 128-bit SIMD. Což by se hodilo i Intelu pro ty jeho e-core Gracemont, které mají fyzicky v HW 128-bit SIMD, ale navenek se tváří že jsou 256-bit AVX2 (podobně jako Zen 1) a navíc aby Gracemont uměl i VNNI instrukce z AVX512, tak backportoval VNNI do 256-bit AVX (takže vytvořil AVX2.1, které zase neumí AMD). Tohle všechno by vyřešila 128-bit SVE pro Gracemont a velké Golden Cove jádro by dostalo 4x128-bit SVE. Přitom SW by na tom běžel taky jako na 256-bit SVE v Zen4, protože SW si to sám naporcuje dle šířky vektoru daného CPU.
SVE je revoluční v tom, že ti umožňuje dnes napsat SW, který bude fungovat na všech 16 šířkách vektorů, i těch 2048-bit někdy v budoucnosti a poběží na tom rychleji. Dopředná kompatibilita. Podle mne SVE časem okopírují všechny ISA a CPU. RISC-V už to udělal s RVV vektory.