-O3最適化を使用したGNU / Linuxのコンパイル

GNUツールとLinuxカーネルを-O3gcc最適化オプションでコンパイルすると、奇妙で​​ファンキーなバグが発生すると言われています。本当ですか？誰もがそれを試しましたか、それは単なるデマですか？

Gentooで使用されており、異常なものはありませんでした。

-O3 いくつかの欠点があります：

1. まず第一に、-O2またはよりも遅いコードを生成することがよくあります-Os。ループのアンロールが原因で長いコードが生成される場合がありますが、実際にはコードのキャッシュパフォーマンスが低下するために遅くなる場合があります。
2. 言われたように、それは時々間違ったコードを生成します。最適化のエラーまたはコードのエラー（厳密なエイリアスの無視など）が原因である可能性があります。カーネルコードは時々「スマート」である必要があるため、カーネル開発者が何らかのエラーを犯した可能性もあります。その時点で安定していたgcc 4.5でカーネルをコンパイルすると、ユーザースペースユーティリティのクラッシュなど、さまざまな奇妙な問題が発生しました。さまざまなバグのため、カーネルといくつかの選択されたユーザースペースユーティリティにgcc 4.4を使用しています。同じことが適用され-O3ます。
3. Linuxカーネルに大きな利点はないと思います。カーネルは大量の計算を行わず、アセンブリを使用して最適化されます。-O3flagは、コンテキスト切り替えのコストやI / Oの速度を変更しません。全体的なパフォーマンスの<0.1％の高速化は価値があるとは思いません。

最適化レベルを変更すると、ツールチェーンの大部分（特にglibc）が完全にコンパイルされないことに注意してください。ビルドシステムは、ほとんどの健全なディストリビューションでこれらのセクションの-O設定を無視するように設定されています。

簡単に言えば、特定の基本的なライブラリとOSの機能は、多くの場合高速になるものではなく、実際にコードが実行することに依存しています。特に-fgcse-after-reload（-O3で有効化）は奇妙な問題を引き起こす可能性があります。

過去10年間、私は-O3 -march=nativeグローバルに1000以上のパッケージを使用して複数のGentooシステムを実行してきましたが、これらの神話上の安定性の問題にまだ遭遇していません-O3。CPUを集中的に使用するアプリケーション（数学/科学アプリなど）のベンチマークは-O3、より高速なコードを生成することを一貫して示しています。大部分のデスクトップアプリCFLAGSはIOバウンドであるため、とにかくそれほど重要ではありませんが、CPUバウンドであるサーバー側のものにとっては非常に重要です。

-O3は、レジスタの使用、スタックフレームとの相互作用、および関数の再入に関する特定の仮定が真である場合にのみ安全ないくつかの積極的な最適化を使用します。使用（カーネルとそのドライバーモジュールの一部の非常に低レベルの部分にあるように）。

ほとんどのアプリケーションで-O3およびその他の最適化ノブを使用することで回避できますが（速度が向上する可能性があります）、カーネル自体またはそのビルドに必要なツールチェーン（コンパイラ、binutils、等。）。

考えてみてください：raidおよびext3サブシステムの5％のパフォーマンス向上は、システムクラッシュまたは潜在的なデータ損失や破損の価値がありますか？

再生中のQuakeポートまたはDVDコレクションをdivxファイルにリッピングするために使用するオーディオ/ビデオコーデックに必要なすべてのノブを微調整します。おそらく改善が見られます。無駄にする時間がなくて、データを失うのを我慢できない限り、カーネルを混乱させないでください。