🚀 go-pugleaf

>> Ik vroeg me af of iemand een methode kende om packed bytes te roteren.
>> En gewone byte roteren is vrij makkelijk:
>>
>> ror AL, 1



>Misschien een domme vraag, maar wat is het verschil tussen een packed
>byte en een gewone byte?


SIMD, ofwel MMX, 3DNow!, Enhanced 3DNow!, SSE of SSE-2 voor x86.

Dus in het geval van MMX twee 32bit integers in een 64bit integer.


>> Maar met grote hoeveelheden data gaat dat traag worden.

>Dat ligt natuurlijk aan de hoeveelheid data, maar misschien als je een
>deel van de lus uitrolt dat je al genoeg snelheid kunt winnen.


Uiteraard, maar SIMD maakt het in principe nog vele malen sneller.
Loop-unrolling heeft als nadeel dat je code groter wordt, zodat de decoder
meer moet werken. Met SIMD maak je de code net zo compact, maar doet meer
tegelijk en voer je de loop dus minder vaak uit. (Of je doet beide.)

>> Nu vroeg ik mij af of het niet ook met MMX (of SSE/Enhanced 3DNow!)
>> kan.

>MMX heeft mi zo'n grote overhead dat het alleen bruikbaar is in hele
>specifieke situaties waarbij bv verschillende MMX instructies achter
>elkaar worden gebruikt.

MMX overhead?
Je refereerd toch niet naar de switch-instructie: EMMS, FEMMS?
Die is tegenwoordig vrij klein:

0 cycles op een Athlon
25/50 op een K6-2/III.
50 op een PII/PIII
12 op een P4

Dat haal je er makkelijk uit met een beetje hoeveelheden data/ lange loops

En waarom zou je uberhaupt moeten switchen? Ik gebruik geen floating-point
code, dus de unit wordt eenmalig in MMX-modes gezet en vervolgens blijft die
daar in.

Met SSE(2) bestaat verder geen noodzaak tot switchen en met (Enhanced)
3DNow! hoef je ook weinig tot niet te swicthen wat de floating-point code
doene we gewoon met (Enhanced) 3DNow! code.

>> 64bit-SIMD geeft 8 bytes en als ik die in een keer kan roteren
>> scheelt dat behoorlijk in de performance. Helaas heeft geen enkel
>> SIMD instructie-set de mogelijkheid bytes te roteren (wel word,
>> double word en quadword).


>> Nu kan ik wel ingerwikkeld gaan doen met shifts, and-operaties etc.,
>> maar dan is het voordeel een beetje weg.

>Inderdaad.

Dus vroeg ik mij af of ik iets over het hoofd zag, en of er dus - ondanks
dat er geen directe instructie is voor bytes - een truc was.

8 bytes per keer is veel: dat vervangt 8 losse instructies en dus verlaagd
heel wat decoder-bandbreedte en cache-druk. Een beetje overhead door
AND-operanties en shifts is dus helemaal niet erg, maar met teveel is
uiteraard wel het vorodeel weg.

Armin
--
Philips Semiconductors B.V.
Systems Laboratory Eindhoven (PS-SLE)

Backup not found: (A)bort (R)etry (P)anic

Tools:
http://www.phys.uu.nl/~gerritsn/download.html