Vlákno názorů k článku Dlouho očekávaná podpora SIMD operací v programovacím jazyku Go od atarist - jaké je typické urychlení řekněme maticových operací nebo...

jaké je typické urychlení řekněme maticových operací nebo nějakého zpracování obrazu? Protože jsem našel článek, kde píšou, že je to jen 15%. To mi připadne hodně málo popravdě řečeno. Ale asi záleží na konkrétním benchmarku.

Zalezi nejen na benchmarku - tedy SIMD operacich, ale i na architekture a nakonec i na uzivateli. Meril sem to v jave, kde JIT ma docela dobrou autovektorizaci ale manualni SIMD na x86_64 pri hodne velkych datech nebo pri hodne komplikovanych operacich sel klidne i 5x rychleji. Pokud bylo dat malo (ale porad dost na to aby JIT makl) tak mohlo klidne dojit i ke zpomaleni. Pkud jit nemakl, vzdycky byla manualni autovektorizace lepsi.

Odtud mam na autora otazku - jak je to se SIMD, Go a aarch64?

V jave jsem na to pri tech mich "benchmarcich" koukal dost vykulene. Tam kde intel zlepsil malicko, zlepsil malicko i aarch. Tam kde se intel zhorsil, se aarch64 vetsinou zrychlil, byt malo, ale tam kde se intel fakt hodne zrychlil, se arm bud zlepsil malinko, nebo i zhorsil. Primo v JEPu (posledni je https://openjdk.org/jeps/537 ) zminuji prakticky a intel, a z lidi co to delahji jsem vydoloval ze je to opravdu intel based, a proto se to tak tahne. Ale uz ne proc. Asi me znaji a vedeli ze je to na me moc slozita odpoved.

Mas pod clankem spoustu referenci, ktere by mohli "proc to" zdpovedet, takze.. nevis?

A jeste, proc je :vektorove instruke" nespravne? Zda se ze se to pouziva jako terminus technikus celosvetove.

Re Go a aarch64: porad je to experimental, ale v Go 1.27 je podpora pro 128bitove vektory a instrukce Neon (kdysi jsem o tom psal, tusim je to i v odkazech) a taky pro WASM (to se taky uz probiralo). Ale urcite se to bude jeste doplnovat, porad je to experimental (Go team neni v panic rezimu, maji na to cas, nebo si to aspon mysli)

Re vektorove instrukce: SIMD pracuji nad vektory pevne (omezene delky). Skutecne vektorove procesory (kdysi Cray napriklad, a "vector set" pro RISC-V) pracuji s vektory s neomezenou delkou. Takze rikat, ze napriklad SIMD soucet ctyrprvkovych vektoru je vektorova instrukce - to by se Seymour Cray pousmal.

Na druhú stranu, nemusím búrať steny v baráku, aby som počítač dostal do bytu ani ho chladiť kvapalinou. Rpi 5 prenesiem vo vrecku a chladí ho smiešne maličká vrtulka.

Abych to ujasnil - já neříkám, že současné SIMD operace jsou nějak špatné nebo nedostatečné. Je to věc pojmenování - prostě SIMD striktně řečeno nejsou vektorové operace.

PS: Ale Cray1 byl nádhernej stroj, asi bych si na něj udělal místo a pouštěl bublinky v těch jeho akváriích. Nebo aspoň Connection Machine, aby si to blikalo...

tento clanek ze? https://hexfusion.io/posts/go-simd-art/

Zalezi na algoritmu. My delame veci okolo embeddingu a tam je hlavni operaci vektorovy soucin nebo vypocet kosinu pro dva vektory. Tam to je +- 20%, i kdyz v cecku dosahuju mnohem lepsich vysledku (ale kdyz mrknes na Go assembler, to neni zadna super optimalizace)

Na cosine distance stačí dot product ne? Stačí mít spočítané normalizační koeficienty vektorů. U těch uložených to bude součást DB, a u toho input vectoru to jde předpočítat - těch dot productů je stejně potřeba stovky až tisíce pro jeden dotaz.

Pro RAG apod, kde jsou statické vektory, to je přesně jak píšeš. Jak se tam však začne hledat v dynamicky přijímaných datech a navíc nám stačí najít "první dostatečně podobný" vektor, tak už to nemá smysl předpočítávat hned. Ale obecně máš pravdu: buď mít v DB uložené normalizované vektory nebo do sloupečku vedle předpočítat normalizační koeficient.