-O3
GNUツールとLinuxカーネルをコンパイルするためにgcc最適化オプションを使用すると、奇妙なバグが発生すると言われています。これは本当ですか?誰かがこれを試したことがありますか?それともこれは単なる詐欺ですか?
答え1
-O3
いくつかの欠点があります。
- まず、生成されるコードは通常、
-O2
または-Os
。ループのゆるみによってコードが長くなることもありますが、実際にはコードのキャッシング性能が悪く、速度が遅くなることがあります。 - 言ったように、時には間違ったコードが生成されます。これは、最適化エラーやコーディングエラー(厳密なエイリアスを無視するなど)が原因で発生する可能性があります。カーネルコードは時々「スマート」であり、時には「インテリジェント」でなければならないので、いくつかのカーネル開発者が間違いを犯した可能性があります。当時、安定したgcc 4.5を使用してカーネルをコンパイルするとき、ユーザースペースユーティリティの競合など、あらゆる種類の奇妙な問題に直面しました。さまざまなバグのため、私はまだカーネルにgcc 4.4を使用しており、いくつかの選択されたユーザースペースユーティリティを使用しています。同じ状況が適用されます
-O3
。 - 私はそれがLinuxカーネルに多くの利点をもたらすとは思わない。カーネルは過度の計算を実行せず、アセンブリ最適化機能を備えています。
-O3
フラグはいいえコンテキスト切り替えコストまたはI / O速度を変更します。私は0.1%未満の全体的なパフォーマンススピードの向上がそれほど価値があるとは思いません。
答え2
私は過去10年間に-O3 -march=native
世界中で使用されている1000を超えるパッケージを含む複数のGentooシステムを実行してきましたが、まだ-O3
発生しなければならないこれらの神秘的な安定性の問題に直面していません。 CPU集中型アプリケーション(数学/科学アプリケーションなど)のベンチマークは、常により高速なコードを生成できることを示しました-O3
。それ以外の場合は意味がありません。ほとんどのデスクトップアプリケーションではCFLAGS
IOバインディングなので、それほど重要ではありませんが、CPUバインドされたサーバー側のコンテンツでは重要です。
答え3
これはGentooで使用され、珍しい点は見えません。
答え4
-O3 は、レジスタの使用、スタックフレームの対話方法、および関数の再進入に関する特定の仮定が真である場合に限り、安全ないくつかの積極的な最適化を使用します。真、特に使用される場合、インラインアセンブリでは(カーネルとそのドライバモジュールの非常に低いレベルの部分にあるため)