Odpověď na názor

Vždyť o těch gather a scatter jsem psal. Gather a scatter jde udělat přes skalární multiplikátor úplně stejně dobře jako to násobení.

Klidně tak lze udělat 2 rozměrné pole (matice). Využívá to v podstatě stejný princip jako se v C/C++ přistupuje k array s n-dimenzemi s využitím aritmetiky s pointery. Někdy se mi zdá že neznáte ani základy programování C a neznáte rozdíl mezi předáváním proměnné poiterem, referencí a hodnotou. To je potom těžké diskutovat protože tyto úplné základy SW souvisí jak funguje strojový kod a sám CPU.

Pointa je přece ta, že s multiplikátorem nemusíš optimalizovat VŮBEC. Vektorové optimalizace jsou nutné právě protože máš pevně danou délku vektoru a řešíš jak je vektor dlouhý a jak jej rozsekat na menší. A taky jestli je tohle místo dostatečně horké aby se s optimalizací vůbec vyplatilo ztrácet čas a člověkohodiny.

S multiplikovaným skalárem krásně uděláš autovektorizaci pomocí smyčky FOR, stačí dát kompilátoru nějakou direktivu, že tento FOR je datově nezávislý a tedy paralelizovatelný a kompilátor tam vrazí multiplikační blok. Dokonce tohle může detekovat IDE nebo kompilátor sám a dělat to automaticky. Když OoO engine v CPU dokáže řešit datové závisloti za běhu programu na 6 GHz, nevím proč by to neměl umět kompilátor co na to má 1000x víc času.

V podstatě se řeší jen zda ten FOR jde paralelizovat, ale už neřešíš kolik ten vektor má prvků, protože nejsi ničím omezen (nemáš žádné 512 registry tak pro ně nemusíš nic optimalizovat). Všechny vektory delší než 2 prvky jsou jen bonus.

Je to stejná věc jako proč mít 32 architektonických GP registrů v ISA, když CPU má fyzicky stejně třeba 250 a pracuje převážně se zásobníkem a provádí eliminaci zbytečných Load-store párů a v podstatě mraky omezení ISA chytře obchází. Jenže bohužel zatímco ty fyzické registry řeší automaticky OoO, tak ty pitomé AVX512 se musí optimalizovat ručně. A to je ten průser plynoucí z porušení abstraktnosti.

Fixní vektorové registry = VLIW Itanium se všemi problémy
1) Teoreticky vysoký paralelní výkon (proto i GPU jsou VLIW).
2) Prakticky to brutálně závisí na kompilátoru a ruční optimalizaci a plný výkon se ve skutečnosti využije málokdy (proto GPU má super výkon, ale dej tomu pár IFů a skalární výpočet a výkon padne o několik řádů, což u grafických dat nehrozí, proto se to tam vyplatí, ale většina obecných algoritmů využije AVX512 jen málokdy. Zkus si v BIOSu vypnout AVX512 jestli při běžné práci a browsení po webu poznáš rozdíl, myslím že ani náhodou). Proto AMD i Intel valí AVX512 ve skutečnosti jako 256-bit vektory což má mnohem větší využitelnost i pro AVX2.

Proto si myslím že ARM hodil zpátečku s vektory i na tom Neoverse V2 jádře. Vysoký skalární výkon se 4x128-bit a přitom paralelní výkon z toho dostanou díky OoO stejný jako z AVX512.