0

MPGO (Managed Profile Guided Optimization) に関する投稿を読みましたが、説明されているプロセスは次のとおりです。

  1. Visual Studio 11 Ultimate Beta とアプリケーションがインストールされたマシンを入手します。
  2. 必要なパラメーターを使用して (管理者として) MPGO ツールを実行します。
    MPGO -scenario MyLargeApp.exe -AssembyList *.* -OutDir C:\Optimized\ 最適化された IL アセンブリがC:\Optimizedフォルダーに作成されます。
  3. 各アプリケーション DLL に必要なパラメーターを指定して、NGen ツールを (管理者として) 実行します。 NGEN.exe myLargeApp.exe
  4. アプリケーションを実行します。最適化されたネイティブ イメージが使用されます。

これは、リリースされた製品に入るバイナリでガイド シナリオを実行する必要があることを意味しているようです。

ビルド プロセス中に手動での介入が必要であることは、私には理解できません。ガイド シナリオを 1 回実行してから、生成されたデータをコミットして、将来のビルドでコンパイル済みアセンブリに自動的に挿入されるようにする方法はありますか?

4

1 に答える 1

2

何年も前に、私はマイクロソフトのビルド ラボで働いていました。そこでは、多くのマネージ コードを扱っていました。これは何年も前のことで、マネージド MPGO が公開される前のことです。しかし当時は、古いプロファイル データ (通常は前日から、場合によっては 1 週間前まで) を使用して、一連の内部バイナリを「部分的に最適化」していました。数字で話すことはできませんが、利益がなければ実行しなかったでしょう。これらの「部分的に最適化された」バイナリは、自動煙テストにのみ使用され、内部使用のみでした。完全に最適化されたバイナリ (プロファイル データが同じビルドから収集されたもの) のみがリリースされます。

私は専門家ではありませんが、MPGO ガイダンス データはメソッド シグネチャ (デバッグ シンボルで使用されるものなど) とビルド間で安定しないファイル オフセットを使用していると理解しています。次に問題となるのは、なんらかの利益を得るのに十分安定している割合はどれくらいかということです。

よく使われるメソッドのメソッド名が変わったとしましょう。もちろん、古いバイナリの「ホットな」ページ (その方法のため) は新しいバイナリでは見つからず、頻繁に使用されるページはおそらく最適化されたバイナリの「最後」に配置されます。使用されていないコードで。コインの反対側: 1 つのデイリー ビルドで名前が変更されるメソッドの割合は? (または、CI ではさらに頻繁に発生しますか?) 1% 未満だと思います。

内部ビルドに戻りましょう。もちろん、新しいパフォーマンス プロファイル データの収集にはしばらく時間がかかりました。したがって、完全に最適化されたビルド フレーバーよりも数時間前にビルドが完了するため、時間に敏感な内部関数 (ビルドの直後に実行する必要がある) は、部分的に最適化されたビルド フレーバーを使用して実行されます。 . なぜそんなに時間がかかったのか説明しましょう。IIRC では、コア ライブラリ シナリオが最初に実行され、それらのバイナリが最適化され、最適化されたコアが後の「エンド ツー エンド」シナリオ (つまり、サーバー側 Web サービスまたはクライアント側 GUI) で使用されるプロファイル「パス」を使用しました。シナリオ）。そのため、コア ライブラリのプロファイリングと最適化が何度も行われます。ご想像のとおり、これにはすべて時間がかかります。そのため、「完全に分析/最適化された」ビルドには長い時間がかかりました。

これがお役に立てば幸いです。

PS この質問で32 ビット DLL リベースの問題を思い出しました。

于 2012-06-07T04:57:03.073 に答える