0

SPEC ベンチマークで GCC Profile-Guided Optimization のオーバーヘッドをベンチマークしています。いくつかのベンチマークで奇妙な結果が得られました。実際、私のベンチマークのうち 2 つは、インストルメント化するとより高速に実行されます。

通常の実行可能ファイルは次のようにコンパイルされます: -g -O2 -march=native

インストルメント化された実行可能ファイルは、次のようにコンパイルされます: -g -O2 -march=native -fprofile-generate -fno-vpt

GCC 4.7 (正確には Google ブランチ) を使用しています。ベンチマークが実行されているコンピューターには、Intel(R) Xeon(R) CPU E5-2650 0 @ 2.00GHz が搭載されています。

bwaves は Fortran ベンチマークであり、libquantum

結果は次のとおりです。

bwaves-normal: 712.14 
bwaves-instrumented: 697.22 
  => ~2% faster 

libquantum-normal: 463.88
libquantum-instrumented: 449.05
  => ~3.2% faster

ma機の問題かと思いベンチマークを数回実行しましたが、その都度確認しました。

一部のプログラムではオーバーヘッドが非常に小さいことは理解できますが、改善の理由はわかりません。

私の質問は次のとおりです。GCC インストルメント化された実行可能ファイルは、最適化された通常の実行可能ファイルよりも高速にするにはどうすればよいですか?

ありがとう

4

2 に答える 2

1

GCCのドキュメントを見ると、-fprofile-generateプロファイリングを簡単/安価にするために特定のコード変換がアクティブ化されているように見えるため、インストルメントされたコードは実際には元のコード+インストルメンテーションではありません。変更によりコードが高速化される可能性があり、コードを追加するとキャッシュ動作も変更されます。問題のあるコードを見ずに知るのは難しい。そして、私の（ずっと前の）LCCをいじくり回していたことから、プロファイリングがインテリジェントに行われる場合、驚くほど小さなコード変更が必要になります。

好奇心：上記と比較して、プロファイルを考慮してコードをコンパイルするとどうなりますか？

于 2013-01-31T12:41:43.730 に答える
1

2 つの可能性が考えられますが、どちらもキャッシュに関連しています。

1 つは、カウンタのインクリメントがいくつかの重要なキャッシュ ラインを「ウォーム」することです。2 つ目は、インストルメンテーションに必要な構造を追加すると、使用頻度の高い配列や変数が別のキャッシュ ラインに分類されることです。

もう 1 つの問題は、for ループのたびにプロファイリング/カウンターの増加を行う必要がないことです。ループに「ブレーク」または「リターン」がない場合、コンパイラーはループの外でインクリメントを最適化できます。

于 2013-01-31T14:16:17.283 に答える