Odpověď na názor

To nevím, zatím jediná implementace (Fujitsu) používá také 512bitový hardware AFAIK/IIRC, takže je na úrovni AVX-512.

Ta abstrakce šířky vektoru sice umožňuje psát jeden kód pro různé hardwarové šířky,kdežto u SSE(x), AVX(2) a AVX-512 máte šířku registru danou, ale budou tam IMHO i nevýhody, kdy tohle může znemožnit tak dobrou optimalizaci kódu. Mám z otho pocit, že SVE je dělané hlavně pro autovektorizační kompilátory, kdežto ASM programátoři možná takovou radost mít nebudou.

Ono tahle vlastnost je v omezené míře přítomná i u x86. Ale tam je vždy daná velikost registrů, s kteýrmi pracujete, a podle toho programátor ví, kolik dat (kolik hodnota najednou) musí najednou zpracovávat, aby se mu SIMD vyplatilo a vytěžil maximum. ALE CPU pak v určité míře může pracovat s menší šířkou, například Pentium III/K7-K8 měly 64bitové jednotky a 128bitové SSE dělaly nadvakrát, Zen nebo BD byly 128bitové a 256bitů AVX dělaly na dvakrát, Intel v části procesorů taky dělá AVX-512 na dvakrát. Myslím, že z pohledu programátora tohle může být lepší, ale i tady tahle forma, kdy na těch některých CPU určité instrukce trvají dvakrát déle, přináší problémy. Některý optimalizovaný kód je pak rychlejší na CPU A, ale na CPU B je pomalejší, než kdyby program zvolil místo AVX2 třeba cestu s instrukcemi SSE2-4.

P.S. Zatím není moc jasné, jestli vůbec někdo počítá s nasazením SVE do těchhle spotřebitelských ARMů, mohlo by to zůstat jenom v HPC... Apple si už začal přidávat vlastní instrukce, takže by mě třeba nepřekvapilo přidání vlastní proprietární verze Neonu rozšířené na 256 bitů (jako má AVX1/2), místo aby přijali SVE.