最近 Linuxカーネルの提案がリリースされました、パッチのセットを含めることが提案されています memchr（）関数の最適化された実装 配列内の文字を検索するために使用されます。
memchr（）関数は、sが指すメモリ領域の先頭のnバイトをスキャンして、cの最初のインスタンスを探します。 cとsが指すメモリ領域のバイトは、どちらも符号なし文字として解釈されます。
提案 約束 より速くなる メモリのブロック内の文字を見つけるため。 開発者テストでは、新しい実装は大規模な検索でほぼXNUMX倍高速になる可能性があります
バイトごとの比較を使用していた以前のバージョンとは異なり、、提案された実装は、64ビットおよび32ビットのCPUレジスタをフルに使用することを考慮して作成されています。 バイトの代わりに、マシンワードを使用して比較が行われます。これにより、一度に少なくとも4バイトを比較できます。
この一連のパッチは「memchr（）」を最適化し、
「memchr_inv（）」。両方の関数がそれを使用してビットマスクを生成できるようにします。「memchr（）」の元の実装は、バイト比較に基づいています。
これは、CPUの64ビットまたは32ビットレジスタを完全には使用しません。 実装します
少なくとも4バイトを同じものと比較できるようにするための単語による比較
天気。 最適化されたmemchr（）は、元のmemchr（）のほぼ4倍高速です
ロングチェーン用。 Linuxカーネルでは、文字列の長さが
「memchr（）」で検索されるのは、drivers / misc / lkdtm/heap.cで最大512バイトです。
大きな文字列を検索する場合、 新しいバージョンは、古いバージョンよりも約4倍高速であることが判明しました （たとえば、1000文字の文字列の場合）。 小さなチェーンの場合、新しい実装の効率はそれほど重要ではありませんが、それでも元のバージョンよりも高くなります。
新しい提案の興味深い点は、時間を大幅に改善する大規模チェーンの改善です。 Linuxカーネルでは、 memchr（）で処理される文字列のサイズは512バイトに達します。 私たちのテストでは、検索文字が使用されている状況で、512バイトの文字列のパフォーマンスが向上しました 文字列の最後にある場合は20％です。
memchr（）の元のバージョンは、64ビットまたは32ビットCPUのレジスタを完全には使用しないバイト単位の比較手法で実装されていることに注意してください。
CPU上で同時に8文字を比較できるように、単語全体の比較を使用します。 このコードは、DavidLightの実装に基づいています。
最初のファイルのパフォーマンスを測定するためにXNUMXつのファイルを作成します これには、宛先文字の平均10文字前が含まれています。 1000番目のファイルには、前に少なくともXNUMX文字が含まれています ターゲットキャラクター。
「memchr（）」の実装はわずかです 最初のテストでより良く、元のテストよりもほぼ4倍高速です XNUMX番目のテストでの実装。
5.18ビットおよび32ビットアーキテクチャ用の新しい「memchr（）」バリアントを使用したカーネル64テスト 問題はありませんでした。
pが8（または4ビットターゲットでは32）バイトアラインされていない場合はどうなりますか？ すべてのターゲットが非整列（効率的な）負荷をサポートしているわけではありませんよね？
pが8バイトまたは4バイトに整列されていない場合は機能すると思います。 文字列が10バイトだとしましょう。 ここでのforループは、最初の8バイトを探します。 宛先文字が最後の2バイトにある場合、32番目のforループがそれを検出します。 XNUMXビットマシンでもこのように機能します。
全体的なパフォーマンスの向上はまだ評価されていません 最適化された「memchr（）」バリアントを使用する場合のカーネルサブシステムの例も、実装をオーバーライドするかどうかについても説明されていません（memchr（）関数呼び出しは、ドライバーとファイルシステムを含むカーネルコードで129回発生します）。
最後に あなたがそれについてもっと知りたいのなら、 詳細を確認できます 次のリンクで.