Odpověď na názor

1) V praxi se to osvědčilo tak že SVE2 mají už dva roky všechny nové telefony a nyní i brutálně našláplý serverový V2.

Má dnes každej mobil SVE2? ANO .............­.......... AVX512 nemá každý CPU
Mají malé jádra SVE2 instrukce? ANO .................. střední e-jádra AVX512 neumí
Mají velké jádra SVE2 instrukce? ANO ................. AMD jo ale Intel jen někde
Má ARM nulovou frangmentaci? ANO .................. x86 má brutální fragmentaci

ARM v podstatě má nový standard 128-bit SVE2 a mají to všechna zařízení. Od little inOrder jader A520 až po serverovou V2. Co by za to ve světě x86 Intel dal, kdyby nemusel vypínat AVX512 na velkých jádrech.
.
.

2) Proč myslíš že V2 degradovala z 2x 256 SVE (V1) na 4x 128-bit (V2)?
Za tím stojí autovektorizace přes OoO. To tě nenapadlo?

OoO engine musí umět rozpoznávat datové závislosti, aby ty nezávislé mohl poslat na ALU paralelně, tomu snad rozumíš, protože to je základ funkce OoO na ALU. A proč by to samé nemohl udělat se 128-bit SIMD vektory? Stejně jak Apple tak ARM od X1 má 4x 128-bit, takže to stejně už dávno dělá se skalárníma FPU. Tohle OoO se SIMD umí určitě i mnohem starší jádra, nejspíš od A73 která měla 2x 128-bit.

Z toho plyne že V1 investovala tranzistory do širších 256-bit registrů, což přineslo jen komplikace, ale výkon to nezvýšilo. Jediný benefit je menší binárka a menší zátěž OoO enginu. A byla by fragmentace a nekompatibilita SW ala x86. Tedy pokud se nepoužije autovektorizační knihovny, ty to umí vykonat na všech šířkách SIMD.

Budoucí V3 tedy může mít 8x 128-bit SVE2 a výkon bude mít dvojnásobný aniž by musela mít 1024-bit SVE2. Nemusí nutit little jádra mít taky 1024-bit. Nebo si komplikovat vývoj V3/X5.

x86 zvyšuje délku vektorů aby Intel mohl podělat AMD a to se dalších 5 let nechytalo. Že to brzdilo vývoj celé platformy to už nikoho nezajímalo, protože tady kromě x86 nic nebylo. Ale dnes kvůli tomu vypadají jako šašci když jim ARM nastavil zrcadlo, že to lze dělat líp.

Fujitsu s 2x 512-bit SVE vydrtil Nvidia GPU Voltu, takže s výkonem problém nebude protože tam můžou vrznou třeba 6x 512-bit a budou mít hafo výkonu. Těch 2048-bit je vyloženě něco co se použije někdy v budoucnu za 20 let. ARM ISA to prostě umí už teď protože přemýšlí dopředu a pokryje tím úplně všechny myslitelné HW konfigurace. A vše bude kompatibilní. Tohle Intel nikdy nezavede protože by tím usnadnil AMD vývoj, ale kvůli tomu chcípnou společně. On to Keller viděl když se snažil protlačit K12 jako hlavní CPU. No a když se člověk podívá na Intelovskou AMX, tak to je mimochodem 16x větší obdoba AVX512, naprostá prasárna. To nikdy na E-jádrech neuvidíš, to ti garantuju. Takže specialitka pro HPC a už předem mrtvá SIMD. Zatímco ARM klidně bude násobit matice i na little jádru protože 128-bit SVE2 to umí.
.
.
.
3) VLIW

Jinak pročpak asi AVX512 dostal první Larrabee s InOrder Atom jádry? Že by protože nemá OoO a tedy autovektorizaci přes OoO nemůže provádět? Tedy argument s VLIW Itaniem je totálně mimo. Je to přesně naopak. Dlouhé vektory jako AVX512 jsou závislé na kompilátoru (a tedy hodí se pro hloupá InOrder nebo GPU VLIW jádra, protože tím kompilátorem nahrazuje logiku OoO) zatímco naopak moderní OoO jádra si v pohodě vystačí se 128-bit i za 10 let a přitom budou pořád brutálně zvyšovat výkon třeba s 16x 128-bit jednotkami. Ono přerovnat 16 simd instrukcí není problém když má dnešní CPU OoO okno 300 instrukcí, že jo. Jeden by řekl, že možná ani 32 nebo 64 nebude problém což už je docele sci-fi záležitost mít 64x 128-bit, to je ekvivalent 4x 2048-bit SVE2. Sežere to ovšem o 60 bajtů víc v cache, což myslím taky žádný CPU nepoloží.

Takže ani delší vektory než 128-bit pro výkonná OoO jádra nepotřebujeme. A zároven malé vektory jsou ideálka pro ty little jádra. Prostě Win-Win.