наскоро беше пуснато предложение за ядрото на Linux, в който се предлага да се включи набор от пачове с a оптимизирана реализация на функцията memchr(). използва се за търсене на знак в масив.
Функцията memchr() сканира водещите n байта от областта на паметта, посочена от s, за първото копие на c. Както c, така и байтовете в областта на паметта, към която сочи s, се интерпретират като символи без знак.
Предложението обещания бъдете по-бързи за намиране на символ в блок от паметта. В тестовете за разработчици новото внедряване може да бъде почти четири пъти по-бързо при големи търсения
За разлика от предишната версия, която използва сравнение байт по байт, предложената реализация е създадена, като се има предвид пълното използване на 64-битови и 32-битови регистри на процесора. Вместо байтове, сравнението се извършва с помощта на машинни думи, което позволява да се сравняват поне 4 байта наведнъж.
Тази поредица от пачове оптимизира "memchr()" и добави макрос за
"memchr_inv()", така че и двете функции да могат да го използват за генериране на битова маска.Оригиналното изпълнение на "memchr()" се основава на сравнение на байтове,
който не използва напълно 64 или 32 битовия регистър в процесора. Ние прилагаме a
сравнение по думи, така че поне 4 байта да могат да бъдат сравнени със същото
метеорологично време. Оптимизираният memchr() е почти 4 пъти по-бърз от оригинала
за дълги вериги. В ядрото на Linux откриваме, че дължината на низа
търсен от "memchr()" е до 512 байта в drivers/misc/lkdtm/heap.c.
Когато търсите в големи низове, новата версия се оказа около 4 пъти по-бърза от старата (например за низове от 1000 знака). За малките вериги ефективността на новото внедряване не е толкова значителна, но все пак е по-висока от оригиналната версия.
Интересното в новото предложение е подобрението за големите вериги, което значително подобрява времето. Струва си да се спомене, че в ядрото на Linux, размерът на низовете, обработвани в memchr() достига 512 байта. В нашите тестове увеличението на производителността за 512-байтови низове, в ситуация, в която символът за търсене е в края на низа, той е 20%.
Струва си да се спомене, че оригиналната версия на memchr() е реализирана с техниката за байтово сравнение, която не използва напълно регистрите на 64-битовия или 32-битовия процесор.
Ние използваме сравнение на цели думи, така че 8 знака да могат да бъдат сравнени едновременно на процесора. Този код е базиран на изпълнението на David Light.
Създаваме два файла, за да измерим производителността на първия файл който съдържа средно 10 знака пред целевия знак. Вторият файл съдържа поне 1000 знака преди целеви характер.
Нашата реализация на "memchr()" е леко по-добър при първия тест и почти 4 пъти по-бърз от оригинала изпълнение във втория тест.
Тестване на ядрото 5.18 с нов вариант "memchr()" за 32-битови и 64-битови архитектури не разкри никакви проблеми.
Какво се случва, ако p не е 8 (или 4 при 32-битови цели) подравнен байт? Не всички цели поддържат несъгласувани (ефективни) натоварвания, нали?
Мисля, че работи, ако p не е подравнен с 8 или 4 байта. Да приемем, че низът е 10 байта. Цикълът for тук ще търси първите 8 байта. Ако целевият знак е в последните 2 байта, вторият for цикъл ще го намери. Също така работи по този начин на 32-битови машини.
Общото увеличение на производителността все още не е оценено на подсистемите на ядрото при използване на оптимизирания вариант "memchr()", нито е обсъждано дали да се отмени изпълнението (извикването на функцията memchr() се среща 129 пъти в кода на ядрото, включително драйвери и файлови системи).
Накрая Ако се интересувате да научите повече за това, можете да проверите подробностите В следващия линк.