Chyba gadaliśmy kiedyś o niskim narzucie instrukcji, które wielokrotnie modyfikują tę samą linie cache’u.
Pamiętam, że uzyskałem kiedyś spory przyrost wydajności w dekompresorze LZ4 poprzez kopiowanie 16 albo 32 bajtów, niezależnie od tego, ile danych faktycznie miało być skopiowane.
Jedna z operacji w LZ4 polega na skopiowaniu jakiegoś fragmentu już zdekompresowanych danych. Często są to małe obszary, rzędu 3-4 bajtów. Ja zawsze kopiowałem wtedy dane nadrmiarowo, do pełnej szerokości rejestru SIMD i tylko inkrementowałem wskaźnik do następnego zapisu o prawidłowy rozmiar danych.
To powoduje, że kilka razy nadpisuje się te same obszary w pamięci ale nadal jest to bardziej efektywne od precyzyjnego przycinania kopiowanych bajtów.
Pisaliśmy nawet o tym, że nie powinno się zapisywać i odczytywać pamięci w krótkich odstępach czasu. Bo to ląduje w osobnych kolejkach. Od tego czasu dużo się zmieniło. Kolejka odczytu stała się tablicą, a w AMD są rejestry mapowane na pamięć. By trza to zweryfikować.
Chyba gadaliśmy kiedyś o niskim narzucie instrukcji, które wielokrotnie modyfikują tę samą linie cache’u.
Pamiętam, że uzyskałem kiedyś spory przyrost wydajności w dekompresorze LZ4 poprzez kopiowanie 16 albo 32 bajtów, niezależnie od tego, ile danych faktycznie miało być skopiowane.
Jedna z operacji w LZ4 polega na skopiowaniu jakiegoś fragmentu już zdekompresowanych danych. Często są to małe obszary, rzędu 3-4 bajtów. Ja zawsze kopiowałem wtedy dane nadrmiarowo, do pełnej szerokości rejestru SIMD i tylko inkrementowałem wskaźnik do następnego zapisu o prawidłowy rozmiar danych.
To powoduje, że kilka razy nadpisuje się te same obszary w pamięci ale nadal jest to bardziej efektywne od precyzyjnego przycinania kopiowanych bajtów.
Pisaliśmy nawet o tym, że nie powinno się zapisywać i odczytywać pamięci w krótkich odstępach czasu. Bo to ląduje w osobnych kolejkach. Od tego czasu dużo się zmieniło. Kolejka odczytu stała się tablicą, a w AMD są rejestry mapowane na pamięć. By trza to zweryfikować.