私は多くの人々が-O3
オプションについて不平を言っているのを見てきました:
GCCのマニュアルを確認します。
-O3 Optimize yet more. -O3 turns on all optimizations specified by -O2 and also turns on the -finline-functions and -frename-registers options.
また、コードを確認して、2つのオプションが-O3
onに含まれる2つの最適化のみであることを確認しました。
if (optimize >= 3){
flag_inline_functions = 1;
flag_rename_registers = 1;
}
これら2つの最適化の場合:
-finline-functions
-finline-limitを使用してインライン関数のサイズ(デフォルトでは600)を定義できるため、場合によっては(主にC ++で)便利です。高いインライン制限を設定すると、コンパイラはメモリ不足を訴えるエラーを報告する場合があります。-frename-registers
レジスタ割り当て後に残ったレジスタを利用することにより、スケジュールされたコードの誤った依存関係を回避しようとします。この最適化は、多くのレジスタを備えたプロセッサに最も役立ちます。
インライン関数の場合、関数呼び出しの数を減らすことはできますが、バイナリファイルが大きくなる可能性があるため、-finline-functions
深刻なキャッシュペナルティが発生し、-O2よりもさらに遅くなる可能性があります。キャッシュのペナルティは、プログラム自体に依存するだけではないと思います。
名前変更レジスタについては、x86のようなciscアーキテクチャにプラスの影響はないと思います。
私の質問には2.5の部分があります:
プログラムが-O3オプションでより速く実行できるかどうかは、基盤となるプラットフォーム/アーキテクチャに依存すると主張する権利はありますか?[回答済み]
編集:
最初の部分は真であることが確認されています。David Hammenはまた、IntelやAMDのような拡張精度の浮動小数点レジスタを備えたマシンで最適化と浮動小数点演算がどのように相互作用するかについて非常に注意する必要があると主張しています。
-O3
オプションを自信を持って使用できるのはいつですか?これらの2つの最適化、特に名前変更レジスタは、-O0/O2とは異なる動作を引き起こす可能性があると思います。コンパイルされたいくつかのプログラムが-O3
実行中にクラッシュするのを見ましたが、それは決定論的ですか?実行可能ファイルをクラッシュせずに1回実行した場合、それは安全に使用できることを意味します-O3
か?編集:決定論は最適化とは何の関係もありません、それはマルチスレッドの問題です。ただし、マルチスレッドプログラムの
-O3
場合、実行可能ファイルをエラーなしで1回実行すると、安全に使用できません。David Hammenは、-O3
浮動小数点演算の最適化が、比較のための厳密な弱順序基準に違反する可能性があることを示しています。オプションを使用したいときに注意が必要な他の懸念事項はあり-O3
ますか?最初の質問の答えが「はい」の場合、ターゲットプラットフォームを変更するとき、または異なるマシンを使用する分散システムで、との間で変更する必要がある場合があり
-O3
ます-O2
。でパフォーマンスを改善できるかどうかを判断する一般的な方法はあります-O3
か?たとえば、より多くのレジスタ、短いインライン関数など。[回答済み]編集:3番目の部分はLouenによって「プラットフォームの多様性により、この問題に関する一般的な推論が不可能になる」と回答されています。によるパフォーマンスの向上を評価するときは
-O3
、両方で試して、コードをベンチマークしてどちらが速いかを確認する必要があります。