Ostatnio opublikowano propozycję jądra Linuksa, w którym proponuje się dołączyć zestaw łatek z zoptymalizowana implementacja funkcji memchr() używany do wyszukiwania znaku w tablicy.
Funkcja memchr() skanuje wiodące n bajtów obszaru pamięci wskazywanego przez s dla pierwszego wystąpienia c. Zarówno c, jak i bajty w obszarze pamięci wskazywanym przez s są interpretowane jako znaki bez znaku.
Propozycja obietnice bądź szybszy zlokalizować znak w bloku pamięci. W testach deweloperskich nowa implementacja może być prawie czterokrotnie szybsza w przypadku dużych wyszukiwań
W przeciwieństwie do poprzedniej wersji, w której zastosowano porównanie bajt po bajcie, proponowana implementacja jest tworzona z uwzględnieniem pełnego wykorzystania 64-bitowych i 32-bitowych rejestrów procesora. Zamiast bajtów porównanie odbywa się za pomocą słów maszynowych, co pozwala na jednoczesne porównywanie co najmniej 4 bajtów.
Ta seria łatek zoptymalizowała "memchr()" i dodała makro dla
"memchr_inv()", aby obie funkcje mogły go użyć do wygenerowania maski bitowej.Oryginalna implementacja "memchr()" opiera się na porównaniu bajtów,
który nie w pełni wykorzystuje 64 lub 32-bitowy rejestr w CPU. Wdrażamy
porównanie za pomocą słów, aby co najmniej 4 bajty można było porównać z tym samym
pogoda. Zoptymalizowany memchr() jest prawie 4 razy szybszy niż oryginał
do długich łańcuchów. W jądrze Linux stwierdzamy, że długość łańcucha
szukane przez "memchr()" ma do 512 bajtów w drivers/misc/lkdtm/heap.c.
Podczas wyszukiwania na dużych ciągach, nowa wersja okazała się około 4 razy szybsza od starej (na przykład dla ciągów 1000 znaków). W przypadku małych sieci wydajność nowej implementacji nie jest tak znacząca, ale wciąż jest wyższa niż w oryginalnej wersji.
Ciekawostką w nowej propozycji jest usprawnienie dla dużych sieci, co znacznie poprawia czasy. Warto wspomnieć, że w jądrze Linuksa rozmiar napisów przetwarzanych w memchr() sięga 512 bajtów. W naszych testach wzrost wydajności dla 512-bajtowych ciągów w sytuacji, gdy szukany znak znajduje się na końcu ciągu, wynosi 20%.
Warto wspomnieć, że oryginalna wersja memchr() jest zaimplementowana techniką porównania bajtów, która nie wykorzystuje w pełni rejestrów w procesorze 64-bitowym lub 32-bitowym.
Używamy porównywania całych słów, dzięki czemu 8 znaków może być porównywanych w tym samym czasie na procesorze. Ten kod jest oparty na implementacji Davida Lighta.
Tworzymy dwa pliki, aby zmierzyć wydajność pierwszego pliku który zawiera średnio 10 znaków przed znakiem docelowym. Drugi plik zawiera co najmniej 1000 znaków przed charakter docelowy.
Nasza implementacja "memchr()" jest nieznacznie lepszy na pierwszym teście i prawie 4 razy szybszy od oryginału implementacja w drugim teście.
Testowanie jądra 5.18 z nowym wariantem "memchr()" dla architektur 32-bitowych i 64-bitowych nie ujawnił żadnych problemów.
Co się stanie, jeśli p nie jest równe 8 (lub 4 w przypadku 32-bitowych celów) wyrównane bajtami? Nie wszystkie cele obsługują niewyrównane (wydajne) obciążenia, prawda?
Myślę, że to działa, jeśli p nie jest wyrównane 8 lub 4 bajtami. Załóżmy, że ciąg ma 10 bajtów. Pętla for będzie szukała pierwszych 8 bajtów. Jeśli znak docelowy znajduje się w ostatnich 2 bajtach, druga pętla for go znajdzie. Działa to również w ten sposób na maszynach 32-bitowych.
Ogólny wzrost wydajności nie został jeszcze oceniony podsystemów jądra podczas używania zoptymalizowanego wariantu "memchr()", ani nie dyskutowano, czy nadpisać implementację (wywołanie funkcji memchr() występuje 129 razy w kodzie jądra, wliczając w to sterowniki i systemy plików).
W końcu Jeśli chcesz dowiedzieć się więcej na ten temat, możesz sprawdzić szczegóły W poniższym linku.