Vlákno názorů k článku Podpora SIMD (vektorových) instrukcí na RISCových procesorech od alex6bbc - ted bude pekne jeste najit implementaci nasobeni matic,...
-
Má, pořád je to 27 násobení (nebo 64 pro 4*4 matice, které jsou obvyklejší). I s overhead na call se to může vyplatit. Lepší je samozřejmě napsat a zkompilovat větší kus kódu pro různé architektury. Pro představu, násobení matic 4*4 nebo matice a vektoru 4*4 :
_ref je přímý výsledek kompilátoru, _novec se zakázanou vektorizací.
x86_64 (laptop, Intel Core i7):
matmult_ref : 22.27 cycles, avg 24.28 cycles, 197.229 MOPS
matmult_novec : 57.42 cycles, avg 58.07 cycles, 82.652 MOPS
matmult_Avx512 : 7.03 cycles, avg 7.66 cycles, 626.281 MOPS
vecmult_ref : 3.96 cycles, avg 4.15 cycles, 1156.402 MOPS
vecmult_novec : 14.36 cycles, avg 14.54 cycles, 330.136 MOPS
vecmult_Avx512 : 1.46 cycles, avg 1.69 cycles, 2846.387 MOPS
aarch64 (Graviton 3):
matmult_ref : 21.97 cycles, avg 22.67 cycles, 110.261 MOPS
matmult_novec : 34.18 cycles, avg 34.81 cycles, 71.806 MOPS
matmult_NeonPar2 : 7.93 cycles, avg 9.35 cycles, 267.375 MOPS
matmult_SveSingle : 4.44 cycles, avg 7.04 cycles, 369.560 MOPS
vecmult_ref : 3.28 cycles, avg 3.86 cycles, 647.590 MOPS
vecmult_novec : 6.56 cycles, avg 6.73 cycles, 371.362 MOPS
vecmult_NeonPar2 : 1.91 cycles, avg 2.27 cycles, 1102.215 MOPS
vecmult_Sve : 0.40 cycles, avg 0.48 cycles, 5411.007 MOPSKompilátor něco zvládne, ale i u takhle malých matic či vektorů může být rozdíl mezi autovektorizací a kódem pro složitější architekturu několikanásobný. Autovektorizace u kompilátoru je typicky spíš na úrovni SSE, možná AVX-2.
-
ah vidis, ja mam porad (bez mereni) nejak v hlave, ze volat univerzalni algoritmus z nejake knihovny pro neco tak malyho bude spatny, ale nevypada to tak (spis jsem tedy myslel nasobeni vektoru matici - proste transformace, ale o tom se vlastne nebavime - muj problem)
Btw ty pocty cyklu ve druhem sloupci se nejak pocitaji? Ze to nejsou cela cisla...
-
Transformace je u těch vecmult. Ale je to násobení pole vektorů, takže ten call overhead se tam docela ztratí.
Ten první je nejlepší zaznamenaný čas na krátkém vzorku, nikoliv jednom prvku, i tak je náchylnější na chyby. Avg je průměrný čas přes celé měření. Většinou by měly být přibližně stejné, ale Avx-512 a SVE na Graviton 3 ten výkon dlouhodobě neudrží.
-
Je tam dost užitečných operací navíc, takže je to zlepšení. Že se to přehřívá - expert nejsem - jestli je to vysoký počet velkých registrů (které se prostě nedají v normálním kódu nejspíš využít) nebo ten CPU nestíhá takové množství operací. Zvláštní je, že Apple M1 zvládá ty operace rychleji i s jenom 128-bitovým Neon a paradoxně i ten strojový kód je podobně velký. Ale Apple M1 je už zase na lepším výrobním procesu, takže není úplně korektní je porovnávat.
Takže se spíš přikláním k tomu, že primární brzdou bude ta 50 let rozšiřovaná CISC instrukční sada, se kterou už nic udělat ohledně superscalar nepůjde a Intel i AMD ji budou muset zahodit.
ČLÁNKY DO MAILU