Názory k článku Dlouho očekávaná podpora SIMD operací v programovacím jazyku Go

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.

Pokud o spuštění v mém případě ovšem dopadne neslavně, protože mikroprocesor v mém počítači AVX-512 nepodporuje (je totiž určen pro běžnou práci, nikoli pro vytápění domácnosti):

Toto je ale hodně hloupý komentář...

Mno při měření vycházelo, že provoz AVX-512 vede k frequenci throttlingu až někam na 60% top frekvence (Intel čipy, Xeony v serverech, takže určitě ne low end). Takže to asi hodně topilo. Zase - to je asi logické, když tomu dám spočítat dejme tomu druhou odmocninu ze šestnácti floatů naráz (teď popravdě z hlavy nevím, jestli je druhá odmocnina ta nejsložitější instrukce, možná 1/r nebo 1/sqrt(r)?)

To platilo pro první generaci Intel CPU s AVX-512, tedy Skylake-X. Moderní micro-architektury tímto netrpí. Navíc u AMD je to naopak - při použití AVX-512 jde spotřeba dolů, protože má míň práce decoder.

Takze Linusovo "I think the 512-bit part is a hot mess" uz neplati?

Už dávno ne.

Navíc X86 má díky komplikovanému dekodéru v podstatě jen tu jednu možnost - udělat víc za jednu instrukci (proto AVX-512) aby ty CPU mohli konkurovat ARMu. Dekódovat víc než 4 instrukce za cyklus je náročné, a i ty 4 instrukce jsou peklo (proto tam jsou nějaké omezení).

AArch64 má mnohem lepší intrukční sadu pro generické operace, ale má zase horší SIMD (NEON je jen 128-bit a SVE je v podstatě neaplikovatelné na zajímavé problémy).

Takže AVX-512 je vlastně jediná budoucnost X86 architektury (klidně ať si tomu Intel říká AVX10, ale to je jen rebranded AVX-512).

me to taky trklo, ale ne ze bych myslel, ze je to hloupost, ale je to autoruv humor.

me by zajimalo jaky je rozdil pouzit 2x X bytove funkce a registry proti pouziti 1x ale 2xX vetsich funkci a registru?