1

I-32A アーキテクチャー用のインテル C コンパイラーを使用しています。次のオプションを使用して C プログラムをコンパイルすると、次のようになります。

icl mytest.c /openmp /QxHost /fp:fast /fast

テスト実行には 3.3 秒かかります。今、私は PGO を使用しようとしたので、次のようにコンパイルしました:

icl mytest.c /openmp /QxHost /fp:fast /fast /Qprof-gen

次に、サンプル入力を使用して実行可能ファイルを 2 ～ 3 回実行し、次のコマンドで再度コンパイルします。

icl mytest.c /openmp /QxHost /fp:fast /fast /Qprof-use

収集された情報が考慮されることを願っています。実際、.dyn ファイルを使用していることがわかりますが、結果の実行可能ファイルは Qprof を使用しない場合よりも遅くなり (3.85 秒)、これは実行が実行されたのとまったく同じデータ上にあります (PGO に最適なはずです)。.dyn 出力を混乱させる可能性があると考えて、openmp スレッドを 1 に設定しようとしましたが、結果は同じです。単純なコンパイルよりも遅いです。

私の質問は次のとおりです。それは理論的にも可能ですか、それともコンパイラオプションで PGO プロセスを台無しにしていますか?

4

1 に答える 1

1

3.3 秒の浮動小数点アプリケーションは、プロファイルに基づく最適化の恩恵を受けません。私の推測では、PGO よりも生の FLOP が必要な場合は、何らかの生データのクランチングを行っています。

PGO は、内部ループを最適化して分岐遅延を除去し、パイプラインをフルに保つ方法をコンパイラに指示しません。ループが 5,000 回しか実行されない可能性が高いかどうか、またはフロートがいくつかの基準を満たしているかどうかがわかります。

実行したい他のデータを統計的に代表するデータで使用されます。言い換えれば、良いクリップで他のデータを実行できるようにしたいプログラムのデータで使用します。手元のプログラムに合わせて必ずしも最適化するとは限りません。

それは本当にあなたのプログラムに依存しますが、OpenMP FP アプリは PGO の目的ではありません。他のすべてと同様に、それは「魔法の弾丸」ではありません。

于 2012-07-21T16:04:28.377 に答える