アプリケーションのハードウェアの問題を判定するため、全般解析のマイクロアーキテクチャー解析を使用します。
コードのホットスポットを特定するのに基本ホットスポットや高度なホットスポット解析を行った後、コードがパイプライン中をどれくらい効率良く通過しているか理解するため全般解析を実行できます。全般解析の実行中に、インテル® VTune™ Amplifier は一般的なクライアント・アプリケーションの解析に必要なすべてのイベントを収集し、メトリックに使用される定義済み比率の計算を行い、次のようなハードウェア問題の特定を可能にします。
![全般解析ビューポイント: [Bottom-up] ウィンドウ](GUID-C1139DE7-0EAC-453D-9890-8F4BAD33841A-low.gif)
全般解析を行うには次を確認します。
全般解析の方針
全般解析の方針はマイクロアーキテクチャーによって異なります。インテル® マイクロアーキテクチャー開発コード名 Ivy Bridge 以降の現代のマイクロアーキテクチャーでは、全般解析はアプリケーションの主なパフォーマンス・ボトルネックを特定するため、階層構成のイベントベースのメトリックによるトップダウン特性方法論を使用したトップダウンのマイクロアーキテクチャー解析方式に基づいています。
スーパースカラー・プロセッサーは、概念的にフロントエンド (命令をフェッチし、操作を行うためデコード) とバックエンド (計算を実行) で構成されます。各サイクルで、フロントエンドは最大 4 つの操作を生成し、これらはバックエンドを通過するパイプライン・スロットに送出されます。そのため、クロックサイクルにおける特定の実行期間において、その期間中にリタイアできる実質的なワークを含むパイプライン・スロットの最大数を推定するのは容易です。実質的なワークを含むリタイアしたパイプライン・スロットの数は、この最大数とほぼ等しくなります。これにはいくつかの要因が関連します。いくつかのパイプライン・スロットには、フロントエンドが時間内に命令をフェッチまたはデコードできない (フロントエンド依存の実行)、もしくはバックエンドが特定の操作を受け入れる準備ができていない (バックエンド依存の実行) ことが原因で実質的なワークが含まれないことがあります。さらに、実質的なワークを含むパイプライン・スロットが、投機の問題によりリタイアしないこともあります。フロントエンド依存の実行は、大きなコードのワーキングセット、問題のあるコード配置、またはマイクロコード・アシストが原因であることが考えられます。また、バックエンド依存の実行は、長いレイテンシーの操作や実行リソースの競合などで発生します。投機の問題の多くは分岐予測ミスが原因です。
それぞれのサイクルとコアは、最大 4 つのパイプライン・スロットを実質的な操作で埋めることができます。したがって、時間間隔で埋められそして発行されるパイプライン・スロットの最大数を推測することができます。この解析では、パイプライン・スロットを 4 つのカテゴリーに分類して推測を行います。
発行されリタイアした実質的なワークを含むパイプライン・スロット (リタイア)
発行されキャンセルされた実質的なワークを含むパイプライン・スロット (投機の問題)
フロントエンドの問題により、実質的なワークを送出できなかったパイプライン・スロット (フロントエンド依存)
バックエンドの問題により、実質的なワークを受け入れることができなかったパイプライン・スロット (バックエンド依存)
全般解析を使用するには、最初にどの上位レベルのカテゴリーのホットスポットに注目するか決定します。行を拡張表示することで、そのカテゴリー下のレベルを調査でき、そのカテゴリーに属する多くの問題を発見できます。
インテル® VTune™ Amplifier のトップダウン方法論でカバーされない他のマイクロアーキテクチャー上で、全般解析を実行することもできます。
インテル® マイクロアーキテクチャー開発コード名 Sandy Bridge: このマイクロアーキテクチャーは、すでにトップダウン方法論に部分的に適応しており、インテル® VTune™ Amplifier は次のカテゴリーをベースとしたハードウェア・メトリックの階層的な解析を提供しています: 埋められたパイプライン・スロットと埋められていないパイプライン・スロット (ストール)
インテル® マイクロアーキテクチャー開発コード名 Nehalem と開発コード名 Westmere: これらのマイクロアーキテクチャー上での全般解析において、インテル® VTune™ Amplifier は次のようなハードウェア・レベルのパフォーマンスの問題を特定するのに有用なメトリックを収集します。
フロントエンド・ストールとその原因
実行時とリタイア時のストール: 特にレイテンシーの高い各種ロード、分岐予測ミスによる実用価値のない処理、またはレイテンシーの長い命令によるストール。
注
全般解析の背後にあるチューニング方法論の詳細と、この解析に関連する複雑性については、「インテル® VTune™ Amplifier の全般解析がどのように動作するかを理解する」 (英語) をご覧ください。
アーキテクチャー固有のチューニング・ガイドについては、https://www.isus.jp/products/vtune/processor-specific-performance-analysis-papers/ をご覧ください。
設定オプション
全般解析向けのオプションを設定するには、次の操作を行います。
必要条件: プロジェクトを作成し、解析ターゲットを指定します。
インテル® VTune™ Amplifier ツールバーの
(スタンドアロン GUI)/
(Visual Studio* IDE) [New Analysis (新規解析)] ボタンします。[Analysis Type (解析タイプ)] ウィンドウをアクティブにして、[New Amplifier Result (新規 Amplifier 結果)] タブを開きます。
左にあるペインの解析ツリーから、[Microarchitecture Analysis (マイクロアーキテクチャー解析)] > [General Exploration (全般解析)] を選択します。
右側に [Analysis Configuration (解析オプション)] ペインが開きます。
注
特定のマイクロアーキテクチャー上で収集される全般解析向けのイベントについては、「インテル® プロセッサー・イベント・リファレンス」 (英語) を参照してください。
解析オプションを設定します。
[Analyze memory bandwidth (メモリー帯域幅を解析)] チェックボックス
メモリー帯域幅の計算に必要なデータを収集します。
デフォルト値は、[false] です。
[Evaluate max DRAM bandwidth (最大 DRAM 帯域幅を評価)] チェックボックス
収集を開始する前に、達成可能な最大ローカル DRAM 帯域幅を評価します。このデータは、タイムラインで帯域幅メトリックのスケールしきい値を計算するために使用されます。
デフォルト値は、[true] です。
[Analyze OpenMP regions (OpenMP* 領域を解析)] チェックボックス
OpenMP* 領域をインストルメントおよび解析し、インバランス、ロックの競合、またはスケジュール、リダクション、およびアトミック操作におけるオーバーヘッドなど非効率な振る舞いを特定します。
デフォルト値は、[false] です。
[Analyze user tasks, events, and counters (ユーザータスク、イベント、カウンターを解析)]チェックボックス
ITT API を使用してコード中で指定したタスク、イベント、およびカウンターを解析します。このオプションを指定すると、高いオーバーヘッドが生じ、結果ファイルのサイズが増加します。
デフォルト値は、[false] です。
[Details (詳細)] ボタン
この解析タイプで使用されるデフォルト設定 (編集不可) のリストを展開/折りたたみます。解析向けの追加設定を修正または有効にする場合、既存の事前定義設定をコピーしてカスタム設定を作成する必要があります。この解析タイプ設定の編集可能なコピーが作成され、解析ツリーの [Custom Analysis (カスタム解析)] に追加されます。
解析を実行するには、[Start (開始)] をクリックします。
注
下にある [Command Line... (コマンドライン...)] ボタンをクリックして、この設定のコマンドラインを生成できます。
ビューポイント
全般解析結果は、次のビューポイントで表示できます。
ビューポイント |
説明 |
|---|---|
General Exploration (全般解析) |
アプリケーションで利用可能なハードウェア・リソースを活用していない場所を特定するのに役立ちます。このビューポイントは、ハードウェア・イベントから得られるメトリックを表示します。[Summary (サマリー)] ウィンドウは、メトリックの説明と実行全体におけるトータルなメトリックをレポートします。[Bottom-up (ボトムアップ)] と [Top-down Tree (トップダウン・ツリー)] ウィンドウで、アプリケーション内のハードウェアの問題が発生する場所を特定できます。パフォーマンス向上の可能性が検出されると、セルはハイライト表示されます。グリッドのハイライトされているメトリックにカーソルをホバーすると、問題の説明が表示されます。 |
Hardware Events (ハードウェア・イベント) |
モニターされたハードウェア・イベントの特性を表示: 予測されるカウントおよび (または) 収集されたサンプル数。このビューを使用して、注目するイベントの最も高いアクティビティーのコード領域 (モジュール、関数、コード行など) を特定します。 |
Hardware Issues (ハードウェアの問題) |
アプリケーションで利用可能なハードウェア・リソースを活用していない場所を特定するのに役立ちます。このビューポイントは、ハードウェア・パフォーマンス・カウンターから得られるメトリックを表示します。グリッドにハイライト表示されたメトリック値にマウスをホバーすると、そのメトリックがパフォーマンスの問題を引き起こす理由が表示されます。 |
Hotspots (ホットスポット) |
多くの CPU 時間を使用しているコード領域 (ホットスポット) を特定するのに役立ちます。 |
Memory Usage (メモリー使用量) |
アプリケーションがメモリーリソースを効率良く使用しているか理解するのを支援し、過度な NUMA プラットフォーム上のリモートへのアクセス、DRAM へのヒット、またはインターコネクトの帯域幅制限などメモリーアクセスに関連する問題の可能性を特定します。アプリケーション・コードとメモリー・オブジェクト配列の両方に関連する各種パフォーマンス・メトリックを提供します。 |
これらのビューポイントには次のウィンドウが含まれます。
[Summary] ウィンドウ: アプリケーションの実行の全体的な統計を表示します。
[Bottom-up] ペイン: ホットスポット関数ごとにパフォーマンス・メトリック・データ (イベント比率/イベントカウント/サンプルカウント) を表示します。
[Top-down Tree] ウィンドウ: ホットスポット関数 (呼び出しツリー形式)、関数のみのパフォーマンス・メトリック (セルフ値)、関数とその子関数のメトリック (合計値) を表示します。
[Caller/Callee (呼び出し元/呼び出し先)] ウィンドウ: 選択された関数の親と子関数を表示します。このウィンドウは、解析設定でスタック収集が有効にされている場合にのみ表示されます。
[Event Count (イベントカウント)] ウィンドウ: 選択された解析の PMU イベント数を表示します。
[Sample Count (サンプルカウント)] ウィンドウ: イベントが収集された実際のサンプル数を示します。
[Uncore Event Count (アンコア・イベント・カウント)] ウィンドウ: 選択された解析のアンコアイベント数を表示します。アンコアイベントがカウントされなかった場合、ウィンドウの上部のペインは空になります。
[Platform (プラットフォーム)] ウィンドウ: コード中のタスク API、Ftrace*/Systrace* イベントタスク、OpenCL* API タスクなどで指定されるタスクの詳細を提供します。対応するプラットフォームのメトリックが収集されると、[Platform] ウィンドウは、ソフトウェア・シーケンス上の GPU 使用、CPU 時間使用、OpenCL* カーネルデータ、および GPU ハードウェア・メトリックの概要グループごとの GPU パフォーマンスと CPU 周波数などを、時間経過におけるデータとして表示します。