nemrég megjelent a Linux kernelre vonatkozó javaslat, amelyben azt javasolják, hogy tartalmazzanak egy foltkészletet a a memchr() függvény optimalizált megvalósítása karakterek keresésére szolgál egy tömbben.
A memchr() függvény a memóriaterület első n bájtját vizsgálja, amelyre s mutat a c első példánya esetén. Mind a c, mind az s által mutatott memóriaterület bájtjai előjel nélküli karakterekként értelmeződnek.
A javaslatot ígér legyen gyorsabb karakter megkereséséhez egy memóriablokkon belül. A fejlesztői tesztekben az új megvalósítás csaknem négyszer gyorsabb lehet nagy kereséseknél
Ellentétben az előző verzióval, amely bájtonkénti összehasonlítást használt, a javasolt megvalósítás a 64 bites és 32 bites CPU regiszterek teljes kihasználásának figyelembevételével jön létre. Bájtok helyett gépi szavakkal történik az összehasonlítás, ami lehetővé teszi legalább 4 bájt egyidejű összehasonlítását.
Ez a javítássorozat optimalizálta a "memchr()"-t, és hozzáadott egy makrót a következőhöz
"memchr_inv()", így mindkét függvény használhatja bitmaszk létrehozására.A "memchr()" eredeti megvalósítása bájtok összehasonlításán alapul,
amely nem használja teljes mértékben a 64 vagy 32 bites regisztert a CPU-ban. Megvalósítjuk a
szavakkal való összehasonlítás, hogy legalább 4 bájt összehasonlítható legyen ugyanazzal
időjárás. Az optimalizált memchr() majdnem 4-szer gyorsabb, mint az eredeti
hosszú láncokhoz. A Linux Kernelben azt találjuk, hogy a karakterlánc hossza
A "memchr()" által keresett kifejezés legfeljebb 512 bájt lehet a drivers/misc/lkdtm/heap.c fájlban.
Ha nagy karakterláncokon keres, az új verzió körülbelül 4-szer gyorsabbnak bizonyult, mint a régi (például 1000 karakteres karakterláncok esetén). A kis láncok esetében az új megvalósítás hatékonysága nem olyan jelentős, de még mindig magasabb az eredeti verziónál.
Az új javaslat érdekessége a nagy láncok fejlesztése, ami jelentősen javítja az időt. Érdemes megemlíteni, hogy a Linux kernelben a memchr()-ben feldolgozott karakterláncok mérete eléri az 512 bájtot. Teszteinkben az 512 bájtos karakterláncok teljesítménynövekedése olyan helyzetben, amikor a keresési karakter a karakterlánc végén van, ez 20%.
Érdemes megemlíteni, hogy a memchr() eredeti verziója a byte-wise összehasonlító technikával van megvalósítva, amely nem használja teljes mértékben a 64 bites vagy 32 bites CPU regisztereit.
Teljes szóösszehasonlítást alkalmazunk, így 8 karaktert lehet egyszerre összehasonlítani a CPU-n. Ez a kód David Light megvalósításán alapul.
Két fájlt hozunk létre az első fájl teljesítményének mérésére amely átlagosan 10 karaktert tartalmaz a cél karakter előtt. A második fájl legalább 1000 karaktert tartalmaz a célkarakter.
A "memchr()" implementációja kissé elmarad jobb az első teszten és majdnem 4-szer gyorsabb, mint az eredeti megvalósítás a második tesztben.
Kernel 5.18 tesztelése új "memchr()" változattal 32 bites és 64 bites architektúrákhoz nem tárt fel semmilyen problémát.
Mi történik, ha p nincs 8 (vagy 4 bites célok esetén 32) bájthoz igazítva? Nem minden cél támogatja a nem igazított (hatékony) terheléseket, igaz?
Szerintem működik, ha a p nincs 8 vagy 4 bájtra igazítva. Tegyük fel, hogy a karakterlánc 10 bájt. A for ciklus itt az első 8 bájtot keresi. Ha a célkarakter az utolsó 2 bájtban van, a második for ciklus megtalálja. 32 bites gépeken is így működik.
A teljes teljesítménynövekedést még nem értékelték a kernel alrendszerek közül az optimalizált "memchr()" változat használatakor, és arról sem esett szó, hogy felül kell-e írni a megvalósítást (a memchr() függvényhívás 129 alkalommal fordul elő a kernelkódban, beleértve az illesztőprogramokat és a fájlrendszereket).
Végül Ha érdekel, hogy többet tudjon meg róla, ellenőrizheti a részleteket A következő linken.