Názor k článku Nástřel výkonu next-gen procesorů Intel Arrow Lake: Jen 3–21 % navíc proti Raptor Lake? od Jim_Keller - Vždyť tomu vůbec Olšan nerozumí proboha, žádná virtuální...

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).