Odpověď na názor

IMHO se to nedělá spíš proto, že když neznám dopředu velikost vektoru, tak se mi těžko optimalizuje algoritmus tak, aby fakt byl rychlejší a na to právě je naráženo v tom RVV patchi, kde autor říká, že to bude ideálně fungovat na 128bitech a s vyšší šířkou to nemusí být ideální.

Optimalizace v assembly se dělají tak, že člověk něco napíše a pak si to testuje na rychlost na reálném CPU a zkouší, co pomůže a co škodí. Když cílí na předem nedefinovanou velikost vektoru a ne moc definové CPU, tak tohle nemůže moc udělat a výsledek může být, že to moc nevyladí nebo třeba vyladí na jedno současné jádro, ale na ostatních to bude neefektivní. To se děje i na x86, protože třeba AVX2 nebo AVX-512 kód byl laděný na Intelu dřív, než byla implementace na AMD, kde to pak nemusí být optimální nebo může dojít ke stavu, kdy AVX2 cesta je pomalejší než SSE*. S těmahle SVE a podobně se ten problém ještě zvětší. Dokážu si představit, když budou šířky vektorů 128, 256, 512, 1024 a 2048, ale když tam uděláte extrémní volnost v šířce jednotek, tak už to bude těžké kočírovat.

P.S.
A taky jee trochu problém, že SIMD není jenom o tom, udělat sčítání nebo násobení 65tisíc krát, ale taky jsou u něj důležité operace které jdou napříč těmi SIMD lanes, permutace. Ty hlavně si s tímhle nebudou moc rozumět.

23. 6. 2023, 17:36 editováno autorem komentáře