-O3最適化を使用したGNU / Linuxのコンパイル
GNUツールとLinuxカーネルを-O3 gcc最適化オプションを使用してコンパイルすると、奇妙でファンキーなバグが生成されると言われています。
Gentooで使用されており、異常なことに気づきませんでした。
-O3にはいくつかの欠点があります。
- まず第一に、それはしばしば
-O2または-Osより遅いコードを生成します。ループのアンロールが原因でコードが長くなる場合がありますが、コードのキャッシュパフォーマンスが悪いため、実際には遅くなる可能性があります。 - 言われたように、それは時々間違ったコードを生成します。最適化のエラーまたはコードのエラー（厳密なエイリアスを無視するなど）が原因である可能性があります。カーネルコードは時々「スマート」である必要があるため、カーネル開発者がエラーを犯した可能性があります。その時点で安定していたgcc 4.5でカーネルをコンパイルしたとき、ユーザースペースユーティリティのクラッシュなど、さまざまな奇妙な問題が発生しました。さまざまなバグのため、カーネルと選択したいくつかのユーザースペースユーティリティにまだgcc 4.4を使用しています。同じことが
-O3にも当てはまります。 - Linuxカーネルに多くのメリットをもたらすとは思いません。カーネルは重い計算を行わず、場所によってはアセンブリで最適化されます。
-O3フラグはnotコンテキスト切り替えのコストまたはI/Oの速度を変更します。全体的なパフォーマンスの0.1％未満の高速化のようなものはそれだけの価値があるとは思いません。
ツールチェーン（特にglibc）の大きなチャンクは、最適化レベルを変更してもコンパイルされないことに注意してください。ビルドシステムは、ほとんどの正常なディストリビューションでこれらのセクションの-O設定を無視するように設定されています。
簡単に言えば、特定の基本的なライブラリとOSの機能は、多くの場合より高速になるものではなく、実際にコードが実行するコードに依存します。特に-fgcse-after-reload（-O3によって有効化）は、奇妙な問題を引き起こす可能性があります。
過去10年間、私は-O3 -march=nativeをグローバルに使用して1000以上のパッケージを持つ複数のGentooシステムを実行してきましたが、-O3が持っているはずのこれらの神秘的な安定性の問題にはまだ遭遇していません。 CPUを集中的に使用するアプリケーション（数学/科学アプリなど）のベンチマークは常に-O3を示し、より高速なコードを生成します。デスクトップアプリケーションの大部分では、CFLAGSはIOバインドされているため、とにかくそれほど重要ではありませんが、CPUバインドされているサーバー側のものにとっては重要です。
-O3は、レジスタの使用に関する特定の仮定、スタックフレームの相互作用方法、および関数の再入可能性がtrueの場合にのみ安全であるいくつかの積極的な最適化を使用します。これらの仮定は、特にインラインアセンブリーの場合、カーネルなどの一部のコードでtrueであることが保証されていません。使用されます（カーネルおよびそのドライバモジュールの一部の非常に低レベルの部分にあるため）。
ほとんどのアプリケーションで-O3やその他の最適化ノブを使用することで問題を回避できます（そしてcan結果は速度が向上します）カーネル自体または必要なツールチェーンでそのような微調整を使用することをためらいますビルド（コンパイラ、binutilsなど）。
それについて考えてください：raidおよびext3サブシステムの5％のパフォーマンス向上は、システムクラッシュまたは潜在的なデータの損失や破損に値しますか？
再生しているQuakeポートに必要なすべてのノブ、またはDVDコレクションをdivxファイルにリッピングするために使用するオーディオ/ビデオコーデックを微調整します。おそらく改善が見られます。無駄にする時間と失うことができるデータがない限り、カーネルを台無しにしないでください。