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ć.
W komentarzach o tym artykule pojawił się wątek optymalizacji tablic. https://lobste.rs/s/oxtwre/hard_numbers_wayland_vs_x11_input_latency#c_pmv0h3
Dziwne, że autor posta skupił się na zerowaniu pamięci, a nie na dodatkowym wywołaniu alokatora przez wektor.
Ale w sumie lepsze to niż dyskusja o rodzajach inicjalizacji w C++.
Mam nieodparte wrażenie, że już o tym rozmawialiśmy. Tylko ja liczyłem na to, że istnieje jakaś instrukcja przygotowująca linię cache do zapisu.
Z drugiej strony chciałbym zobaczyć na ile to prawda i przygotować jakiś benchmark. Wydaje mi się to trudne. Za dużo nie wiem co może zaburzyć pomiar.
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ć.