Vlákno názorů k článku Podpora SIMD operací v GCC s využitím intrinsic: technologie SSE od atarist - To ze se SIMD nepouzivaji v interpretrech a...

To ze se SIMD nepouzivaji v interpretrech a prekladacich se pomalu meni. V JVM uz je dokonce par optimalizaci pro AVX-512. Testuji si to pres CPUID a tak a byvaji tam chybky v detekci, co procesor umi a co ne :)

Souhlas, mainstream překladače umí SIMD už poměrně dlouho. Dokonce, jak jsem minule psal, že to spíš bývá na úrovni SSE nebo možná FMA, tak gcc-12 už mi dává ještě lepší výsledky na úrovni AVX-2 (kdysi jsem jej netestoval, bo tam měli <a href="https:/­/gcc.gnu.org/bug­zilla/show_bug­.cgi?id=104188>chy­bu v AVX-512, navíc jsem možná měl vypnuté -ffast-math). Zkusím zjistit přesněji, kde ještě zaostává.

U vysokoúrovňových jazyků to může být složitější, neboť data obvykle nebývají uložena v souvislém poli primitivních typů, takže načíst vektor je komplikované. JVM jsem více nezkoumal, ale obecně všem těmto jazykům chybí primitivní struktury - snad se někdy dočkáme.

No ano, překadače umí SIMD už dlouho, ale problém je, že sémantika jazyků (třeba toho céčka) je čistě ve stylu: jeden thread a zpracováváme skalární hodnoty.

Jakákoli vektorizace je tak složitá. Třeba nějaká snaha o změnu formátu bitmapy (RGB v plane modu do packed modu), co by šla řešit přes dvě "shuffle" instrukce se takto (IMHO) nikdy nepřeloží, protože to céčko z kódu prostě nepozná.

PS: Cray to měl na svých počítačích lehké, bo autovektorizova FORTRAN a to ještě přesně popsané typy smyček a konstrukcí.

U C to může být složitější, bo musí počítat s tím, že jednotlivá pole se mohou překrývat, nemusí být správně zarovnané apod., takže přímočaře napsaný algoritmus může být potenciálně náchylný na vedlejší efekty, které kompilátor musí zachovat. Ale jinak souhlasím, kompilátory spíš dnes řeší autovektorizaci aritmetických operací, víc než image media speciality. Na druhé straně, reálné image media algoritmy jsou o dost komplikovanější, takže ztrácet čas zlepšovaním kompilátoru, aby vyřešil jen část problému, nejspíš nedává smysl - lidi stejně relevantní části v asm nebo intrinsic, aby optimalizovali celek. IMHO srovnání s Cray a Fortran není zcela korektní, neboť ty se využívaly právě spíš na matematické operace než manipulace s obrázky. Možná se pletu.

Ohledně zmiňované optimalizace v gcc-12: Porovnal jsem výsledek kompilátoru a 256-bit FMA (AVX-2) pro násobení matic 4*4 a dělá to podobně, s tím, že: používá 256-bit YMM registry, používá 4 násobení, 2 sčítání a 4 násobení se sčítáním místo 2 násobení a 6 násobení se sčítáním, v důsledku všeho používá víc permute a broadcast instrukcí než je nutné, má tam ještě jednu zvláštní operaci čtení a zápisu z/do FS segmentu, ve výsledku je asi o 30% pomalejší. Takže není to špatné, trochu mě překvapuje, že přesto, že je zjevně schopen pochopit vektorizaci toho cyklu, tak vybere neoptimální cestu.

Pro porovnání, clang-14 na aarch64 Neon taky pochopí vektorizaci a použije správnou kombinaci sčítání a násobení se sčítáním, ale jednotlivé prvky z druhé matice nahrává po jednom, místo po celém vektoru a následným násobením indexem vektoru. K tomu zbytečné ukládání na stack, které je pravděpodobně dáno nejistotou ohledně potenciálního překryvu vstupních a výstupních parametrů. Ve výsledku asi 2.5* pomalejší.

To srovnání s Crayem skutečně není korektní v kontextu multimediálních dat. Tam se rozpoznávaly jen určité typy smyček a operací, typicky s floaty (Cray měl vlastní formát, ne podle IEEE 754). Zase na druhou stranu bylo hodně jasné, co a jak se přeloží, a ta Crayovská instrukční sada (musím dohledat) byla v tomto ohledu docela jednoduchá a RISCová (i když tento termín asi ještě neexistoval).

Trošku OT, ale hodně dobře rozumí/rozuměly C kódu překladače pro VLIW DSP, například pro čipy od TI atd. Tam se nejednalo o vektorizaci, ale o optimalizaci na různé ty post/pre inkrementy, dekrementy, přístupy do polí, včetně "motýlků" u fourierky, MAC operace atd. Tam jsem měl v praxi pocit, že C je fakt jen high level assembler (na x86 je to spíš přání :-).

Jinak výsledek jen o 30% horší je asi fajn (navíc ukazuje, že člověk má k tématu assembleru atd. ještě hodně co říct, i když se dneska traduje opak :-)

https://docs.oracle.com/en/java/javase/16/docs/api/jdk.incubator.vector/jdk/incubator/vector/IntVector.html

Pěkné, díky!

Trochu mi u https://docs.oracle.com/en/java/javase/16/docs/api/jdk.incubator.vector/jdk/incubator/vector/FloatVector.html chybí fmaLane, ale jinak to vypadá použitelně, za předpokladu, že to dokáže JVM slušně vektorizovat. Někdy se budu muset na výsledek podívat To nic nemění na tom, že primitivní struktury by se pořád hodily .

"Incubating Feature. Will be removed in a future release."

To budou jeste stabilizovat nebo to fakt vyhodi?

No v kazdem pripade to vypada zajimave, vubec netusim, jak to resi v bajtkodu (asi jen tim typem).

bytecode bude pořád jednoduché volání metod. Do SIMD se potenciálně přeloží až v JIT, podle runtime architektury (nebo taky ne, záleží, jak daleko je samotná implementace).

Jinak samozřejmě, aby to nedopadlo jako s Unsafe. Člověk to začne používat a za pár let to zmizí. Předpokládám, že zatím bude pro interní použití nějakých math či multimedia classes, snad to časem stabilizují a otevřou.

No budu víc sledovat vývoj NumPy, tam by se to mohlo pohnout dopředu. Je tam spousta problémů (vůbec výběr jazyka a tak), ale taktéž velká možnost ty výpočty víc optimalizovat (ale stejně, pořád tam je ten interop s VM).