onlangs er is een voorstel voor de Linux-kernel uitgebracht, waarin wordt voorgesteld om een set patches op te nemen met a geoptimaliseerde implementatie van de memchr() functie gebruikt om te zoeken naar een teken in een array.
De functie memchr() scant de eerste n bytes van het geheugengebied waarnaar wordt verwezen door s voor de eerste instantie van c. Zowel c als de bytes in het geheugengebied waarnaar wordt verwezen door s worden geïnterpreteerd als tekens zonder teken.
Het voorstel promete sneller zijn om een teken in een geheugenblok te lokaliseren. In ontwikkelaarstests kan de nieuwe implementatie bijna vier keer sneller zijn bij grote zoekopdrachten
In tegenstelling tot de vorige versie, die een byte-by-byte vergelijking gebruikte, is de voorgestelde implementatie gemaakt rekening houdend met het volledige gebruik van 64-bits en 32-bits CPU-registers. In plaats van bytes wordt de vergelijking gedaan met behulp van machinewoorden, waardoor ten minste 4 bytes tegelijk kunnen worden vergeleken.
Deze reeks patches optimaliseerde "memchr()" en voegde een macro toe voor
"memchr_inv()" zodat beide functies het kunnen gebruiken om een bitmasker te genereren.De oorspronkelijke implementatie van "memchr()" is gebaseerd op bytevergelijking,
die het 64- of 32-bits register in de CPU niet volledig gebruikt. We implementeren een
vergelijking door woorden zodat ten minste 4 bytes met hetzelfde kunnen worden vergeleken
het weer. De geoptimaliseerde memchr() is bijna 4 keer sneller dan het origineel
voor lange kettingen. In Linux Kernel vinden we dat de lengte van de string
gezocht door "memchr()" is maximaal 512 bytes in drivers/misc/lkdtm/heap.c.
Bij het zoeken op grote strings, de nieuwe versie bleek ongeveer 4 keer sneller te zijn dan de oude (bijvoorbeeld voor strings van 1000 karakters). Voor kleine ketens is de efficiëntie van de nieuwe implementatie niet zo significant, maar het is nog steeds hoger dan de originele versie.
Het interessante van het nieuwe voorstel is de verbetering voor grote ketens, wat de tijden aanzienlijk verbetert. Het is vermeldenswaard dat in de Linux-kernel, de grootte van strings verwerkt in memchr() bereikt 512 bytes. In onze tests was de prestatiewinst voor strings van 512 bytes, in een situatie waarin het zoekteken is aan het einde van de string, het is 20%.
Het is vermeldenswaard dat de originele versie van memchr() is geïmplementeerd met de byte-gewijze vergelijkingstechniek, die de registers op de 64-bits of 32-bits CPU niet volledig gebruikt.
We gebruiken hele woordvergelijking, zodat 8 tekens tegelijkertijd op de CPU kunnen worden vergeleken. Deze code is gebaseerd op de implementatie van David Light.
We maken twee bestanden om de prestaties van het eerste bestand te meten die gemiddeld 10 tekens vóór het bestemmingsteken bevat. Het tweede bestand bevat minimaal 1000 tekens voor de doel karakter.
Onze implementatie van "memchr()" is enigszins beter bij de eerste test en bijna 4 keer sneller dan het origineel implementatie in de tweede test.
Kernel 5.18 testen met nieuwe "memchr()"-variant voor 32-bits en 64-bits architecturen bracht geen problemen aan het licht.
Wat gebeurt er als p niet 8 (of 4 op 32-bits doelen) byte uitgelijnd is? Niet alle doelen ondersteunen niet-uitgelijnde (efficiënte) belastingen, toch?
Ik denk dat het werkt als p niet 8 of 4 bytes is uitgelijnd. Laten we zeggen dat de string 10 bytes is. De for-lus hier zoekt naar de eerste 8 bytes. Als het doelteken zich in de laatste 2 bytes bevindt, zal de tweede for-lus het vinden. Het werkt ook zo op 32-bits machines.
Algehele prestatiewinst nog niet geëvalueerd van de kernelsubsystemen bij gebruik van de geoptimaliseerde "memchr()"-variant, en er is ook niet besproken of de implementatie moet worden overschreven (de functieaanroep memchr() komt 129 keer voor in de kernelcode, inclusief stuurprogramma's en bestandssystemen).
Eindelijk Als u er meer over wilt weten, u kunt de details controleren In de volgende link.