Názory k článku Instrukční sady SIMD a automatické vektorizace prováděné překladačem GCC (3)

Ten broadcast byte do všech lanes teda nic moc.

Dřív se používalo spíš něco jako toto (kompaktnější):

IMUL eax, eax, 0x01010101 // broadcast byte to dword
MOVD xmm0, eax
PSHUFD xmm0, xmm0, 0x00  // broadcast dword to dqword

Nebo třeba toto (ideálně pokud už konstanta 0 je v registru xmm7):

PXOR xmm7, xmm7 // xmm7 = 0
MOVD xmm0, eax
PSHUFB xmm0, xmm7 // broadcast byte to dqword

Ale není nad AVX512:

VPBROADCASTB xmm0, eax // broadcast byte to dqword

souhlas, AVX512 je už konečně udělaná dobře. Proto nám ji Intel do procesorů nedává a raději se řeší divná AVX10 (ok od verze 3 to už není pain).

Podobné věci jsem viděl naposledy dost dávno, a tehdy se - aspoň u těch char* nulování - řešilo speciálně "dozarovnání" na kulaté adresy, aby ty vícebajtové instrukce pracovali na "přirozeném" bloku. Proč to už není potřeba? Už to je procesoru jedno, nebo už jsou zarovnané i char*? Nebo to zarovnávání vždycky byl jen cargo kult?

Ona instrukce MOVUPS má +- třikrát větší latenci než MOVAPS, takže ty výsledné programy nejsou úplně dobré. Ale tady překladač zjistil, že než si nějakými bitovými operacemi řešit zarovnání začátku a konce třeba 32bajtového pole, tak bude lepší tam vrazit dvě MOVUPS. Cargo kult to není - vždycky se narazí na šířku datové sběrnice.

Myslel jsem původně i ten stosq příklad, ale teď na to koukám pořádně a tam to zarovnání vlastně dělá - zapíše první, poslední, a pak zarovná přes and -8 a jede.

ano, tam to dela. Sice zvlastne, ale dela (zkusim, jak to vyresi u pole vetsiho nez stranka pameti - tam by asi nemel provadet zapis posledniho prvku hned na zacatku, tim zmate cache).

Mezi MOVAPS a MOVUPS už dlouho není rozdíl, pokud cílová adresa je zarovnaná, takže safe je použít unaligned instrukce, protože když adresa je aligned, tak k žádné penalizaci nedojde. Naopak MOVAPS je dobré použít tam, kde je opravdu očekáváné, že adresa je zarovnaná, protože CPU se postará o SIGBUS v případě, že tomu tak není.

Pokud je ale nějaký cyklus dlouhý a pracuje s jedním polem, je lepší pointer zarovnat manuálně, protože pak CPU nemusí kombinovat více cache lines dohromady (tady klesá IPC) - nejhorší je ale page split - pokud chci unaligned read/write, který je někde mezi 2 pages, tak tam je penalizace o řády větší než pár cyklů (nemluvím o případném page fault).

Obecně říct, že latence unaligned vs aligned je 3x horší ale dnes nejde, pokud člověk nezmíní konkrétní mikroarchitekturu. Třeba když CPU podporuje 2x512-bit fetch, tak buď to budou 2x512-bit aligned a nebo 1x512-bit unaligned (kde se fetch udělá 2x). Takže latence pořád může být 1 cyklus, ale už není možné udělat další paralelní fetch.

pravda, dneska už to asi není 3x horší. My to měřili někdy u i5, když jsme ještě neměli AVX-512 na pracovních stanicích (na ntb. není dodnes). Fakt je, že překladač dává MOVAPS jen když si je jistý (pomůžeme překladači), jinak - jak píšeš - to pěkně zpanikaří.