Odpověď na názor

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.