Keiichi Oono's Weblog

より具体的に見ていくために以下の例を使います (foo.c というプログラムをコンパイルして foo という実行ファイルを作成することを想定しています)

 1  $ cc -xtarget=native -xprofile=collect:foo foo.c -o foo
 2  $ ./foo 123
 3  $ ./foo 456
 4  $ rm foo
 5  $ cc -xtarget=native -xprofile=use:foo foo.c -o foo

1 行目のコンパイルで、foo という実行可能ファイルは最適化のためのプロファイルデータを収集するプログラムとして生成されます。

2 行目と 3 行目の実行により、実行ディレクトリに foo.profile というサブディレクトリが生成され、ここにプロファイルデータが蓄積されます。このディレクトリ名はオプションの指定のしかたによって変わります。例えば -xprofile=collect:/tmp/bar と指定したら /tmp/bar.profile というサブディレクトリに集められます。プログラムに与える引数によって内部での分岐先が異なるような場合には、異なる引数を与えて複数回実行させます。ただ、ここで与える引数はあくまでも実際の動作により近い典型的な入力値であり、頻度が非常に少ないのであれば上限値や下限値を与える必要はありませんし、すべての分岐を実行させる必要もありません。

4 行目で再コンパイルのために一旦実行ファイルを削除します。実際にはこの部分は make clean によって行われることが多いのではないかと思います。

5 行目で最終的な実行ファイル foo を生成させます。この foo は実行時のプロファイルデータの情報による最適化が行われたものとなります。

姫野ベンチを実行した時には、-xprofile=collect:bmt を指定してコンパイルし実行させた後に -xprofile=use:bmt を指定して再コンパイルを行ったところ、再コンパイルされた実行可能ファイルのパフォーマンスの向上は約 1 - 2 % でした。あまり大きな効果は出ていません。何度か計測した中では -xprofile オプションの指定によってパフォーマンスが低下した計測値も出ています。姫野ベンチのプログラムではソースコードの解析に基づく最適化に実行時のプロファイルデータを加味しても、最適化そのものに大きな変更は加えられなかった。別の言い方をすれば、実行時プロファイルデータによる最適化はあまり (もしかしたらほとんど) 行われなかった。ということだと思います。analyzer(1) を使って逆アセンブリの結果を見てみましたが、処理の流れに違いは見られませんでした。データ配置にはもしかしたら変更が加えられたかもしれません。

姫野ベンチの場合には実行時プロファイルデータによる効果はさほど現れませんでしたが、プログラム内部の処理の流れによっては、-xprofile を使用した実行時プロファイルデータの使用によって効果的な最適化が行われ、最終的なパフォーマンスの向上に効果を及ぼす場合があると思っています。以前、最新 CPU アーキテクチャへの対応についてのエントリで参考資料として挙げたインテルや AMD の最適化に関する説明内にも「もっとも積極的な (most aggressive)」最適化オプションの一部として -xprofile オプションが使用されています。

 
Posted by keiichio ( 3月 17日 2008年, 03:41:07 午後 JST ) Permalink 投稿されたコメント [0]