Недавно објављен је предлог за Линук кернел, у који се предлаже да се укључи сет закрпа са а оптимизована имплементација функције мемцхр(). користи се за тражење карактера у низу.
Функција мемцхр() скенира водећих н бајтова меморијске области на коју указује с за прву инстанцу ц. И ц и бајтови у области меморије на коју указује с се тумаче као непотписани знакови.
Предлог обећава буди бржи да бисте лоцирали карактер унутар блока меморије. У тестовима за програмере, нова имплементација може бити скоро четири пута бржа при великим претрагама
За разлику од претходне верзије, која је користила поређење бајт по бајт, предложена имплементација је креирана узимајући у обзир пуну употребу 64-битних и 32-битних ЦПУ регистара. Уместо бајтова, поређење се врши помоћу машинских речи, што омогућава да се упореде најмање 4 бајта истовремено.
Ова серија закрпа је оптимизовала „мемцхр()“ и додала макро за
"мемцхр_инв()" тако да обе функције могу да га користе за генерисање битмаске.Оригинална имплементација „мемцхр()“ заснована је на поређењу бајтова,
који не користи у потпуности 64 или 32-битни регистар у ЦПУ-у. Ми имплементирамо а
поређење речима тако да се најмање 4 бајта могу упоредити са истим
временске прилике. Оптимизовани мемцхр() је скоро 4 пута бржи од оригинала
за дуге ланце. У Линук кернелу налазимо да је дужина стринга
тражи "мемцхр()" је до 512 бајтова у дриверс/мисц/лкдтм/хеап.ц.
Када тражите велике низове, испоставило се да је нова верзија око 4 пута бржа од старе (на пример, за низове од 1000 знакова). За мале ланце, ефикасност нове имплементације није толико значајна, али је и даље већа од оригиналне верзије.
Занимљивост новог предлога је побољшање за велике ланце, што знатно побољшава време. Вреди напоменути да у Линук кернелу, величина стрингова обрађених у мемцхр() достиже 512 бајтова. У нашим тестовима, повећање перформанси за стрингове од 512 бајта, у ситуацији када се тражи карактер је на крају низа, то је 20%.
Вреди напоменути да је оригинална верзија мемцхр() имплементирана техником поређења по бајтовима, која не користи у потпуности регистре на 64-битном или 32-битном ЦПУ-у.
Користимо поређење целе речи тако да се 8 карактера може упоредити истовремено на ЦПУ-у. Овај код је заснован на имплементацији Дејвида Лајта.
Правимо две датотеке за мерење перформанси прве датотеке који у просеку садржи 10 знакова испред одредишног карактера. Друга датотека садржи најмање 1000 знакова пре циљни карактер.
Наша имплементација "мемцхр()" је незнатна бољи на првом тесту и скоро 4 пута бржи од оригинала имплементација у другом тесту.
Тестирање кернела 5.18 са новом "мемцхр()" варијантом за 32-битне и 64-битне архитектуре није открио никакве проблеме.
Шта се дешава ако п није поравнат са 8 (или 4 на 32-битним циљевима) бајтова? Не подржавају све мете неусклађена (ефикасна) оптерећења, зар не?
Мислим да ради ако п није поравнат од 8 или 4 бајта. Рецимо да је стринг 10 бајтова. Петља фор овде ће тражити првих 8 бајтова. Ако је одредишни знак у последња 2 бајта, друга фор петља ће га пронаћи. Такође ради овако на 32-битним машинама.
Укупан добитак учинка још није процењен подсистема кернела када се користи оптимизована варијанта „мемцхр()“, нити се расправљало о томе да ли да се замени имплементација (позив функције мемцхр() се јавља 129 пута у коду кернела, укључујући драјвере и системе датотека).
Коначно Ако сте заинтересовани да сазнате више о томе, можете проверити детаље У следећем линку.