nylig et forslag til Linux-kernen blev udgivet, hvori det foreslås at inkludere et sæt plastre med en optimeret implementering af memchr()-funktionen bruges til at søge efter et tegn i et array.
Funktionen memchr() scanner de førende n bytes af hukommelsesområdet, der peges på af s for den første forekomst af c. Både c og bytes i hukommelsesområdet, der peges på af s, fortolkes som usignerede tegn.
Forslaget løfter være hurtigere at lokalisere et tegn i en hukommelsesblok. I udviklertests kan den nye implementering være næsten fire gange hurtigere ved store søgninger
I modsætning til den tidligere version, som brugte en byte-for-byte sammenligning, er den foreslåede implementering skabt under hensyntagen til den fulde brug af 64-bit og 32-bit CPU-registre. I stedet for bytes udføres sammenligningen ved hjælp af maskinord, som gør det muligt at sammenligne mindst 4 bytes ad gangen.
Denne serie af patches optimerede "memchr()" og tilføjede en makro til
"memchr_inv()", så begge funktioner kan bruge det til at generere en bitmaske.Den oprindelige implementering af "memchr()" er baseret på byte-sammenligning,
som ikke fuldt ud bruger 64 eller 32 bit registeret i CPU'en. Vi implementerer en
sammenligning med ord, så mindst 4 bytes kan sammenlignes med det samme
vejr. Den optimerede memchr() er næsten 4 gange hurtigere end originalen
til lange kæder. I Linux Kernel finder vi, at længden af strengen
søgt efter af "memchr()" er op til 512 bytes i drivers/misc/lkdtm/heap.c.
Når du søger på store strenge, den nye version viste sig at være omkring 4 gange hurtigere end den gamle (for eksempel for strenge på 1000 tegn). For små kæder er effektiviteten af den nye implementering ikke så væsentlig, men den er stadig højere end den originale version.
Det interessante ved det nye forslag er forbedringen for store kæder, som forbedrer tiderne betydeligt. Det er værd at nævne, at i Linux-kernen, størrelsen af strenge behandlet i memchr() når 512 bytes. I vores tests opnår ydeevnen for 512-byte strenge, i en situation hvor søgetegnet er i slutningen af strengen, er det 20%.
Det er værd at nævne, at den originale version af memchr() er implementeret med den byte-vise sammenligningsteknik, som ikke fuldt ud bruger registrene på 64-bit eller 32-bit CPU.
Vi bruger hele ord sammenligning, så 8 tegn kan sammenlignes på samme tid på CPU'en. Denne kode er baseret på David Lights implementering.
Vi opretter to filer for at måle ydeevnen af den første fil som i gennemsnit indeholder 10 tegn foran destinationstegnet. Den anden fil indeholder mindst 1000 tegn før målkarakter.
Vores implementering af "memchr()" er lidt bedre ved første test og næsten 4 gange hurtigere end originalen implementering i den anden test.
Kernel 5.18 test med ny "memchr()" variant til 32-bit og 64-bit arkitekturer afslørede ingen problemer.
Hvad sker der, hvis p ikke er 8 (eller 4 på 32 bit mål) byte justeret? Ikke alle mål understøtter ikke-justerede (effektive) belastninger, vel?
Jeg tror det virker, hvis p ikke er 8 eller 4 byte justeret. Lad os sige, at strengen er 10 bytes. For-løkken her vil lede efter de første 8 bytes. Hvis destinationstegnet er i de sidste 2 bytes, vil den anden for loop finde det. Det fungerer også sådan på 32-bit maskiner.
Samlet præstationsgevinst endnu ikke evalueret af kerneundersystemerne ved brug af den optimerede "memchr()"-variant, og det er heller ikke blevet diskuteret, om implementeringen skal tilsidesættes (funktionskaldet memchr() forekommer 129 gange i kernekoden, inklusive drivere og filsystemer).
Endelig Hvis du er interesseret i at vide mere om det, du kan kontrollere detaljerne I det følgende link.