C文字列ライブラリを直接実装しようとすると、glibcとLinuxカーネルが特定の機能を異なる方法で実装することがわかりました。例えば、glibc メモリロガーそしてglibc 文字列機能を高速化するには、いくつかのトリックを使用してください。kernelmemchrそしてカーネルstrchrいいえ。 Linuxカーネル機能がglibcのように最適化されていないのはなぜですか？
ベストアンサー1
カーネルは、アーキテクチャ固有のディレクトリにこれらの機能のいくつかの最適化されたバージョンを提供します。x86の実装memchr（望むよりすべてのmemchr定義とすべてのstrchr定義）。見つかったバージョンは代替一般バージョンです。と#ifndef __HAVE_ARCH_MEMCHRの保護チェックを見つけてそれを見つけることができます。memchr#ifndef __HAVE_ARCH_STRCHRstrchr
Cライブラリの最適化されたバージョンはより複雑なコードで動作する傾向があるため、上記はカーネルがスピードを上げようとしない理由を説明していません。カーネルがこれらの機能の1つのより最適化されたバージョンから恩恵を受ける可能性があるシナリオを見つけることができれば、パッチが歓迎されると思います（適切なサポート証拠があり、最適化された機能がまだ理解できる限り - 参照）。この古い議論はmemcpy）。しかし、私は通常、カーネルがこれらの関数を使用するのにそれほど価値がないと思います。たとえば、memcpy関連関数はカーネルの小さなバッファで使用される傾向があります。そして、キャッシュに合ったりインライン化したりできる短い関数による速度向上を過小評価しないでください。
さらに、次のように私は存在しません 私は存在しません、MMX と SSE はカーネルでは簡単に使用できません。、メモリ検索またはコピー機能の多くの最適化されたバージョンがこれに依存します。
ほとんどの場合、使用されるバージョンは次のとおりです。コンパイラの組み込みバージョンそれにもかかわらず、それらはCライブラリよりもはるかに最適化されています（たとえば、memcpyレジスタのロードと保存、または定数ストアにしばしば変換されます）。