🚀 go-pugleaf

Wojciech Muła pisze:
> Hej, kontynuacja wątku założonego przez Andrzeja.
> U mnie niestety starsze posty wyparowały, więc nie mam
> gdzie się podczepić.
> 
> Przetestowałem właśnie kilka metod:
> * "bajty"  - naiwny algorytm zamiany bajt po bajcie
> * BSWAP    - zmiana 4 bajtów na iterację (1 x BSWAP)
> * 2xBSWAP  - zmiana 8 bajtów na iterację (2 x BSWAP)
> * PSHUFB   - zmiana 16 bajtów na iterację (1 x PSHUFB)
> * 2xPSHUFB - zmiana 32 bajtów na iterację (2 x PSHUFB)
> 
> Rozmiary tablic są wielokrotnością 32 bajtów, więc wszystkie
> dostępy do pamięci były wyrównane. Procesor Core 2 Duo E8400.
> W tabelce są czasy wykonywania kilku-kilkuset tysięcy iteracji.
> Mój wniosek nie jest odkrywczy: najbardziej ograniczają nas
> czasy dostępu do pamięci.
> 
> +-------------+-----------+----------------+----------------+----------------+----------------+
> |  rozmiar    |   bajty   |      BSWAP     |    2xBSWAP     |     PSHUFB     |    2xPSHUFB    |
> +-------------+-----------+--------+-------+--------+-------+--------+-------+--------+-------+
> |   64 B      |  759 ms   | 292 ms | 2.6 x | 267 ms | 2.8 x | 240 ms | 3.1 x | 138 ms | 5.5 x |
> +-------------+-----------+--------+-------+--------+-------+--------+-------+--------+-------+
> |  128 B      |  740 ms   | 264 ms | 2.8 x | 218 ms | 3.4 x | 108 ms | 6.8 x | 107 ms | 6.9 x |
> +-------------+-----------+--------+-------+--------+-------+--------+-------+--------+-------+
> |  256 B      |  808 ms   | 303 ms | 2.6 x | 243 ms | 3.3 x |  81 ms | 9.9 x |  72 ms |11.2 x |
> +-------------+-----------+--------+-------+--------+-------+--------+-------+--------+-------+
> |  512 B      | 1026 ms   | 394 ms | 2.6 x | 305 ms | 3.3 x |  91 ms |11.2 x |  84 ms |12.2 x |
> +-------------+-----------+--------+-------+--------+-------+--------+-------+--------+-------+
> |    1 kB     | 1000 ms   | 404 ms | 2.4 x | 298 ms | 3.3 x |  81 ms |12.3 x |  69 ms |14.5 x |
> +-------------+-----------+--------+-------+--------+-------+--------+-------+--------+-------+
> |    4 kB     |  786 ms   | 312 ms | 2.5 x | 235 ms | 3.3 x |  64 ms |12.0 x |  50 ms |15.7 x |
> +-------------+-----------+--------+-------+--------+-------+--------+-------+--------+-------+
> |    8 kB     |  793 ms   | 310 ms | 2.5 x | 235 ms | 3.4 x |  61 ms |13.0 x |  51 ms |15.5 x |
> +-------------+-----------+--------+-------+--------+-------+--------+-------+--------+-------+
> |   16 kB     | 1582 ms   | 617 ms | 2.6 x | 467 ms | 3.4 x | 120 ms |13.2 x | 100 ms |15.8 x |
> +-------------+-----------+--------+-------+--------+-------+--------+-------+--------+-------+
> 
> w.
> 

Jak pamiętasz, zadałem na początku pytanie: czy przy odwracaniu
kolejności bajtów BSWAP może się do czegoś przydać?

Jaki wniosek?

Co prawda w ogólnym przypadku długość pola nie jest wielokrotnością 4, 
ale zaprezentowany przeze mnie algorytm po wykonaniu serii instrukcji 
BSWAP wykonuje jeszcze CO NAJWYŻEJ DWIE ZAMIANY, czyli dodatkowy koszt 
jest stały i niewielki. W ogólnym przypadku pola ładowane/zapisywane 
do/z rejestrów EAX i EDX nie są wyrównane do DWORD, co też może wydłużać 
czasy podane powyżej (a propos: czy rozmiar tablicy będący 
wielokrotnością 32 gwarantuje, że cała tablica będzie wyrównana na 
adresie podzielnym przez 32? Chyba jednak nie...).

Skoro już wziąłeś się za pomiary, to spróbuje porównać moją procedurę z 
naiwnym przestawianiem bajtów.



     PUSH EBX
     PUSH ESI
     PUSH EDI

     CLD

     LEA EDI,[ESI+ECX-4]

     MOV EBX,ECX

     ADD ECX,4
     SHR ECX,3
     JZ  @@Partial

@@Loop:
     LODSD
     MOV EDX,[EDI]
     BSWAP EAX
     BSWAP EDX
     STOSD
     MOV [ESI-4],EDX
     SUB EDI,8
     LOOP @@Loop

@@Partial:

     ; być może ten kawałek można lepiej zrobić
     AND EBX,7
     JZ  @@Done
     TEST EBX,4
     JNZ @@Done
;---------------------------
     LEA  EDI,[ESI+EBX-1]
     MOV  AL,[EDI]
     MOVSB
     MOV [ESI-1],AL

@@Done:

     POP EDI
     POP ESI
     POP EBX