kohët e fundit u lëshua një propozim për kernelin Linux, në të cilën propozohet të përfshihet një grup arnash me a implementimi i optimizuar i funksionit memchr(). përdoret për të kërkuar një karakter në një grup.
Funksioni memchr() skanon n bajtët kryesorë të zonës së kujtesës të treguar nga s për shembullin e parë të c. Si c ashtu edhe bajtët në zonën e kujtesës të treguar nga s interpretohen si karaktere të panënshkruara.
Propozimi premtimet të jetë më i shpejtë për të gjetur një personazh brenda një blloku memorie. Në testet e zhvilluesve, zbatimi i ri mund të jetë pothuajse katër herë më i shpejtë në kërkime të mëdha
Ndryshe nga versioni i mëparshëm, i cili përdorte një krahasim byte-pas-byte, implementimi i propozuar është krijuar duke marrë parasysh përdorimin e plotë të regjistrave të CPU 64-bit dhe 32-bit. Në vend të bajteve, krahasimi bëhet duke përdorur fjalë makinerike, gjë që lejon të paktën 4 bajt të krahasohen në të njëjtën kohë.
Kjo seri arnimesh optimizoi "memchr()" dhe shtoi një makro për
"memchr_inv()" në mënyrë që të dy funksionet ta përdorin atë për të gjeneruar një bitmask.Implementimi origjinal i "memchr()" bazohet në krahasimin e bajtit,
i cili nuk përdor plotësisht regjistrin 64 ose 32 bit në CPU. Ne zbatojmë një
krahasimi me fjalë në mënyrë që të paktën 4 bajt të mund të krahasohen me të njëjtat
moti. Memchr() i optimizuar është pothuajse 4 herë më i shpejtë se origjinali
për zinxhirë të gjatë. Në Linux Kernel, gjejmë se gjatësia e vargut
e kërkuar nga "memchr()" është deri në 512 bajt në drivers/misc/lkdtm/heap.c.
Kur kërkoni në vargje të mëdha, versioni i ri doli të ishte rreth 4 herë më i shpejtë se ai i vjetër (për shembull, për vargjet me 1000 karaktere). Për zinxhirët e vegjël, efikasiteti i zbatimit të ri nuk është aq i rëndësishëm, por është akoma më i lartë se versioni origjinal.
Gjëja interesante e propozimit të ri është përmirësimi për zinxhirët e mëdhenj, i cili përmirëson ndjeshëm kohën. Vlen të përmendet se në kernelin Linux, madhësia e vargjeve të përpunuara në memchr() arrin 512 bajt. Në testet tona, performanca fiton për vargjet 512-byte, në një situatë ku karakteri i kërkimit është në fund të vargut, është 20%.
Vlen të theksohet se versioni origjinal i memchr() është implementuar me teknikën e krahasimit me bajt, e cila nuk përdor plotësisht regjistrat në CPU-në 64-bit ose 32-bit.
Ne përdorim krahasimin e të gjithë fjalëve në mënyrë që 8 karaktere të mund të krahasohen në të njëjtën kohë në CPU. Ky kod bazohet në zbatimin e David Light.
Ne krijojmë dy skedarë për të matur performancën e skedarit të parë i cili përmban mesatarisht 10 karaktere përpara karakterit të destinacionit. Skedari i dytë përmban të paktën 1000 karaktere përpara karakteri i synuar.
Zbatimi ynë i "memchr()" është pak më mirë në provën e parë dhe pothuajse 4 herë më shpejt se origjinali zbatimi në testin e dytë.
Testimi i kernelit 5.18 me variantin e ri "memchr()" për arkitekturat 32-bit dhe 64-bit nuk zbuloi asnjë problem.
Çfarë ndodh nëse p nuk është në linjë 8 (ose 4 në objektivat 32 bit) bajt? Jo të gjitha objektivat mbështesin ngarkesa të palidhura (efikase), apo jo?
Unë mendoj se funksionon nëse p nuk është i rreshtuar 8 ose 4 bajt. Le të themi se vargu është 10 bajt. Cikli for këtu do të kërkojë 8 bajtët e parë. Nëse karakteri i destinacionit është në 2 bajtin e fundit, cikli i dytë for do ta gjejë atë. Gjithashtu funksionon kështu në makinat 32-bit.
Fitimi i përgjithshëm i performancës nuk është vlerësuar ende e nënsistemeve të kernelit kur përdoret varianti i optimizuar "memchr()", as nuk është diskutuar nëse duhet të anashkalohet zbatimi (thirrja e funksionit memchr() ndodh 129 herë në kodin e kernelit, duke përfshirë drejtuesit dhe sistemet e skedarëve).
Më në fund Nëse jeni të interesuar të dini më shumë për këtë, ju mund të kontrolloni detajet Në lidhjen vijuese.