インテル® VTune™ プロファイラー
パフォーマンス解析クックブック
2020 年 6 月 8 日
インテル® VTune™ プロファイラー は、開発者がコードを解析し、非効率なアルゴリズムおよびハードウェアの利用状況を特定して、適切なパフォーマンス・チューニングのアドバイスを得られるように支援する、パフォー
マンス・プロファイル・ツールです。
注•••インテル® VTune™ プロファイラー評価版のダウンロードと製品サポートについては、
https://www.isus.jp/intel-vtune-amplifier-xe/ を参照してください。
このクックブックのレシピはすべてスケーラブルであり、インテル® VTune™ Amplifier 2018 以降に適用できます。バージョンにより設定がわずかに異なることがあります。
ベータ版インテル® oneAPI ベース・ツールキット向けのバージョンから、インテル® VTune™
Amplifier の名称がインテル® VTune™ プロファイラーに変わりました。引き続き、インテル® Parallel
Studio XE またはインテル® System Studio のコンポーネントとして、あるいはスタンドアロン版のインテル® VTune™ プロファイラーをご利用いただけます。

このクックブックは、インテル® VTune™ プロファイラーで提供される解析タイプを使用して、パフォーマンス
の手法とレシピを紹介します。
•

•

•

•

手法
最初に、チューニング手法、パフォーマンス・メトリック、統計を収集するハードウェア・ソリューション
を理解して、パフォーマンス解析を開始します。その後、ベータ版インテル® VTune™ プロファイラーと従来のインテル® VTune™ Amplifier で利用可能な特定のチューニングや設定レシピにドリルダウン
できます。
設定レシピ
特定のコード環境でパフォーマンス解析を行うため、システムとベータ版インテル® VTune™ プロファ
イラーと従来のインテル® VTune™ Amplifier を設定する方法を詳しく説明します。
チューニング・レシピ
ベータ版インテル® VTune™ プロファイラーと従来のインテル® VTune™ Amplifier で検出可能な最も一般的なパフォーマンスの問題を調査し、パフォーマンスを最適化するためのステップを提供します。
法務上の注意書き手法
最初に、チューニング手法、パフォーマンス・メトリック、統計を収集するハードウェア・ソリューションを理解して、パフォーマンス解析を開始します。その後、ベータ版インテル® VTune™ プロファイラーと従来のインテル®
VTune™ Amplifier で利用可能な特定のチューニングや設定レシピにドリルダウンできます。
•

•

•

•

トップダウン・マイクロアーキテクチャー解析法
アプリケーションが利用可能なハードウェア・リソースをどのように使用しているかを把握し、CPU マ
イクロアーキテクチャーの利点を活用できるようにします。この情報を得る 1 つの手段として、オン
チップのパフォーマンス・モニタリング・ユニット (PMU) を使用する方法があります。
OpenMP* コード解析
OpenMP* または OpenMP* - MPI ハイブリッド・アプリケーションの CPU 利用率を解析して、潜在的な非効率性の原因を特定します。
DPDK アプリケーションのコア使用率
このレシピは、DPDK ベースのアプリケーションにおけるパケット受信のコア使用率を特徴付けるメ
トリックを調査します。
DPDK アプリケーションの PCIe* トラフィック
インテル® VTune™ Amplifier の PCIe* 帯域幅メトリックを使用して、パケット・フォワーディングを行う DPDK ベースのアプリケーションの PCIe* トラフィックを調査します。

トップダウン・マイクロアーキテクチャー解析法
アプリケーションが利用可能なハードウェア・リソースをどのように使用しているかを把握し、CPU マイクロアーキテクチャーの利点を活用できるようにします。この情報を得る 1 つの手段として、オンチップのパフォー
マンス・モニタリング・ユニット (PMU) を使用する方法があります。
コンテンツ・エキスパート: Jackson Marusarz (英語)、Dmitry Ryabtsev (英語)PMU は、システム上で発生した特定のハードウェア・イベントをカウントする CPU コア内部の専用ロジックです。これらのイベントには、キャッシュミスや分岐予測ミスなどがあります。これらのイベントを組み合わせることで、命令あたりのサイクル数 (CPI) などの高レベルのメトリックを構成して監視できます。
特定のマイクロアーキテクチャーでは、PMU を介して数百ものイベントを利用できます。特定のパフォーマンスの問題を検出して解決する際に、どのイベントが有用であるかを判断することは容易ではありません。生のイ
ベントデータから有用な情報を得るには、マイクロアーキテクチャーの設計と PMU 仕様の両方に関する深い知識が求められます。しかし、事前定義されたイベントとメトリックを使用することにより、トップダウン特性化
方法論の利点を活用してデータを実用的な情報に変換することができます。
PMU 解析レシピでは、その手法とインテル® VTune™ プロファイラーでの使用方法を説明します。
•••

使用するもの:o トップダウン・マイクロアーキテクチャー解析法 (TMAM) の概要
o インテル® VTune™ プロファイラーによるトップダウン解析法
o マイクロアーキテクチャー・チューニングの方法論
手順:o バックエンド依存カテゴリーのチューニング
o フロントエンド依存カテゴリーのチューニング
o 投機の問題カテゴリーのチューニング
o リタイアカテゴリーのチューニング
関連クックブック・レシピ

トップダウン・マイクロアーキテクチャー解析法の概要
現代の CPU は、リソースを可能な限り有効に活用するため、ハードウェアによるスレッド化、アウトオブオー
ダー実行、命令レベルの並列性などの技術とともにパイプラインを採用しています。しかし、ソフトウェア・パ
ターンとアルゴリズムの中には、依然として非効率なものがあります。例えば、リンクデータ構造はソフトウェ
アで良く利用されますが、これはハードウェア・プリフェッチャーの有効性を損ねる間接アドレスの原因となります。多くの場合、このような振る舞いはパイプラインに無益な隙間 (パイプライン・バブル) を作り、データが取得されるまで実行するほかの命令がない状態となります。リンクデータ構造は、ソフトウェアの問題に対しては適切なソリューションですが、非効率な結果となるでしょう。このほかにも、CPU パイプラインに関連して重要な意味を持つ多くのソフトウェア・レベルの例があります。トップダウン・マイクロアーキテクチャー解析法は、
トップダウン特性化方法論をベースとして、アルゴリズムとデータ構造が適切な選択を行っているかどうか、詳しい情報を提供します。トップダウン・マイクロアーキテクチャー解析法の詳細は、『インテル® 64 および IA32 アーキテクチャー最適化リファレンス・マニュアル、付録 B.1』を参照してください。

トップダウン特性化は、アプリケーションのパフォーマンス・ボトルネックを特定するイベントベースのメトリッ
クを階層的に構成します。これは、CPU がアプリケーションを実行する際のパイプラインの利用率の平均を示します。以前のフレームワークは、CPU のクロックティックをカウントする方法を使用して、どの要素の CPU のクロックティックが、どの操作 (L2 キャッシュミスによるデータ取得など) に費やされたか判別して、イベントを解釈していました。このフレームワークは、その代わりに、パイプラインのリソースをカウントする方法を使用します。トップダウン特性化を理解するため、高レベルのマイクロアーキテクチャーの概念を調査します。マイク
ロアーキテクチャーの詳細の多くはこのフレームワークで抽象化されており、ハードウェアのエキスパートでなくても理解して、使用することができます。
現代のハイパフォーマンス CPU のパイプラインは、非常に複雑です。以下の図に示すように、パイプラインは概念的にフロントエンドとバックエンドの 2 つに分割できます。フロントエンドは、アーキテクチャーの命令を表すプログラムコードをフェッチして、それらを μop (マイクロオペレーション) と呼ばれる 1 つ以上の低レベ
ルのハードウェア操作にデコードします。μop は、パイプラインの「アロケーション」と呼ばれる過程でバックエンドへ送られます。アロケーションが行われると、バックエンドは μop のデータオペランドが利用可能になるのを監視し、利用可能な実行ユニットで μop を実行する役割を担います。μop の実行完了は「リタイア」と呼ばれ、μop の実行結果はアーキテクチャー状態にコミットされます (CPU レジスターやメモリーへの書き戻し)。通常、ほとんどの μop はパイプラインを通過してリタイアしますが、投機的にフェッチされた μop はリタイ
アする前に取り消される場合があります (分岐予測ミスのようなケース)。

最近のインテル® マイクロアーキテクチャーでは、パイプラインのフロントエンドはサイクルごとに 4 つのμop をアロケートでき、バックエンドはサイクルごとに 4 つの μop をリタイアできます。これらの機能を考慮して、パイプライン・スロットの抽象化の概念を定義します。パイプライン・スロットは、1 つのマイクロオペレー
ションを操作するために必要なハードウェアのリソースを表します。トップダウン特性化では、それぞれのCPU コアには、各クロックサイクルで利用可能な 4 つのパイプライン・スロットがあると仮定します。そして、特殊な PMU イベントを使用して、これらのパイプライン・スロットがどの程度効率良く利用されているか測定します。パイプライン・スロットの状態は、アロケーションの時点 (上記の図で★印が記された場所) で取得され、μop はフロントエンドからバックエンドへ移ります。アプリケーションの実行中に利用可能な各パイプライン・
スロットは、上記のパイプラインの図に基づいて 4 つのカテゴリーのいずれかに分類されます。
すべてのサイクルで、パイプライン・スロットは空であるか、μop で埋められているかのどちらかです。スロットが 1 クロックサイクルで空の場合、ストールに分類されます。このパイプラインを分類するために必要な次のステップは、パイプラインのフロントエンドまたはバックエンドのどちらがストールの原因であるか判断することです。この処理は、指定された PMU イベントと式を使用して行われます。トップダウン特性化の目的は重要なボトルネックを特定することですが、フロントエンドもしくはバックエンドのどちらかがストールの原因であるかは重要な考慮点です。一般に、ストールの原因がフロントエンドによる μop 供給の能力不足であれば、このサイクルはフロントエンド依存 (Front End Bound) スロットとして分類され、パフォーマンスはフロントエ
ンド依存カテゴリーのいくつかのボトルネックで制限されます。バックエンドで μop を処理する準備ができていないためにフロントエンドが μop を渡せない場合、空のパイプライン・スロットはバックエンド依存 (BackEnd Bound) として分類されます。バックエンド・ストールは、一般にバックエンドがいずれかのリソース (ロードバッファーなど) を使い果たしていることにより生じます。そして、フロントエンドとバックエンドの両方がストールしている場合、そのスロットはバックエンド依存として分類されます。これは、そのような場合にフロントエンドのストールを解決しても、アプリケーションのパフォーマンス改善に直結することが少ないためです。
バックエンドがボトルネックであれば、フロントエンドの問題を解決する前にボトルネックを排除する必要があります。
プロセッサーがストールしていない場合、パイプライン・スロットはアロケーションの時点で μop で満たされます。この場合、スロットをどのように分類するか決定する要因は、μop が最終的にリタイアするかどうかです。
リタイアすれば、そのスロットはリタイアに分類されます。そうでなければ、フロントエンドによる不適切な分岐予測、もしくは自己修正コードによるパイプライン・フラッシュなどのクリアイベントによって、そのスロットは投機の問題に分類されます。これら 4 つのカテゴリーが、トップダウン特性化のトップレベルを形成します。ア
プリケーションを特性化するため、それぞれのパイプライン・スロットは 4 つのカテゴリーの 1 つに分類されます。

これら 4 つのカテゴリーにおけるパイプライン・スロットの分布は非常に有用です。イベントベースのメトリッ
クは長年使用されてきましたが、この特性化以前は最もパフォーマンスに影響を与える問題を識別する手法はありませんでした。パフォーマンス・メトリックをこのフレームワークに当てはめると、開発者は最初に取り組むべき問題を知ることができます。4 つのカテゴリーにパイプライン・スロットを分類するイベントは、
インテル® マイクロアーキテクチャー開発コード名 Sandy Bridge (第 2 世代インテル® Core™ プロセッサー・ファミリーとインテル® Xeon® プロセッサー E5 ファミリー) から利用できます。以降のマイクロアーキテク
チャーでは、これらのハイレベルのカテゴリーを、より詳細なパフォーマンス・メトリックに分割できます。

インテル® VTune™ プロファイラーによるトップダウン解析法
インテル® VTune™ プロファイラーは、インテル® マイクロアーキテクチャー開発コード名 Ivy Bridge 以降のトップダウン特性化で定義されたイベント収集のための事前定義を含む [Microarchitecture Exploration(マイクロアーキテクチャー全般)] 解析タイプ (英語) を提供します。マイクロアーキテクチャー全般はまた、その他の有用なパフォーマンス・メトリックの計算に必要なイベントを収集します。マイクロアーキテクチャー全
般解析の結果は、デフォルトでは [Microarchitecture Exploration (マイクロアーキテクチャー全般)] ビュー
ポイント (英語) に表示されます。
マイクロアーキテクチャー全般の結果は、トップダウン特性化を補足する階層的なカラムで表示されます。
[Summary (サマリー)] ウィンドウは、アプリケーション全体の各カテゴリーのパイプライン・スロットの比率を表示します。結果はさまざまな方法で調査できます。最も一般的な方法は、関数レベルで表示されるメトリッ
クを調査することです。

それぞれの関数で、各カテゴリーのパイプライン・スロットが表示されます。例えば、上記で選択されている
price_out_impl 関数は、パイプライン・スロットの 2.2% がフロントエンド依存、7.4% が投機の問題、
64.2% がメモリー依存、8.4% がコア依存、そして 17.8% がリタイアカテゴリーです。各カテゴリーを展開すると、そのカテゴリーに属するメトリックが表示されます。自動ハイライト機能により、開発者の注意を促す潜
在的な問題領域が強調されます。ここでは、price_out_impl のメモリー依存のパイプライン・スロットの比率がハイライトされています。

マイクロアーキテクチャー・チューニングの方法論
パフォーマンス・チューニングを行う際は、常にアプリケーションの上位の hotspot に注目します。「hotspot」
は最も CPU 時間を消費している関数です。これらのスポットに注目し、アプリケーションのパフォーマンス全体に影響する最適化を特定します。インテル® VTune™ プロファイラーには、ユーザーモードのサンプリングとハードウェア・イベントベースのサンプリングの 2 つの収集モードを備えた hotspot 解析機能があります。マイクロアーキテクチャー全般ビューポイント内の hotspot は、CPU クロックティック数を測定して、最も高い
クロックティック・イベントの関数やモジュールを決定することで特定できます。マイクロアーキテクチャーのチューニングから最大限の利益を得るため、並列処理の追加などのアルゴリズムの最適化がすでに行われていることを確認します。一般にシステムのチューニングが最初に行われ、その後アプリケーション・レベルのア
ルゴリズムのチューニング、アーキテクチャーとマイクロアーキテクチャーのチューニングへと続きます。この
手順は、トップダウンのソフトウェア・チューニング方法論と同様に、「トップダウン」と呼ばれます。ワークロー
ドの選択などその他の重要なパフォーマンス・チューニングについては、「謎めいたソフトウェア・パフォーマンスの最適化を紐解く」 (英語) の記事で説明されています。
1. hotspot の (アプリケーションの合計クロックティックの大半を占める) 関数を特定します。
2. トップダウン法と以下に示すガイドラインを使用して hotspot の効率を評価します。
3. 非効率であれば、最も重要なボトルネックを示すカテゴリーをドリルダウンし (掘り下げ)、ボトルネッ
クのサブレベルを調べて原因を特定します。
4. 問題を最適化します。インテル® VTune™ プロファイラーのチューニング・ガイドには、各カテゴリーの多くのパフォーマンスの問題に対するチューニングの推奨事項が含まれます。
5. 上位の hotspot をすべて評価するまで上記のステップを繰り返します。
インテル® VTune™ プロファイラーは、hotspot が事前定義されたしきい値の範囲を超えている場合、GUI 上のメトリック値を自動的にハイライト表示します。インテル® VTune™ プロファイラーは、アプリケーション内で取得された合計クロックティックの 5% 以上である関数を hotspot として分類します。パイプライン・スロッ
トが特定のカテゴリーのボトルネックを構成するかどうかの判断はワークロードに関係していますが、以下の表に一般的なガイドラインを示します。

各カテゴリーのパイプライン・スロットの期待される範囲(適切に最適化された hotspot)
カテゴリー

クライアント/
デスクトップ向け
アプリケーション

サーバー/データベース/
分散型アプリケーション

ハイパフォーマンス・
コンピューティング (HPC)
アプリケーションリタイア

20-50%

10-30%

30-70%

バックエンド依存

20-40%

20-60%

20-40%

フロントエンド依存

5-10%10-25%

5-10%

投機の問題

5-10%

5-10%

1-5%

これらのしきい値は、インテルの研究所でいくつかのワークロードを解析した結果に基づいています。hotspotのカテゴリー (リタイアを除く) に費やされた時間が上位にあるか、示される範囲よりも大きい場合、調査が役立つと考えられます。この状況が 1 つ以上のカテゴリーに当てはまる場合、時間が最も上位のカテゴリーを最初に調査します。hotspot が各カテゴリーで時間を費やしていても、その値が通常の範囲内であれば問題は報告されない可能性があることに注意してください。
トップダウン法を適用する際に重要なことは、ボトルネックではないカテゴリーに最適化の時間をかける必要はないということです。最適化を行っても大幅なパフォーマンス向上にはつながりません。

バックエンド依存カテゴリーのチューニング
チューニングされていないアプリケーションのほとんどは、バックエンド依存です。バックエンドの問題を解決するのは、多くの場合、必要以上にリタイアに時間のかかるレイテンシーの原因を解決することです。インテル®
マイクロアーキテクチャー開発コード名 Sandy Bridge 向けに、インテル® VTune™ プロファイラーは、高いレ
イテンシーの原因を検出するためのバックエンド依存メトリックを用意しています。例えば、ラストレベル・
キャッシュミス (LLC Miss) メトリックは、データを取得するために DRAM にアクセスする必要があるコード領域を特定し、分割ロード (Split Loads) と分割ストア (Split Stores) メトリックは、パフォーマンスに影響する
複数のキャッシュ間のメモリー・アクセス・パターンを指摘します。インテル® マイクロアーキテクチャー開発
コード名 Sandy Bridge のメトリックの詳細は、「チューニング・ガイド」を参照してください。インテル® マイク
ロアーキテクチャー開発コード名 Ivy Bridge (第 3 世代インテル® Core™ プロセッサー・ファミリー) 以降では、バックエンド依存に分類されるイベントが、メモリー依存とコア依存のサブメトリックに区分されています。上位 4 つのカテゴリーに属するメトリックは、パイプライン・スロット・ドメイン以外のドメインを使用する可能性があります。各メトリックは、PMU イベントの最も適切なドメインを使用します。詳細は、各メトリック
またはカテゴリーのドキュメント (英語) を参照してください。
メモリー依存とコア依存のサブメトリックは、トップレベルの分類で使用されるアロケーション・ステージとは対照的に、実行ユニットの使用率に対応するイベントを使用して決定されます。したがって、これらのメトリックの合計は、必ずしもトップレベルで決定されたバックエンド比率と一致するわけではありません (関連性は高い)。
メモリー依存カテゴリーのストールの原因は、メモリー・サブシステムに関連します例えば、キャッシュミスとメ
モリーアクセスは、メモリー依存のストールの原因となります。コア依存のストールは、各サイクルで CPU の実行ユニットが十分に利用されていないことが原因で発生します。例えば、連続する複数の除算命令は、除算ユ

ニットの競合を引き起こし、コア依存のストールの原因となります。この分類では、ストールで未完了のメモ
リーアクセスがない場合、そのスロットはコア依存に分類されます。例えば、遅延しているロードがある場合、ロードがまだデータを取得していないことが原因で実行ユニットが待機しているため、サイクルはメモリー依存に分類されます。PMU イベントは、アプリケーションの真のボトルネックを特定するのに役立つ分類が可能になるように、ハードウェアで実装されています。バックエンドの問題のほとんどは、メモリー依存カテゴリーに区分されます。
メモリー依存カテゴリーのほとんどのメトリックは、L1 キャッシュからメモリーまでの、ボトルネックになっているメモリー階層のレベルを特定します。この決定に使用されるイベントは注意深く設計されています。一旦
バックエンドがストールすると、メトリックは遅延中の特定のキャッシュレベルへのロード、または実行中のス
トアのストールを区分しようとします。hotspot が特定のレベルで制限されている場合、そのデータの多くはキャッシュやメモリー階層から取得されていることを意味します。最適化の際は、コアに近い位置にデータを移動することに注目します。ストア依存 (Store Bound) は、パイプラインを進行中のロードが直前のストアに依存しているなどの依存性を示すサブカテゴリーとしても利用されます。これらのカテゴリーには、メモリー依存
実行の原因となるアプリケーション固有の動作を特定するメトリックがあります。例えば、ストアフォワードでブロックされたロード (Loads Blocked by Store Forwarding) と 4K エリアス (4K Aliasing) は、アプリケー
ションが L1 依存 (L1 Bound) であることを示すメトリックです。
コア依存のストールは、バックエンド依存ではそれほど多くはありません。これらのストールは、大量のメモ
リー要求がないために利用可能な計算リソースが効率的に利用されない場合に発生します。例えば、浮動小
数点 (FP) 数値計算を小さなループで行い、データがキャッシュに収まる場合などです。インテル® VTune™ プ
ロファイラーは、このカテゴリーの動作を検出するいくつかのメトリックを用意しています。例えば、除算器(Divider) メトリックは、除算器ハードウェアが頻繁に使用されたサイクルを特定し、ポート使用率 (PortUtilization) メトリックは実行ユニットの個々の競合を特定します。

注
灰色で表示されるメトリック値は、このメトリックで収集されたデータの信頼性が低いことを表します。これは、収集された PMU イベントのサンプル数が非常に少ないことが原因であると考えられます。このデータは無視できますが、収集に戻ってデータ収集時間、サンプリングの間隔、またはワークロードを増やして再度収集することもできます。

フロントエンド依存カテゴリーのチューニング
フロントエンド依存カテゴリーは、ほかのタイプのパイプライン・ストールをいくつかカバーします。パイプライ
ンのフロントエンド部分がアプリケーションのボトルネックになることは、それほど多くはありません。例えば、
JIT コードとインタープリターで解釈されるコードは、命令ストリームが動的に生成される (コンパイラーによるコード配置の利点が得られない) ため、フロントエンド・ストールの原因となります。フロントエンド依存カテ

ゴリーのパフォーマンスの改善は、通常、コード配置 (ホットなコードと隣接して配置) とコンパイラーのテクニックに関連します。例えば、分岐の多いコードや大きなフットプリントのコードは、フロントエンド依存カテ
ゴリーで警告されます。コードサイズの最適化やコンパイラーによるプロファイル・ガイド最適化 (PGO) などのテクニックは、多くの場合ストールを軽減するのに有効です。
インテル® マイクロアーキテクチャー開発コード名 Ivy Bridge 以降のトップダウン法では、フロントエンド依
存のストールがフロントエンド・レイテンシーとフロントエンド帯域幅の 2 つのカテゴリーに分離されました。
フロントエンド・レイテンシー (Front-End Latency) メトリックは、バックエンドの準備ができているにもかかわらず、フロントエンドによって μop が発行されないサイクルを報告します。フロントエンド・クラスターは、サ
イクルあたり最大 4μop を発行できることを思い出してください。フロントエンド帯域幅 (Front-End
Bandwidth) メトリックは、発行された μop が 4 未満のサイクル、つまり、フロントエンドの能力を使い切っていないサイクルを報告します。各カテゴリーの下には、さらにメトリックがあります。
分岐予測ミスは、多くの場合、投機の問題カテゴリーに分類されますが、インテル® マイクロアーキテクチャー
開発コード名 Ivy Bridge 以降では、フロントエンドに属する分岐リステア (Branch Resteer) メトリックによって、フロントエンドが非効率になったことが示されます。

インテル® VTune™ プロファイラーは、フロントエンド依存の原因を特定するメトリックの一覧を表示します。
これらのカテゴリーのいずれかの結果が顕著な場合、メトリックをさらに深く調査して原因を特定し、修正する方法を考えます。例えば、命令トランスレーション・ITLB オーバーヘッド (ITLB Overhead) と命令キャッシュミ
ス (ICache Miss) メトリックは、フロントエンド依存の実行で問題のある領域が分かります。チューニングの推奨事項は、インテル® VTune™ プロファイラーのチューニング・ガイドを参照してください。

投機の問題カテゴリーのチューニング
3 番目のトップレベルのカテゴリー、投機の問題は、パイプラインがリタイアしない命令をフェッチして実行しているためにビジーであることを示します。投機の問題のパイプライン・スロットは、マシンが不適切な投機実行から回復する間、リタイアしないまたはストールする μop が発行されることでスロットが浪費されている状態です。投機の問題は、分岐予測ミスとマシンクリア、および (一般的ではありませんが) 自己修正コードによって引き起こされます。投機の問題は、コンパイラーによるプロファイル・ガイド最適化 (PGO)、間接分岐の回避、およびマシンクリアを引き起こすエラー条件の排除などのテクニックで軽減できます。投機の問題を解決する
ことは、フロントエンド依存のストール数を減らすのに役立ちます。特定のチューニングのテクニックについては、適切なマイクロアーキテクチャー向けのインテル® VTune™ プロファイラーのチューニング・ガイドを参照
してください。

リタイアカテゴリーのチューニング
トップレベルの最後のカテゴリー、リタイアは、パイプラインが通常動作の実行でビジーであることを意味します。可能であれば、このカテゴリーにアプリケーションの多くのスロットが分類されるのが理想的です。しかし、パイプライン・スロットでリタイアする大部分がコード領域であれば、改善の余地はあります。リタイアカテゴ
リーの 1 つのパフォーマンスの問題は、マイクロシーケンサーの高い利用率です。これは、特定の条件が記述された μop の長いストリームを生成することで、フロントエンドをアシストします。この場合、多くの μop がリ
タイアしますが、いくつかは回避することが可能です。例えば、FP アシストはデノーマルイベントに適用され、多くの場合、コンパイラーのオプション (DAZ や FTZ) によって軽減できます。コード生成の選択もまた、これらの問題を軽減するのに役立ちます。詳細は、インテル® VTune™ プロファイラーのチューニング・ガイドを参照してください。インテル® マイクロアーキテクチャー開発コード名 Sandy Bridge では、アシスト (Assists) はリタ
イアカテゴリーのメトリックとして分類されます。インテル® マイクロアーキテクチャー開発コード名 Ivy
Bridge 以降では、リタイアカテゴリーのパイプラインは、全般リタイア (General Retirement) と呼ばれるサブカテゴリーに分割され、マイクロコード・シーケンサーの μop は別に識別されます。

まだ行っていない場合、アルゴリズムの並列化やベクトル化によるチューニングは、リタイアカテゴリーでのコード領域のパフォーマンスを改善するのに役立ちます。

まとめ
トップダウン法とインテル® VTune™ プロファイラーにおけるその有効性は、PMU を使用したパフォーマンス・
チューニングの新たな方向性を示しています。開発者がこの特性化を習得するために費やす時間は価値あるものです。特性化のサポートは最近の PMU 向けに設計されており、その階層構造は将来のインテル® マイク
ロアーキテクチャーにも拡張可能です。例えば、特性化は、インテル® マイクロアーキテクチャー開発コード名

Sandy Bridge からインテル® マイクロアーキテクチャー開発コード名 Ivy Bridge の間で大幅に拡張されました。
トップダウン法の目標は、アプリケーション・パフォーマンスのボトルネックの種類を特定することです。
インテル® VTune™ プロファイラーの全般解析と可視化機能の目標は、アプリケーションを改善するために適用可能な情報を提供することです。これらを併用することで、アプリケーションのパフォーマンスを大幅に改善できるだけでなく、最適化における生産性も向上できます。

関連クックブック・レシピ••••

チューニング・レシピ: フォルス・シェアリング
チューニング・レシピ: 頻繁な DRAM アクセス
チューニング・レシピ: 低いポート使用率
チューニング・レシピ: 命令のキャッシュミス

関連項目
•
•
•
•

マイクロアーキテクチャー・パイプ (英語)
マイクロアーキテクチャー全般ビュー (英語)
チューニング・ガイドとパフォーマンス解析の記事
クロックティックとパイプライン・スロット・ベースのメトリック (英語)OpenMP* コード解析
このレシピは、OpenMP* または OpenMP* - MPI ハイブリッド・アプリケーションの CPU 利用率を解析して、潜在的な非効率性の原因を特定します。
コンテンツ・エキスパート: Dmitry Prohorov (英語)
OpenMP* はフォーク・ジョイン並列モデルであり、OpenMP* プログラムは単一のマスター・シリアルコード・
スレッドで実行を開始します。並列領域に到達すると、マスタースレッドは複数のスレッドにフォークして並列領域を実行します。各スレッドは並列領域の最後にあるバリアでジョインして、その後マスタースレッドがシリ
アルコードの実行を続行します。マスタースレッドが並列領域にフォークし、barrier や single などの構造でワークを調整する、MPI プログラムのように OpenMP* プログラムを記述することもできます。しかし、シリアルコードが点在する並列領域のシーケンスで構成される OpenMP* プログラムの方が一般的です。
理想的には、並列化されたアプリケーションは利用可能な CPU コアの処理時間を 100% 利用して、実行開始から終了まで有用なワークを実行するワーカースレッドを持ちます。実際には、ワーカースレッドがアクティ
ブスピンで待機している場合 (待機時間は短くなることが予想されます)、または受動的に待機して CPU を消費していない場合は、有効な CPU 利用率は低くなります。ワーカースレッドが待機し、有用なワークを実行していない理由はいくつかあります。
••••

シリアル領域の実行 (並列領域外): マスタースレッドがシリアル領域を実行している場合、ワーカー
スレッドは OpenMP* ランタイムで次の並列領域を待機しています。
ロード・インバランス: スレッドは並列領域でワークロードの実行を終了すると、他のスレッドが終了するのをバリアで待機します。
並列ワーク不足: ループの反復回数がワーカースレッド数よりも少ないため、チームのいくつかのス
レッドはバリアで待機しており、有用なワークを実行していません。
ロックでの同期: 並列領域内で同期オブジェクトが使用されると、ほかのスレッドとの共有リソースへのアクセス競合を避けるため、スレッドはロックが開放されるまで待機します。

インテル® Composer XE 2013 Update 2 以降とともにインテル® VTune™ プロファイラーを使用すると、ア
プリケーションが利用可能な CPU をどのように利用し、CPU が未使用である原因を特定できます。
インテル® VTune™ プロファイラーで OpenMP* アプリケーションを解析するには、次の操作を行います。
1.
2.
3.
4.
5.
6.

推奨オプションでコードをコンパイルする
OpenMP* 領域解析を設定する
アプリケーション・レベルの OpenMP* メトリックを調査する
シリアルコードを特定する
潜在的なゲインを予測する
制限事項を理解する

推奨オプションでコードをコンパイルする
コンパイル時に並列領域とソース解析を有効にするには、次の手順に従ってください。

•OpenMP* 並列領域を解析するには、インテル® コンパイラー 13.1 Update 2 以降 (インテル®
Composer XE 2013 Update 2 に含まれます) でコードがコンパイルされていることを確認してください。古いバージョンの OpenMP* ランタイム・ライブラリーが検出されると、インテル® VTune™ プロ
ファイラーは警告メッセージを出力します。この場合、収集結果は不完全な可能性があります。
ドキュメントに記載されている最新の OpenMP* 解析オプションを使用するには、常に最新バージョ
ンのインテル® コンパイラーを使用していることを確認してください。

•

Linux* 上で、GCC でコンパイルされた OpenMP* アプリケーションを解析するには、GCC OpenMP*
ライブラリー (libgomp.so) にシンボル情報が含まれていることを確認してください。これを確認す
るには、libgomp.so を検索して nm コマンドでシンボルをチェックします。次に例を示します。
nm libgomp.so.1.0.0
ライブラリーにシンボル情報が含まれていない場合、シンボル付きの新しいライブラリーをインストールまたはコンパイルするか、ライブラリーのデバッグ情報を生成してください。例えば、Fedora* では yum リポジトリーから GCC デバッグ情報をインストールできます。
yum install gcc-debuginfo.x86_64

OpenMP* 解析を設定する
ターゲットの OpenMP* 解析を行うには、次の操作を実行します。
1. インテル® VTune™ プロファイラーのツールバーにある(スタンドアロン GUI)/(VisualStudio* IDE) [Configure Analysis (解析の設定)] ボタンをクリックします。
[Configure Analysis (解析の設定)] ウィンドウが表示されます。
2. [HOW (どのように)] ペインで、[Browse (参照)] ボタンをクリックして OpenMP* 解析をサポートする解析タイプ (スレッド化、HPC パフォーマンス特性、メモリーアクセス、またはカスタム解析タイプ) を選択します。
3. [Analyze OpenMP regions (OpenMP* 領域を解析)] オプションが選択されていない場合は選択します ([Details (詳細)] セクションを確認)。
4.

[Start (開始)] ボタンをクリックして、解析を実行します。

インテル® コンパイラーの OpenMP* ランタイム・ライブラリーは、プロファイル・モードで実行中のアプリケー
ション向けに特別なマーカーを提供します。これを利用して、インテル® VTune™ プロファイラーは OpenMP*
並列領域の統計を解読し、アプリケーション・コードのシリアル領域を区別できます。

アプリケーション・レベルの OpenMP* メトリックを調査する
解析ターゲットの CPU 利用率を理解してから解析を始めます。HPC パフォーマンス特性 (英語) ビューポイン
トを使用する場合、[Summary (サマリー)] ウィンドウの [Effective Physical Core Utilization (効率的な物

理コア利用率)] セクションで、使用されている論理コア数と物理コア数、および CPU 利用率の効率 (パーセント) の予測に注目します。低いコア利用率は、パフォーマンスの問題としてフラグが付けられます。
他のビューポイントでは、アプリケーションの経過時間を CPU 利用率レベルまで細分化した [CPUUtilization Histogram (CPU 利用率の分布図)] が表示されます。分布図には有効な利用率しか表示されな
いため、アプリケーションがスピンループ (アクティブ待機) で CPU を使用した CPU サイクルはカウントされません。利用可能なハードウェア・スレッド数よりも少ない OpenMP* ワーカースレッドを意図的に使用する場
合、スライドバーを使用してデフォルトレベルから調整できます。

バーが理想的な利用率に近い場合、パフォーマンス向上の可能性を見つけるには、アルゴリズムまたはマイク
ロアーキテクチャーのチューニングを検討する必要があります。アプリケーションの非効率な並列化について
は、[Summary (サマリー)] ウィンドウの [OpenMP Analysis (OpenMP* 解析)] セクションを調査します。

[Summary (サマリー)] ウィンドウのこのセクションには、収集時間とプログラムのシリアル領域 (並列領域外) と並列領域の持続期間が表示されます。シリアル領域が長い場合、さらに並列処理を導入するか、並列化が困難なシリアル領域ではアルゴリズムやマイクロアーキテクチャーのチューニングを行って、シリアル実行を短縮することを検討してください。スレッドカウントの多いマシンのシリアル領域は、潜在的なスケーリングに深刻な悪影響を与えるため (アムダールの法則)、可能な限り最小にすべきです。
[Summary (サマリー)] ウィンドウの [OpenMP Region Duration Histogram (OpenMP* 領域持続分布図)] を参照して、OpenMP* 領域のインスタンスを解析し、インスタンスの持続期間の分布を調査して、高速/
良好/低速領域のインスタンスを識別します。デフォルトの分布図では、最小領域時間と最大領域時間の間が20/40/20 の比率で高速/良好/低速に分類されます。必要に応じて、しきい値を調整します。

このデータを使用して、[OpenMP Region/OpenMP Region Duration Type/... (OpenMP* 領域/OpenMP* 領域持続タイプ/...)] グループ化レベルでグリッドをさらに詳しく解析します。

シリアルコードを特定する
シリアル実行されたコードを解析するには、[Summary (サマリー)] ウィンドウの [Serial Time (outside
parallel regions) (シリアル時間 (並列領域外))] セクションを展開して、[Top Serial Hotspots (outside
parallel regions) (上位のシリアル・ホットスポット (並列領域外))] を確認します。関数名をクリックすると、[Bottom-up (ボトムアップ)] ウィンドウでその関数の詳細を確認できます。

潜在的なゲインを予測する
コードの並列領域で CPU 利用率の効率を予測するには、潜在的なゲイン (英語) メトリックを使用します。このメトリックは、並列領域の実測された経過時間と理想化された経過時間 (スレッドのバランスが完璧でOpenMP* ランタイムのオーバーヘッドがゼロであると仮定) の差を予測します。このデータを使用して、並列実行を改善することで短縮できる最大時間を見積ることができます。

[Summary (サマリー)] ウィンドウには、[Potential Gain (潜在的なゲイン)] メトリック値が最も高い 5 つの並列領域が表示されます。#pragma omp parallel で定義された並列領域ごとに 、このメトリックは並列
領域のすべてのインスタンスの潜在的なゲインの合計を示します。

領域の潜在的なゲインが顕著である場合、領域名のリンクをクリックして [Bottom-up (ボトムアップ)] ウィ
ンドウに移動し、バリアによるインバランスなどの非効率なメトリックの詳細な解析を示す [/OpenMP
Region/OpenMP Barrier-to-Barrier Segment/.. (/OpenMP* 領域/OpenMP* バリアからバリアのセグ
メント/..)] グループ化を使用して、さらに深く調査できます。
インテル® コンパイラーの OpenMP* ランタイムは、インテル® VTune™ プロファイラー向けにバリアをインス
トルメントします。インテル® VTune™ プロファイラーは、領域のフォーク位置または以前のバリアからセグメントを定義するバリアまでの、バリア間の OpenMP* 領域セグメントの概念を導入しています。

上記の例では、user barrier、暗黙的な single barrier、暗黙的な omp for ループバリアと region
join バリアとして定義された 4 つのバリアからバリアへのセグメントがあります。
OpenMP* 領域に、並列ループや #pragma single sections などの暗黙のバリア、または明示的なユーザー
バリアが複数定義されている場合、特定の構造の影響や非効率なメトリックに対するバリアを解析します。
バリアタイプはセグメント名に組込まれます (例えば、loop、single、reduction など)。また、暗黙のバリアを持つ並列ループについて、ループのスケジュール、チャンクサイズ、および最小/最大/平均ループ反復カウン
トなど、インバランスやスケジュールのオーバーヘッドを理解するのに役立つ追加の情報を出力します。ループ

反復カウント情報は、外部ループの並列化により、反復回数が少ないワーカースレッドの利用率が低下する問
題を識別するのにも役立ちます。この場合、内部ループを並列化するか、collapse 節を使用してワーカース
レッドを飽和させることを検討してください。

OpenMP* スレッド数で正規化した非効率のコスト (経過時間) を表示することで、領域の潜在的なゲインの内訳を示す [Potential Gain (潜在的なゲイン)] カラムのデータを解析します。経過時間コストは、特定の非効率性タイプに対応すべきかどうかを判断するのに役立ちます。インテル® VTune™ プロファイラーは、次の非効率性タイプを認識できます。
•

•

•
•

•
•

Imbalance (インバランス): スレッドは異なる時間でワークを終え、バリアで待機しています。インバラ
ンス時間が顕著である場合、動的なスケジュールの導入を検討してください。インテル® Parallel
Studio Composer Edition の OpenMP* ランタイム・ライブラリーはインバランスを正確にレポート
し、メトリックはサンプリングに基づいて計算される他の非効率性のように統計の精度に依存しません。
Lock Contention (ロック競合): スレッドは、競合するロック、または "ordered" 節が指定された並列ループで待機しています。ロック競合の時間が顕著である場合、リダクション操作、スレッド・ローカル・ストレージ、または低コストのアトミック操作を使用することで、並列構造内での同期を回避してください。
Creation (生成): 並列ワークの配置に関連したオーバーヘッド。並列ワークの配置時間が顕著である
場合、並列領域を外部ループに移動して、並列処理の粒度を粗くしてください。
Scheduling (スケジュール): ワーカースレッドへの並列ワークの割り当てに関連した OpenMP* ランタイム・スケジューラーのオーバーヘッドです。スケジュールの時間が顕著である場合 (動的スケジュールでよく見られます)、大きなチャンクサイズの "dynamic" スケジュール、または "guided" スケ
ジュールを使用します。
Atomics (アトミック): アトミック操作の実行に関連した OpenMP* ランタイムのオーバーヘッド。
Reduction (リダクション): リダクション操作で費やされた時間。

インテルの OpenMP* ランタイムのバージョンが古く、[Potential Gain (潜在的なゲイン)] カラムを拡張できない場合、対応する CPU 時間メトリックの内訳を解析してください。
パフォーマンスが重要な OpenMP 並列領域のソースを解析するには、[OpenMP Region/.. (OpenMP* 領域/..)] グループ化レベルでソートしたグリッドで領域識別子をダブルクリックします。インテル® VTune™ プロ
ファイラーは、ソースビューを開いて、インテル® コンパイラーが生成した疑似関数内の選択された OpenMP*
領域の先頭を表示します。

注デフォルトでは、インテル® コンパイラーは領域名にソースファイル名を追加しません。そのため、OpenMP*
並列領域名が [unknown (不明)] と表示されます。領域名のソースファイル名を取得するには、コンパイル・オプションに -parallel-source-info=2 を追加します。

制限事項を理解する
インテル® VTune™ プロファイラーの並列 OpenMP* 領域の解析には、次のような制限があります。
•••

サポートされる語彙的な並列領域の最大数は 512 です。512 個を超える並列領域にスコープが到達すると、並列アノテーションは出力されません。
入れ子になった並列領域はサポートされません。最上位の項目のみが領域を生成します。
インテル® VTune™ プロファイラーは、静的リンクされた OpenMP* ライブラリーをサポートしません。

関連クックブック・レシピ•••

チューニング・レシピ: OpenMP* インバランスとスケジュール・オーバーヘッド
チューニング・レシピ: 低いプロセッサー・コア利用率: OpenMP* シリアル時間
設定レシピ: MPI アプリケーションのプロファイル

関連項目
•
•

knob analyze-openmp=true (英語) vtune オプション
MPI コード解析 (英語)DPDK アプリケーションのコア使用率
このレシピは、DPDK ベースのアプリケーションにおけるパケット受信のコア使用率を特徴付けるメトリックを調査します。
コンテンツ・エキスパート: Ilia Kurakin (英語)、Roman Khatko (英語)
高速なパケット処理が求められるデータ・プレーン・アプリケーションでは、DPDK は特定の論理コアにピニングされた無限ループでパケットを受信するため特定のポートをポーリングします。このようなパケット受信
ポーリングモデルは、有効なコア使用率を測定する上で課題となります。ポーリングループを実行するコアのCPU 時間は、DPDK がアイドルのループサイクル数に関係なく、常に 100% 近くになります。そのため、CPU
時間からパケット受信のコア使用率は分かりません。しかし、このポーリングモデルでは、[Rx Spin Time - %of wasted polling loop cycles (Rx スピン時間 - 無駄なポーリング・ループ・サイクルの %)] からコア使用率が分かります。Wasted Cycles (無駄なサイクル) とは、DPDK がパケットを受信しなかった反復を指します。
このレシピは、次のステップに従って、DPDK ベースのワークロードでパケット受信の効率を解析します。
1. 使用するもの
2. 手順:
a. 入力と出力解析を実行する
b. DPDK Rx スピン時間メトリックを使用してコア使用率を解析する
c. DPDK Rx バッチ統計ヒストグラムを使用してパケット受信を解析する
d. Rx 操作を理解して Rx ピークを調査する

使用するもの••アプリケーション: シングルコアで L2 フォワーディングを実行する DPDK testpmd アプリケーショ
ン。インテル® VTune™ Amplifier のプロファイル・サポートが有効な DPDK でコンパイルされています。
ツール:o インテル® VTune™ Amplifier のプロファイル・サポートが有効な DPDK。インテル®
VTune™ Amplifier 18.11 以降では、プロファイル・サポートが DPDK に統合されます。それよりも古いバージョンを使用する場合、パッチ (17.11、18.02、および 18.05 で利用可能) を適用してください。DPDK でプロファイルを有効にするには、インテル® VTune™ Amplifier がDPDK ポーリングサイクルにアタッチするように、(config/common_base config ファイ
ルで) CONFIG_RTE_ETHDEV_RXTX_CALLBACKS フラグとCONFIG_RTE_ETHDEV_PROFILE_WITH_VTUNE フラグを有効にして、DPDK (とターゲッ
ト・アプリケーション) を再構成し再コンパイルします。
o インテル® VTune™ Amplifier 2019: 入力と出力解析
注▪

インテル® VTune™ プロファイラー評価版のダウンロードと製品サポートについては、https://www.isus.jp/intel-vtune-amplifier-xe/ を参照してください。

このクックブックのレシピはすべてスケーラブルであり、インテル® VTune™
Amplifier 2018 以降に適用できます。バージョンにより設定がわずかに異なることがあります。
▪ ベータ版インテル® oneAPI ベース・ツールキット向けのバージョンから、インテル®
VTune™ Amplifier の名称がインテル® VTune™ プロファイラーに変わりました。引
き続き、インテル® Parallel Studio XE またはインテル® System Studio のコンポー
ネントとして、あるいはスタンドアロン版のインテル® VTune™ プロファイラーをご利用いただけます。
オペレーティング・システム: 40GbE リンクを介して接続された、64 バイトのフレームを生成するトラ
フィック・ジェネレーター (以下の図では GEN) とパケットレシーバー (SUT: System Under Test) で構成されたテストシステム。SUT はパケットの L2 フォワーディングを実行します。
▪

••

CPU: インテル® Xeon® Platinum 8180 プロセッサー (38.5MB キャッシュ、2.50GHz、28 コア)

入力と出力解析を実行する
DPDK 解析では、インテル® VTune™ Amplifier GUI で入力と出力解析を選択し、[DPDK IO API] を有効にします。

DPDK Rx Spin Time (DPDK Rx スピン時間) などの API 固有メトリックとハードウェア・イベントやハード
ウェア・イベントベース・メトリックを関連付けることができます。例えば、DPDK Rx スピン時間と [Analyze
PCIe bandwidth (PCIe* 帯域幅を解析)] が有効な場合に収集される PCIe* 帯域幅の間には依存関係があります。
コマンドラインから入力と出力解析を実行して PCIe* 帯域幅と DPDK メトリックを取得するには、解読可能な名前でデバイスごとの PCIe* 帯域幅を取得できるように、root 権限で次のコマンドを実行します。
amplxe-cl -collect io -knob kernel-stack=false -knob dpdk=true -knob collectpcie-bandwidth=true -knob collect-memory-bandwidth=false -knob drambandwidth-limits=false --target-process=testpmd

DPDK Rx スピン時間メトリックを使用してコア使用率を解析する
データが収集されたら、[Platform (プラットフォーム)] タブから始め、スレッドの [DPDK Rx Spin Time(DPDK Rx スピン時間)] オーバータイム・メトリックを調査します。このメトリックは、ゼロパケット返す
rte_eth_rx_burst(...) 関数呼び出しの割合を (スレッドごとに) 示します。これは、パケットを提供しないポーリングループ反復の割合と同じです。

注
ここで紹介した結果は合成されたものです。
上記の [Platform (プラットフォーム)] ビューでは、ポーリングスレッドの [CPU Time (CPU 時間)] (茶色) は
常に 100% 近くです。[DPDK Rx Spin Time (DPDK Rx スピン時間)] (赤色) は、パケット受信のスレッド使用率です。マウスでグラフをポイントすると、その時点の値がツールヒントに表示されます。
この例では、トラフィック・ジェネレーターを自動化して、2 秒ごとに 40Gbps の 5% ずつトラフィック・レートを増やしてパケット損失データを収集しました。適切にフォーマットされた *.csv ファイル形式のオーバータイ
ム・データは、インテル® VTune™ Amplifier プロジェクトにインポート (英語) してタイムラインに表示できます。

デフォルトでは、インテル® VTune™ Amplifier は上記の [Global Counters (グローバルカウンター)] セク
ションに表示されている [Packet Rate (パケットレート)] メトリックと [Packet Loss (パケット損失)] メト
リックを収集できません。このレシピでは、これらのメトリックは別途収集され、インテル® VTune™ Amplifier
によって収集された結果に手動でインポートされました。別の方法として、インテル® VTune™ Amplifier のカ
スタムコレクター (英語) 機能を使用して追加のメトリックを含む csv ファイルをインポートできます。カスタ
ムコレクターは、収集の開始/停止/一時停止時にインテル® VTune™ Amplifier によって実行される追加のプロセスです。カスタムコレクターを使用して、すべてのシステム自動化を実装し、追加のメトリックを収集できます。これにより、実験が再現可能となり、結果を比較できるようになります。これは、パフォーマンス・チューニン
グに役立ちます。
[Platform (プラットフォーム)] ビューの下部では、タイムラインで [Inbound PCIe Bandwidth (インバウン
ド PCIe* 帯域幅)] の変化を確認できます。この解析はインテル® マイクロアーキテクチャー (開発コード名
Skylake) 上で root 権限で実行されたため、PCIe* 帯域幅が PCIe* デバイス別に人間が解読できる名前で表示されています。
上記の入力と出力解析の [Platform (プラットフォーム)] ビューでは、すべてのメトリックに相関性があります。トラフィック生成レートが上昇すると、[Inbound PCIe Bandwidth (インバウンド PCIe* 帯域幅)] は増加
し、[DPDK Rx Spin Time (DPDK Rx スピン時間)] は減少します。ある時点で、テストシステムはオーバーロードとなり、非ゼロの [Packet Loss (パケット損失)] 値が見られるようになります。
注
スレッドが複数の Rx キューを処理する場合、[DPDK Rx Spin Time (DPDK Rx スピン時間)] メトリックは複合統計を表します。

DPDK Rx バッチ統計ヒストグラムを使用してパケット受信を解析する
DPDK は、rte_eth_rx_burst(...) 関数を使用して NIC からパケットのバッチを受け取ります。区間 (0,MAX_NB_PKTS) の任意の数のパケットを受信できます。ここで、MAX_NB_PKTS は定数値 (通常 32) です。したがって、固定の [Rx Spin Time (Rx スピン時間)] では、コアのトラフィック処理量が大きく異なる可能性があるため、[Rx Spin Time (Rx スピン時間)] は全体像を表していません。
パケット受信のサマリー統計を表示し、Rx のコア使用率を完全に把握するには、[Summary (サマリー)] タブに切り替えて、[DPDK Rx Batch Statistics (DPDK Rx バッチ統計)] ヒストグラムを調査します。

ヒストグラムは、選択した [Port / Rx Queue / TID (ポート/Rx キュー/TID)] グループの受信バッチパケット
に関する統計を表します。この例では、すべてのピークが 4 の倍数の値を示しています。これは偶然ではなく、根本的な原因を調査するにはパケット受信の背景を理解する必要があります。

Rx 操作を理解して Rx ピークを調査する
パケットを受信するため、実行コアは Rx 記述子を介して NIC と通信します。Rx 記述子は、アドレスやサイズなどパケットに関する情報を保持するデータ構造で、Rx キューと呼ばれるリングバッファーに結合されます。簡
単に言えば、パケット受信はリングバッファー内のレースであり、NIC はリングバッファーの [Head (先頭)] に
Rx 記述子を追加し、実行コアは [Tail (末尾)] から Rx 記述子をポーリング、処理、そして解放します。

コアは Rx 記述子を解放すると、Tail ポインターを前方に移動します。Tail が Head に到達すると、
rte_eth_rx_burst() は 0 パケットを返します。逆に、Head が Tail に到達すると、Rx キューに利用可能
な Rx 記述子がなく、パケット損失が発生する可能性があります。
新しいパケットを提供するため、NIC は Rx キューの Head にある Rx 記述子を読み取り、記述子のコアで指定されたメモリーアドレスにパケットを転送します。そして、Rx 記述子を書き戻して、コアに新しいパケットの到着を通知する必要があります。

このレシピのセットアップに使用したインテル® イーサネット・コントローラー XL710 シリーズは、16 バイトと32 バイトの Rx 記述子をサポートします。どちらもキャッシュラインのサイズよりも小さいため、NIC は PCIe*
帯域幅を抑えるため整数のキャッシュラインへ Rx 記述子をパックして書き込みをまとめる、記述子の書き戻しポリシーを採用しています。主に、インテル® イーサネット・コントローラー XL710 シリーズは、次の条件を満たす場合、完了した Rx 記述子を書き戻します。
••

4 x 32 バイト の記述子または 8 x 16 バイトの記述子が完了した場合
内部 NIC キャッシュで記述子が無効にされた場合

詳細は、インテル® イーサネット・コントローラー X710/XXV710/XL710 シリーズのデータシート (英語) を参照してください。
このレシピでは、システムが 32 バイトの Rx 記述子を使用しているため、[DPDK Rx Batch Statistics(DPDK Rx バッチ統計)] のほとんどのピークは 4 の倍数になっています。
DPDK では Rx 記述子のサイズを切り替えることができます。以下は、testpmd を 32 バイトと 16 バイトのRx 記述子を使用して中程度の負荷で実行した場合の [DPDK Rx Batch Statistics (DPDK Rx バッチ統計)]の変化です。
•

32 バイトの Rx 記述子: ほとんどの rte_eth_rx_burst() 呼び出しは 4 パケットを受け取ります。

•

16 バイトの Rx 記述子: ほとんどの rte_eth_rx_burst() 呼び出しは 8 パケットを受け取ります。

関連項目
•
•
•
•

DPDK アプリケーションの PCIe*トラフィック
カスタムコレクターの使用 (英語)
外部データを含む CSV ファイルの作成 (英語)
外部データのインポート (英語)DPDK アプリケーションの PCIe*トラフィック
インテル® VTune™ Amplifier の PCIe* 帯域幅メトリックを使用して、パケット・フォワーディングを行う
DPDK ベースのアプリケーションの PCIe* トラフィックを調査します。
コンテンツ・エキスパート: Ilia Kurakin (英語)、Roman Khatko (英語)
10/40 GbE NIC を搭載したシステムで実行するデータ・プレーン・アプリケーションは通常、プラットフォーム
I/O 機能を多く利用します。特に、CPU とネットワーク・インターフェイス・カード (NIC) 間のインターフェイスである PCIe* リンクの帯域幅を集中的に消費します。このようなワークロードでは、パケット転送と通信制御のバランスを保つことにより、PCIe* リンクを効率的に利用することが重要です。PCIe* 転送を理解することは、
パフォーマンス問題の特定と解決に役立ちます。
DPDK ベースのワークロードにおける PCIe* パフォーマンス解析の方法論の詳細は、https://fd.io/wpcontent/uploads/sites/34/2018/01/performance_analysis_sw_data_planes_dec21_2017.pdf (英語) を参照してください。
このレシピでは、DPDK によるパケット・フォワーディングの段階と PCIe* 帯域幅消費の理論的な推定値を調べた後、理論的な推定値とインテル® VTune™ Amplifier で収集したデータを比較します。
1. 使用するもの
2. 手順:
a. インバウンド/アウトバウンド PCIe* 帯域幅メトリックを理解する
b. 入力と出力解析を設定して実行する
c. パケット・フォワーディングに必要な PCIe* 転送を理解する
d. PCIe* トラフィックの最適化を理解する
e. PCIe* 帯域幅消費を推定する
f. PCIe* 帯域幅とパケットレートを比較する

使用するもの
以下は、このレシピで使用するハードウェアとソフトウェアのリストです。
••

アプリケーション: シングルコアで L2 フォワーディングを実行する DPDK testpmd アプリケーショ
ン。インテル® VTune™ Amplifier のプロファイル・サポートが有効な DPDK でコンパイルされています。
パフォーマンス解析ツール:o インテル® VTune™ Amplifier 2019 Update 3: 入力と出力解析
注ooインテル® VTune™ プロファイラー評価版のダウンロードと製品サポートについては、
https://www.isus.jp/intel-vtune-amplifier-xe/ を参照してください。
このクックブックのレシピはすべてスケーラブルであり、インテル® VTune™ Amplifier 2018以降に適用できます。バージョンにより設定がわずかに異なることがあります。

ベータ版インテル® oneAPI ベース・ツールキット向けのバージョンから、インテル® VTune™
Amplifier の名称がインテル® VTune™ プロファイラーに変わりました。引き続き、インテル®
Parallel Studio XE またはインテル® System Studio のコンポーネントとして、あるいはスタ
ンドアロン版のインテル® VTune™ プロファイラーをご利用いただけます。
システムの設定: トラフィック・ジェネレーターおよび testpmd アプリケーションがパケット・フォワー
ディングを実行し、インテル® VTune™ Amplifier がパフォーマンス・データを収集する被試験システ
ム (SUT)。
o••

CPU: インテル® Xeon® Platinum 8180 プロセッサー (38.5MB キャッシュ、2.50GHz、28 コア)

インバウンド/アウトバウンド PCIe* 帯域幅メトリックを理解する
PCIe* 転送は PCIe* デバイス (NIC など) と CPU の両方により開始されます。そのため、インテル® VTune™
Amplifier は、次の帯域幅タイプで、PCIe* 帯域幅メトリックを識別します。
••[Inbound PCIe Bandwidth (インバウンド PCIe* 帯域幅)]: システムメモリーをターゲットとするデバイスのトランザクションが消費する帯域幅を示します。
o [Read (リード)]: メモリーからデバイスへの読み取りを示します。
o [Write (ライト)]: デバイスからメモリーへの書き込みを示します。
[Outbound PCIe Bandwidth (アウトバウンド PCIe* 帯域幅)]: デバイスの MMIO 空間をターゲッ
トとする CPU のトランザクションが消費する帯域幅を示します。
o [Read (リード)]: デバイスの MMIO 空間から CPU への読み取りを示します。
o [Write (ライト)]: CPU からデバイスの MMIO 空間への書き込みを示します。

入力と出力解析を設定して実行する[Inbound PCIe Bandwidth (インバウンド PCIe* 帯域幅)] および [Outbound PCIe Bandwidth (アウトバウンド PCIe* 帯域幅)] データを収集するには、入力と出力解析を使用します。
GUI で、プロジェクトを作成し、[HOW (どのように)] ペインで [Input and Output (入力と出力)] 解析を選択して、[Analyze PCIe bandwidth (PCIe* 帯域幅を解析)] オプションを有効にします。

コマンドラインで、collect-pcie-bandwidth knob (デフォルトで true に設定) を使用します。例えば、次のコマンドは DPDK メトリックを使用して PCIe* 帯域幅データの収集を開始します。
amplxe-cl -collect io -knob kernel-stack=false -knob dpdk=true -knob collectmemory-bandwidth=false --target-process my_process
結果が収集されたら、GUI で [Platform (プラットフォーム)] タブに移動し、[Inbound PCIe Bandwidth (インバウンド PCIe* 帯域幅)] および [Outbound PCIe Bandwidth (アウトバウンド PCIe* 帯域幅)] セクションに注目します。
注
インテル® マイクロアーキテクチャー開発コード名 Skylake 以降のサーバー・プラットフォームでは、デバイス
ごとに PCIe* 帯域幅メトリックを収集できます。root 権限が必要です。

パケット・フォワーディングに必要な PCIe* 転送を理解する
DPDK によるパケット・フォワーディングは、パケットを受信 (rx_burst DPDK ルーチン) した後に、パケットを送信 (tx_burst) します。「DPDK アプリケーションのコア使用率」レシピの、Rx 記述子を含む Rx キューを利用したパケット受信の詳細が参考になります。DPDK によるパケット送信はパケット受信と同じように動作します。パケットを受信するため、実行コアは Tx 記述子 (パケットアドレス、サイズ、その他の制御情報を格納する 16 バイトのデータ構造) を使用します。Tx 記述子のバッファーは連続するメモリーのコアにより割り当て
られ、Tx キューと呼ばれます。Tx キューはリングバッファーとして処理され、長さ、Head、Tail で定義されます。Tx キューからのパケット送信はパケット受信に非常に似ています。コアは Tx キューの Tail で新しい Tx
記述子を準備し、NIC は Head から処理します。
Rx キューと Tx キューの Tail ポインターは、新しい記述子が利用可能であることを通知するため、ソフトウェ
アにより更新されます。Tail ポインターは MMIO 空間にマップされる NIC レジスターに格納されます。つまり、Tail ポインターはアウトバウンド書き込み (MMIO 書き込み) で更新されます。MMIO アドレス空間はキャッシュできないため、アウトバウンド書き込みとアウトバウンド読み取りには非常にコストがかかります。
そのため、これらのトランザクションは最小限にするべきです。
パケット・フォワーディングを行う場合、PCIe* トランザクションのワークフローは次のようになります。
1.
2.
3.
4.

コアが Rx キューを準備して、Rx キューの Tail のポーリングを開始します。
NIC が Rx キューの Head の Rx 記述子を読み取ります (インバウンド・リード)。
NIC が Rx 記述子で指定されたアドレスにパケットを送ります (インバウンド・ライト)。
NIC が Rx 記述子を書き戻して、コアに新しいパケットが到着したことを通知します (インバウンド・ラ
イト)。
5. コアがパケットを処理します。
6. コアが Rx 記述子を解放して、Rx キューの Tail ポインターを移動します (アウトバウンド・ライト)。
7. コアが Tx キューの Tail の Tx 記述子を更新します。
8. コアが Tx キューの Tail ポインターを移動します (アウトバウンド・ライト)。
9. NIC が Tx 記述子を読み取ります (インバウンド・リード)。
10. NIC がパケットを読み取ります (インバウンド・リード)。
11. NIC が Tx 記述子を書き戻して、コアにパケットが送信され Tx 記述子を解放できることを通知します(インバウンド・ライト)。

PCIe* トラフィックの最適化を理解する
最大パケットレートを増やしてレイテンシーを軽減するため、DPDK は次の最適化を使用します。
••

アウトバウンド・リードを行わない。Rx および Tx キューの Head の位置を把握するためにコストのかかるアウトバウンド・リード (MMIO 読み取り) を行いません。代わりに、NIC は Rx および Tx 記述子を書き戻してソフトウェアに Head の位置が移動したことを通知します。
Tx 記述子に関連するインバウンド・ライト帯域幅を減らす。コアに Tx キューの Head の位置と再利用できる Tx 記述子を通知するには Tx 記述子の書き戻しが必要です。パケット受信では、できるだけ
早く Rx 記述子を書き戻してコアに新しく到着したパケットの情報を通知することが重要です。パケッ
ト送信では、Tx 記述子を書き戻す必要はありません。コアにパケット送信の成功を定期的に (例えば、
32 パケットごとに) 通知すれば、その前のすべてのパケットも正常に送信されたことが伝わります。
NIC は Tx 記述子の RS (レポートステータス) ビットがセットされると Tx 記述子を書き戻します。

•

DPDK 側には、RS ビットしきい値 (英語) があります。この値は、RS ビットがセットされる頻度、つまりNIC が TX 記述子を書き戻す頻度を定義します。この最適化は、Tx 記述子に関連するインバウンド・ラ
イトを減らします。
アウトバウンド・ライトを平均化する。DPDK はパケット受信と送信をバッチで行い、アプリケーション
はパケットのバッチが処理された後に Tail ポインターを更新します。rx_burst の一部の実装は、Rx
解放しきい値 (英語) を使用しています。このしきい値を使用すると、アプリケーションが Rx キューのTail ポインターを更新する前に処理される Rx 記述子の数を設定できます (このしきい値はバッチサ
イズよりも大きい場合にのみ有効になることに注意してください)。アウトバウンド書き込みはパケッ
ト間で平均化されます。

プラットフォーム・レベルでは、トランザクションはキャッシュラインの粒度で行われるため、ハードウェアは、
常に読み取りと書き込みをまとめて、一部のキャッシュラインが転送されないように試みます。

PCIe* 帯域幅消費を推定する
最適化されたパケット・フォワーディングは、次の式を適用して指定されたパケットレートの PCIe* 帯域幅消費を推定できます。

上記のアウトバウンド・ライト帯域幅の式は、パケットが同じサイズのバッチで処理された場合にのみ有効です。パケットが複数のサイズのバッチで送信された場合、式の精度は低くなります。
単純なフォワーディングでは、コアは受信したパケットをすべて送信します。testpmd は完了までまとめて実行するモデルで設計されたアプリケーションであるため、tx_burst は rx_burst と同じパケットのバッチで動作すると推測できます。つまり、[DPDK Rx Batch Statistics (DPDK Rx バッチ統計)] (「DPDK アプリケー
ションのコア使用率」レシピを参照) はパケット受信とパケット送信の両方の統計値を反映します。そのため、[DPDK Rx Batch Statistics (DPDK Rx バッチ統計)] を使用して汎用的なケースのアウトバウンド・ライト帯域幅を推定できます。
Tx バッチサイズの代わりに、「平均」Tx バッチサイズを考えます。

ここで、 はバッチサイズ、は rx_burst 呼び出しの回数 (バッチサイズ )、Batch Statistics (DPDK Rx バッチ統計)] の i 番目のピークのパケット数、は [DPDK Rxはフォワードされたパケットの総数です。次の図はこの計算の例です。この例では、バッチ統計にはバッチサイズ 8、10、12 の 3 つのピークがあり、計算された平均バッチサイズは 11 です。

単純にするため、Rx 解放のしきい値がその最大 Rx バッチサイズよりも大きいと考えます。アウトバウンド・ラ
イト帯域幅の最終的な計算は次のようになります。

推定値と解析結果を比較する
次の 2 つの図は、下記の表にリストされた値で設定された testpmd アプリケーションの、PCIe* 帯域幅の理論的な推定値とインテル® VTune™ Amplifier で収集された PCIe* 帯域幅を示しています。

パケットサイズ、B

64

Rx 記述子サイズ、B 32
RS ビットしきい値

32

Rx 解放しきい値

32

アウトバウンド・ライトの値はほぼ中央のポイントから低下しています。この低下は、処理するパケット数の増加による [DPDK Rx Batch Statistics (DPDK Rx バッチ統計)] の変更が原因です。このポイント以前は[DPDK Rx Batch Statistics (DPDK Rx バッチ統計)] にはバッチサイズ 0 と 4 の 2 つのピークがあり、このポイント以降はバッチサイズ 8 に新しいピークが現れています (下記の 2 つのヒストグラムを参照)。上記の式に当てはめると、平均バッチサイズは増え、アウトバウンド・ライト帯域幅は減ります。
10 Mpps:

13 Mpps:

式で考慮していない要素が原因と思われる多少の違いはありますが、概して、理論的な推定値はインテル®
VTune™ Amplifier でレポートされたデータに非常に近くなっています。
このレシピで使用したデータ・プレーン・アプリケーションは、すでに適切に最適化されていました。しかし、実際のアプリケーションで I/O 中心のパフォーマンス解析を行う際は、このレシピを利用することを推奨します。

関連項目
•
•
•

i40e ドライバーの 16/32 バイト Rx 記述子の切り替え (英語)
testpmd で利用可能なしきい値およびしきい値の変更方法 (英語)https://fd.io/wp-content/uploads/sites/34/2018/01/performance_analysis_sw_data_
planes_dec21_2017.pdf (英語)設定レシピ
特定のコード環境でパフォーマンス解析を行うため、システムとベータ版インテル® VTune™ プロファイラーと従来のインテル® VTune™ Amplifier を設定する方法を詳しく説明します。
•

•

•

•

•

•

•

•

•

•

•

CPU と FPGA (インテル® Arria® 10 GX) の相互作用を解析する
このレシピは、インテル® Arria® 10 GX FPGA を例として、CPU と FPGA の相互作用を解析するため
プラットフォームを設定する方法を説明します。
.NET Core アプリケーションのプロファイル
このレシピは、インテル® VTune™ Amplifier を使用して .NET Core ダイナミックコードをプロファイ
ルし、マネージドコードの hotspot を特定してパフォーマンスが向上するようにアプリケーションを最適化します。
Amazon Web Services* (AWS*) EC2* インスタンス上のアプリケーションのプロファイル
このレシピは、インテル® VTune™ プロファイラーを使用してパフォーマンスをプロファイルするため、
AWS* で VM インスタンスを設定します。
GitLab* CI でパフォーマンスをプロファイルする
このレシピは、インテル® VTune™ プロファイラーを GitLab* CI パイプラインに統合して、ビルドをプ
ロファイルする方法を説明します。
ハードウェアベースの hotspot 解析向けに Hyper-V* 仮想マシンを設定する
このレシピは、インテル® VTune™ プロファイラーを使用してハードウェア・パフォーマンスをプロファイルするため、Hyper-V* 環境で仮想マシン・インスタンスを設定します。
DPC++ アプリケーションのプロファイル
このレシピは、DPC++ (データ並列 C++) アプリケーションを作成してコンパイルする方法を紹介します。また、インテル® VTune™ プロファイラーを使用して DPC++ アプリケーションの GPU 解析を実行
し、結果を検証する方法も示します。
FPGA 上での DPC++ アプリケーションのプロファイル
このレシピは、FPGA 上で DPC++ (データ並列 C++) アプリケーションをプロファイルします。このレ
シピでは、インテル® VTune™ プロファイラーの CPU/FPGA 相互作用解析タイプ (プレビュー機能)に統合されている AOCL プロファイラーを使用します。
インテルのサンプリング・ドライバーを使用しないハードウェアのプロファイル
この一連のレシピは、インテル® VTune™ プロファイラーでドライバーを使用しない Linux* perf ベースのパフォーマンス・プロファイルを設定して、その利点と制限に対する回避策を理解するのに役立ちます。
MPI アプリケーションのプロファイル
このレシピは、インテル® VTune™ Amplifier を使用して MPI アプリケーションのインバランスと通信の問題を特定し、アプリケーション・パフォーマンスを向上します。
Node.js* の JavaScript* コードのプロファイル
このレシピは、Node.js* をリビルドし、インテル® VTune™ プロファイラーを使用して、JavaScript*
フレームとネイティブフレーム (ネイティブコード、例えば、JavaScript* コードから呼び出されたシス
テム・ライブラリーやネイティブ・ライブラリー) から成る混在モードのコールスタックを含む
JavaScript* コードのパフォーマンスを解析するための設定手順を説明します。
Docker* コンテナーでのプロファイル
このレシピは、インテル® VTune™ Amplifier の解析向けに Docker* コンテナーを構成して、独立したコンテナー環境で動作しているアプリケーションの hotspot を特定します。

•

•

•

Singularity* コンテナーでのプロファイル
このレシピは、インテル® VTune™ Amplifier の解析向けに Singularity* コンテナーを構成して、独立したコンテナー環境で動作しているアプリケーションの hotspot を特定します。
Linux*、Android*、および QNX* のシステムブート時のプロファイル
このレシピは、インテル® VTune™ Amplifier のパフォーマンス解析を Linux*、Android*、およびQNX* オペレーティング・システムのブートフローと統合する方法を示します。この解析は、OS ブート
時に CPU コアで予想外に長く実行されるアクティビティーを識別するのに役立ちます。これにより、ブート順序のさらに詳しい調査が可能になります。
システム・アナライザーによるリアルタイム・モニタリング
このレシピは、システム・アナライザーの概要を紹介し、ターゲットシステムをリアルタイムにモニタリングして、CPU、GPU、メモリー、ディスク、ネットワークによる制限を特定します。

CPU と FPGA (インテル® Arria® 10 GX) の相互作用を解析する
このレシピは、インテル® Arria® 10 GX FPGA を例として、CPU と FPGA の相互作用を解析するためプラット
フォームを設定する方法を説明します。
コンテンツ・エキスパート: JONG IL P. (英語)、Vitaly Slobodskoy (英語)••使用するもの手順:
1. インテル® Arria® 10 GX FPGA とインテル® FPGA SDK for OpenCL* を設定する
2. サンプル・アプリケーションをビルドして FPGA へフラッシュする
3. CPU/FPGA 相互作用解析を実行する
4. 結果を解釈する使用するもの
以下は、パフォーマンス解析シナリオで使用するハードウェアとソフトウェアのリストです。
••

アプリケーション: 行列乗算 OpenCL* アプリケーション。行列乗算サンプル・アプリケーションは、インテル® FPGA SDK for OpenCL* ウェブサイトからダウンロードできます。
ツール: インテル® FPGA SDK for OpenCL*、インテル® VTune™ Amplifier 2019 以降
注
インテル® VTune™ プロファイラー評価版のダウンロードと製品サポートについては、
https://www.isus.jp/intel-vtune-amplifier-xe/ を参照してください。
o このクックブックのレシピはすべてスケーラブルであり、インテル® VTune™ Amplifier 2018以降に適用できます。バージョンにより設定がわずかに異なることがあります。
o ベータ版インテル® oneAPI ベース・ツールキット向けのバージョンから、インテル® VTune™
Amplifier の名称がインテル® VTune™ プロファイラーに変わりました。引き続き、インテル®
Parallel Studio XE またはインテル® System Studio のコンポーネントとして、あるいはスタ
ンドアロン版のインテル® VTune™ プロファイラーをご利用いただけます。
オペレーティング・システム: CentOS* 7、Red Hat* Enterprise Linux* 7 以降
CPU: インテル® サーバー・プラットフォーム (開発コード名 Skylake)
FPGA: インテル® Arria® 10 GX
o

•
•
•

インテル® Arria® 10 GX FPGA とインテル® FPGA SDK for OpenCL* を設定する
1. インテル® Arria® 10 GX FPGA で DIP スイッチを設定して、電源と USB ケーブルを接続します。詳細な手順 (英語) をご覧ください。
2. インテル® FPGA SDK for OpenCL* (コードビルダー、インテル® Quartus® Prime ソフトウェア、デバイスを含む) を http://fpgasoftware.intel.com/opencl/ (英語) からダウンロードします。
3. setup_pro.sh ファイルを実行して SDK をインストールします。
4. source init_opencl.sh を実行して適切な環境変数を設定します。

5. aocl version を実行して正しくインストールされたことを確認します。次のようなメッセージが出力されます。
aocl 17.1.0.240 (Intel(R) FPGA SDK for OpenCL(TM), Version 17.1.0 Build
240, Copyright (C) 2017 Intel Corporation)
6. aocl install を実行して FPGA ボードをインストールします。
7. aocl diagnose を実行してハードウェアが正しくインストールされたことを確認します。次のようなメッセージが出力されます。
Device Name:
acl0
Package Pat:
/home/tce/intelFPGA_pro/17.1/hld/board/a10_ref
Vendor: Intel(R) Corporation
Phys Dev Name

StatusInformation

acla10_ref0

PassedArria 10 Reference Platform (acla10_ref0)
PCIe dev_id = 2494, bus:slot.func = 44:00.00,

Gen3 x4
FPGA temperature = 44.3555 degrees C.
DIAGNOSTIC_PASSED

サンプル・アプリケーションをビルドして FPGA へフラッシュする
1. デフォルトの makefile で make を実行してホストの実行ファイルをビルドします。生成される実行ファイルの名前は host です。
2. 次のコマンドで FPGA 向けのバイナリーをビルドします。
aoc -v -board=a10gx device/matrix_mult.cl -o bin/ matrix_mult.aocx
3. フラッシュの USB ドライバーを設定します。
a. 次のコマンドを実行します。
sudo vim /etc/udev/rules.d/51-usbblaster.rules
次の行を追加します。
# usb blaster
SUBSYSTEM=="usb", ENV{DEVTYPE}=="usb_device",
ATTRS{idVendor}=="09fb", ATTRS{idProduct}=="6001", MODE="0666",
NAME="bus/usb/$env{BUSNUM}/$env{DEVNUM}", RUN+="/bin/chmod
0666 %c"
SUBSYSTEM=="usb", ENV{DEVTYPE}=="usb_device",
ATTRS{idVendor}=="09fb", ATTRS{idProduct}=="6002", MODE="0666",
NAME="bus/usb/$env{BUSNUM}/$env{DEVNUM}", RUN+="/bin/chmod
0666 %c"
SUBSYSTEM=="usb", ENV{DEVTYPE}=="usb_device",
ATTRS{idVendor}=="09fb", ATTRS{idProduct}=="6003", MODE="0666",

NAME="bus/usb/$env{BUSNUM}/$env{DEVNUM}", RUN+="/bin/chmod
0666 %c"
SUBSYSTEM=="usb", ENV{DEVTYPE}=="usb_device",
ATTRS{idVendor}=="09fb", ATTRS{idProduct}=="6010", MODE="0666",
NAME="bus/usb/$env{BUSNUM}/$env{DEVNUM}", RUN+="/bin/chmod
0666 %c"
SUBSYSTEM=="usb", ENV{DEVTYPE}=="usb_device",
ATTRS{idVendor}=="09fb", ATTRS{idProduct}=="6810", MODE="0666",
NAME="bus/usb/$env{BUSNUM}/$env{DEVNUM}", RUN+="/bin/chmod
0666 %c"
4. 次のコマンドで JTAG のクロック速度を 6MHz に設定します。
jtagconfig --setparam 1 JtagClock 6M
5. 次のコマンドでバイナリーを FPGA へフラッシュします。
aocl flash acl0 ./bin/matrix_mult.aocx
6. FPGA を搭載したホストシステムを再起動します。

CPU/FPGA 相互作用解析を実行する
1. インテル® VTune™ Amplifier を起動します。次に例を示します。
/opt/intel/vtune_amplifier_2019/bin64/amplxe-gui
2. 解析用のプロジェクト (例: hello_world_opencl) を作成します。
3. [Configure Analysis (解析の設定)] をクリックして新しい解析を開始します。
4. [CPU/FPGA Interaction (CPU/FPGA 相互作用)] 解析を設定します。

a. [WHERE (どこを)] ペインでは、[Local Host (ローカルホスト)] ターゲット・システム・タイプ
を選択します。
b. [WHAT (何を)] ペインで、[Launch Application (アプリケーションを起動)] ターゲットタイ
プを選択して、hello world アプリケーションを指定します。通常、このアプリケーションは<sample app>/bin/host にあります。
c. [HOW (どのように)] ペインで、解析タイプから [CPU/FPGA Interaction (CPU/FPGA 相互作用)] を選択します。
5. [Start (開始)] をクリックして解析を開始します。

結果を解釈するデータ収集が完了すると、結果がファイナライズされ [CPU/FPGA Interaction (CPU/FPGA 相互作用)]
ビューポイントに表示されます。FPGA の上位の計算タスクや CPU の上位のタスクと hotspot が表示される[Summary (サマリー)] タブから始めます。

[Bottom-up (ボトムアップ)] タブに切り替えて計算タスクのワークサイズとデータ転送スループットを確認します。[Timeline (タイムライン)] ペインで計算タスクとデータ転送の FPGA 使用率を確認します。

[Platform (プラットフォーム)] タブで FPGA とホスト・アプリケーションの計算キューを確認します。各転送と同期の開始時間と継続期間に関する情報も表示されます。

関連項目•

CPU/FPGA 相互作用解析 (英語).NET Core アプリケーションのプロファイル
このレシピは、インテル® VTune™ Amplifier を使用して .NET Core ダイナミックコードをプロファイルし、マネージドコードの hotspot を特定してパフォーマンスが向上するようにアプリケーションを最適化します。
コンテンツ・エキスパート: Denis Pravdin (英語)••使用するもの手順:
1. アプリケーションを準備する
2. 高度な hotspot 解析を実行する
3. マネージドコードの hotspot を特定する
4. ループ交換を使用してコードを最適化する
5. 最適化を確認する

使用するもの
以下は、パフォーマンス解析シナリオで使用するハードウェアとソフトウェアのリストです。
••

アプリケーション: 整数リストのすべての要素を加算するサンプル C# アプリケーション。このアプリ
ケーションはデモ用であり、ダウンロードすることはできません。
ツール:o インテル® VTune™Amplifier 2018注インテル® VTune™ プロファイラー評価版のダウンロードと製品サポートについては、https://www.isus.jp/intel-vtune-amplifier-xe/ を参照してください。
▪ このクックブックのレシピはすべてスケーラブルであり、インテル® VTune™
Amplifier 2018 以降に適用できます。バージョンにより設定がわずかに異なることがあります。
▪ ベータ版インテル® oneAPI ベース・ツールキット向けのバージョンから、インテル®
VTune™ Amplifier の名称がインテル® VTune™ プロファイラーに変わりました。引
き続き、インテル® Parallel Studio XE またはインテル® System Studio のコンポー
ネントとして、あるいはスタンドアロン版のインテル® VTune™ プロファイラーをご利用いただけます。
o .NET Core 2.0 SDK (英語)
オペレーティング・システム: Microsoft* Windows* 10
CPU: インテル® プロセッサー (開発コード名 Skylake)▪

••

アプリケーションを準備する
1. .NET 環境変数が設定された新しいコマンドウィンドウを開き、.NET Core 2.0 が正しくインストール
されていることを確認します。
dotnet --version

2. アプリケーションの新しい listadd ディレクトリーを作成します。
mkdir C:\listadd> cd C:\listadd
3. dotnet new console と入力して、次の構造の新しいスケルトン・プロジェクトを作成します。

4. listadd フォルダーの Program.cs の内容を、整数リストの要素を加算する C# コードに変更します。
using System;
using System.Linq;
using System.Collections.Generic;namespace listadd{
class Program{
static void Main(string[] args){
Console.WriteLine("Starting calculation...");
List<int> numbers = Enumerable.Range(1,10000).ToList();for (int i =0; i < 100000; i ++){ListAdd(numbers);}
Console.WriteLine("Calculation complete");}static int ListAdd(List<int> candidateList){
int result = 0;
foreach (int item in candidateList){
result += item;}
return result;}}}
5. listadd.csproj ファイルの PropertyGroup セクションに<DebugType>pdbonly</DebugType> フラグを追加してインテル® VTune™ Amplifier のソース
コード解析を有効にします。
6. C:\listadd\bin\Release\netcoreapp2.0 フォルダーに listadd.dll を作成します。
dotnet build -c Release
7. サンプル・アプリケーションを実行します。
dotnet C:\listadd\bin\Release\netcoreapp2.0\listadd.dll

高度な hotspot 解析を実行する
1. 管理者権限でインテル® VTune™ Amplifier を起動します。
2. ツールバーの[New Project (新規プロジェクト)] ボタンをクリックして、新規プロジェクトの名
前 (例: dotnet) を指定します。
3. [Analysis Target (解析ターゲット)] ウィンドウで、左ペインから [local host (ローカルホスト)] および [Launch Application (アプリケーションを起動)] ターゲットタイプを選択します。
4. [Launch Application (アプリケーションを起動)] ペインで、解析するアプリケーションを指定します。
o アプリケーション: C:\Program Files\dotnet\dotnet.exe
o アプリケーションのパラメーター:
C:\listadd\bin\Release\netcoreapp2.0\listadd.dll

注dotnet.exe の場所は環境変数に依存します。where dotnet コマンドを使用して確認できます。
5. 右の [Choose Analysis (解析の選択)] ボタンをクリックして、左ペインから [Advanced Hotspots(高度な hotspot)] 解析を選択します。
注
高度な hotspot 解析は、インテル® VTune™ Amplifier 2019 で汎用の hotspot 解析 (英語) に統合されました。ハードウェア・イベントベース・サンプリング収集モードで利用できます。
6. [Start (開始)] をクリックして解析を開始します。

マネージドコードの hotspot を特定する収集した解析結果が表示されたら、[Bottom-up (ボトムアップ)] タブに切り替えて[Process/Module/Function/Thread/Call Stack (プロセス/モジュール/関数/スレッド/コールスタック)]
グループを選択します。

dotnet.exe > listadd.dll を展開して、最も CPU 時間がかかっているマネージド
listadd::Program::ListAdd 関数を見つけます。

この hotspot 関数をダブルクリックして [Source (ソース)] ビューを開きます。ソースと逆アセンブルした
コードを並べて表示するには、ツールバーの [Assembly (アセンブリー)] ボタンをクリックします。

ソース行/アセンブリー命令ごとの統計を使用して、最も時間を費やしているコード部分 (上記の例では行 24)
を特定します。

ループ交換を使用してコードを最適化する
インテル® VTune™ Amplifier は、次のコード行をパフォーマンス・クリティカルとしてハイライトします。
foreach (int item in candidateList)for ループ文を使用してコードを最適化します。Program.cs の内容を次のように変更します。
using System;
using System.Linq;
using System.Collections.Generic;namespace listadd{
class Program{
static void Main(string[] args){
Console.WriteLine("Starting calculation...");
List<int> numbers = Enumerable.Range(1,10000).ToList();for (int i =0; i < 100000; i ++){ListAdd(numbers);}
Console.WriteLine("Calculation complete");}static int ListAdd(List<int> candidateList){
int result = 0;
for (int i = 0; i < candidateList.Count; i++){result += candidateList[i];}return result;}}}

最適化を確認する
更新したコードの最適化を確認するため、高度な hotspot 解析を再度実行します。
最適化前は、サンプル・アプリケーションの CPU 時間は 2.636 秒でした。

最適化後は、サンプル・アプリケーションの CPU 時間が 0.945 秒になり、オリジナルから約 64% パフォーマンスが向上しました。

注
このレシピの情報は、デベロッパー・フォーラム (英語) を参照してください。

関連項目•.NET コード解析 (英語)Amazon Web Services* (AWS*) EC2* インスタンス上のア
プリケーションのプロファイル
このレシピは、インテル® VTune™ プロファイラーを使用してパフォーマンスをプロファイルするため、AWS*
で VM インスタンスを設定します。
コンテンツ・エキスパート: Denis Pravdin (英語)、Jennifer Dimatteo••

使用するもの手順:
1. 仮想マシン・インスタンスを作成して設定する
2. EC2* インスタンスに接続する
3. プロファイル向けにインスタンスを設定する
4. hotspot 解析を実行する

使用するもの
以下は、パフォーマンス解析シナリオで使用するハードウェアとソフトウェアのリストです。
••

アプリケーション: matrix。このアプリケーションはデモ用であり、ダウンロードすることはできません。
ツール: ベータ版インテル® VTune™ プロファイラーまたはインテル® VTune™ Amplifier 2019 hotspot 解析
注oooインテル® VTune™ プロファイラー評価版のダウンロードと製品サポートについては、
https://www.isus.jp/intel-vtune-amplifier-xe/ を参照してください。
このクックブックのレシピはすべてスケーラブルであり、インテル® VTune™ Amplifier 2018以降に適用できます。バージョンにより設定がわずかに異なることがあります。
ベータ版インテル® oneAPI ベース・ツールキット向けのバージョンから、インテル® VTune™
Amplifier の名称がインテル® VTune™ プロファイラーに変わりました。引き続き、インテル®
Parallel Studio XE またはインテル® System Studio のコンポーネントとして、あるいはスタ
ンドアロン版のインテル® VTune™ プロファイラーをご利用いただけます。

仮想マシン・インスタンスを作成して設定する
1. AWS* サイトで [アカウント (Account)] > [AWS マネジメントコンソール (AWS Management
Console)] からアカウントにログインします。
アカウントをお持ちでない場合は、作成してください。
2. Amazon EC2* ダッシュボードで [Compute (コンピューティング)] > [EC2] を選択します。

3. [Launch Instance (インスタンスの作成)] をクリックして、ウィザードに従って仮想マシンを作成し設定します。

設定ウィザードでは、使用するケースに応じて OS とインスタンスの仕様 (CPU の数、メモリー、スト
レージ、ネットワーク容量) を指定できます。
4. [Step 1: Choose an Amazon Machine Image (AMI) (ステップ 1: Amazon マシンイメージ(AMI))] では、Ubuntu* Server 18.04 LTS を選択します。

5. [Step 2: Choose an Instance Type (ステップ 2: インスタンスタイプの選択)] では、インスタンスを選択して [Next: Configure Instance Details (次の手順: インスタンスの詳細の設定)] をクリックします。

注インテル® VTune™ プロファイラーの推奨システム要件は 4GB RAM、空きディスク容量 10GB 以上です。
6. [Step 3: Configure Instance Details (ステップ 3: インスタンスの詳細の設定)] では、[Autoassign Public IP (自動割り当てパブリック IP)] を有効にして [Next: Add Storage (次の手順: スト
レージの追加)] をクリックします。

7. [Step 4: Add Storage (ステップ 4: ストレージの追加)] では、ストレージデバイスの容量を増やしてから [Next: Add Tags (次の手順: タグの追加)] をクリックします。

8. (オプション) [Step 5: Add Tags (ステップ 5: インスタンスのタグ付け)] では、タグ (例えば VTune
Demo) を追加して [Review and Launch (確認と作成)] をクリックします。

9. [Step 7: Review Instance Launch (ステップ 7: インスタンス作成の確認)] では、[Launch (作成)]をクリックします。

10. キーペアを作成します。

a. [Create a new key pair (新しいキーペアの作成)] を選択して、名前 (例えばMyEC2Instance) を割り当てます。
b. [Download Key Pair (キーペアのダウンロード)] をクリックして、キーをダウンロードします。
c. [Launch Instances (インスタンスの作成)] をクリックして、セットアップを完了します。
インスタンスが作成されます。
11. [View Instances (インスタンスの表示)] をクリックします。
[Instance State (インスタンスの状態)] が [running] に更新されたら次のステップに進みます。

EC2* インスタンスに接続する作成した EC2* インスタンスを選択し、[Connect (接続)] をクリックしてインスタンスへ SSH 接続します。

PuTTY* は、Amazon EC2* によって生成されるプライベート・キー形式 (.pem) をネイティブにサポートしません。PuTTY* を使用してインスタンスに接続する前に、PuTTYgen を使用してプライベート・キー (.pem) を必
要な PuTTY* 形式 (.ppk) に変換する必要があります。
1. プライベート・キーを変換します。
a. PuTTYgen を起動します。
b. [Type of key to generate] で [SSH-1 (RSA)] を選択します。
c. [Load] をクリックして .pem ファイルを選択します。
d. [Save private key] をクリックして PuTTY* が使用可能な形式でキーを保存します。
2. PuTTY* を起動して、[Connection] > [SSH] > [Auth] でインスタンスのパブリック DNS とプライ
ベート・キー (.ppk) ファイルを指定します。

3. 設定を保存して、[Open] をクリックします。
インスタンスにログインします。
注
実行中のインスタンスに Xubuntu* デスクトップをインストールする必要があります。VNC* 経由でシステムにアクセスする場合は、VNC* サーバーのセットアップも必要です。

プロファイル向けにインスタンスを設定する/proc/sys/kernel/yama/ptrace_scope を 0 に設定して、プロファイル向けにターゲット・インスタン
スを準備します。
echo 0 | sudo tee /proc/sys/kernel/yama/ptrace_scope

hotspot 解析を実行する
次の任意の方法で hotspot 解析を実行します。
SSH 経由でローカルにインストールされたインテル® VTune™ プロファイラーからリモート収集を実行:
注
リモート・ハードウェア・イベントベース・サンプリング解析は、ベアメタル・インフラストラクチャーとインテル®
VTune™ プロファイラーのすべてのプロファイル機能に直接アクセス可能な EC2* ベアメタル・インスタンス(i3.metal インスタンス・ファミリー) を除き、AWS* EC2* 仮想環境では利用できません。
1. インテル® VTune™ プロファイラーでプロジェクトを作成します。
[Configure Analysis (解析の設定)] ウィンドウが表示されます。
2. [WHERE (どこを)] ペインでは、[Remote Linux (SSH) (リモート Linux* (SSH))] を選択して、[SSH
destination (SSH の対象)] に ubuntu@<PuTTY* 設定の名前> と入力します。
この時点でインテル® VTune™ プロファイラーはリモートシステムに接続して、収集に必要なバイナリーを指定されたフォルダーにインストールしようとします。
3. [WHAT (何を)] ペインでは、アプリケーションの場所と作業ディレクトリーを指定します。
4. [HOW (どのように)] ペインでは、デフォルトで表示される hotspot 解析の [User-Mode Sampling(ユーザーモード・サンプリング)] を選択します。
5.

をクリックして、解析を開始します。
結果は、解析のため自動的にローカルシステムにコピーされます。

AWS* インスタンスから直接インテル® VTune™ プロファイラーを実行:
1. 「インストール・ガイド」 (英語) に従って、インテル® VTune™ プロファイラーをインストールします。
2. インテル® VTune™ プロファイラーを実行します。次に例を示します。
sudo <vtune_install_dir>/vtune_profiler/bin64/vtune-gui
3. プロジェクトを作成します。
[Configure Analysis (解析の設定)] ウィンドウが表示されます。
4. [WHERE (どこを)] ペインでは、[Local Host (ローカルホスト)] ターゲット・システム・タイプを選択します。
5. [WHAT (何を)] ペインでは、アプリケーションの場所と作業ディレクトリーを指定します。
6. [HOW (どのように)] ペインでは、[Hardware Event-Based Sampling (ハードウェア・イベントベー
ス・サンプリング)] など、hotspot 解析の収集モードを選択します。
7.

をクリックして、解析を開始します。
解析結果は、デフォルトの [Hotspots by CPU Utilization (CPU 使用率によるホットスポット)]
ビューポイントに表示されます。

関連項目
•
•
•

仮想環境のターゲット (英語)
パフォーマンス解析 (英語)
リモート収集向けに SSH アクセスを設定 (英語)GitLab* CI でパフォーマンスをプロファイルする
このレシピは、インテル® VTune™ プロファイラーを GitLab* CI パイプラインに統合して、ビルドをプロファイ
ルする方法を説明します。
コンテンツ・エキスパート: Dmitry Sivkov (英語)
このレシピでは、インテル® VTune™ プロファイラーを GitLab* Continuous Integration (CI) パイプラインに統合することでビルドを自動プロファイルする方法と、インテル® VTune™ プロファイラーの静的な HTML レ
ポート機能を使用して最新のパフォーマンス解析データへのアクセスをより便利にする方法を示します。
このアプローチは、次の利点をもたらします。
•

自動パフォーマンス解析: パフォーマンス・リグレッションが検出された場合、テスト環境を設定して手動でパフォーマンス結果を収集することは、単調な作業であり、エンジニアの貴重な時間を消費してしまいます。インテル® VTune™ プロファイラーを GitLab* CI パイプラインのテストステージに統合することで、あらかじめ設定した環境でパフォーマンス・データを自動収集して、結果を自動的にアーティ
ファクトとしてアップロードできます。
これにより、手作業を省き、ビルド完了時にパフォーマンス結果を利用できるようにすることで、リグ
レッションの原因究明に専念できます。

•

カスタム設定: インテル® VTune™ プロファイラーのコマンドライン・インターフェイス (CLI) 機能 (英語) は、柔軟な CI 統合を提供します。インテル® VTune™ プロファイラー の CLI を使用することで、例
えば、チームのニーズに合わせて、必要な解析タイプとパラメーターを選択してカスタムプロセスをセットアップできます。
以下は、いくつかの設定例です。
ビルドごとにホットスポット解析 (英語) を自動実行します。
ビルドシステムの負荷テストステージでパフォーマンス・リグレッションが検出された場合のみ新しいビルドをプロファイルして、すべての必要な解析タイプのパフォーマンス・データを収集し
ます。

o
o

•

HTML 解析レポート: インテル® VTune™ プロファイラーには、収集結果のサマリーを含む静的なHTML レポートを生成するコマンドライン・オプション (英語) が用意されています。この HTML レポー
トをブラウザーで表示して、追加の解析が必要かどうかを判断できます。オプションで、この HTML レ
ポートを便利な GitLab* ページとしてホストすることもできます。
••

使用するもの手順:
1. GitLab* Runner をインストールする
2. 自動データ収集を設定する
3. 結果の自動アップロードを設定する
4. 結果データを表示する
5. (オプション) 新たに発生した問題を解決する

使用するもの
以下は、パフォーマンス解析シナリオで使用するソフトウェアのリストです。
••

インフラストラクチャー: 以下を含む、GitLab* CI パイプラインを設定済みの GitLab* リポジトリー:
o プロジェクトの Makefile
o 事前設定済みの .gitlab-ci.yml ファイルo インテル® VTune™ プロファイラーがインストールされた GitLab* Runner
ツール: インテル® VTune™ プロファイラー 2020 (スタンドアロンまたはインテル® Parallel Studio
XE/インテル® System Studio に含まれるもの)。
注oooインテル® VTune™ プロファイラーのダウンロードと製品サポートについては、
https://www.isus.jp/intel-vtune-amplifier-xe/ を参照してください。
このクックブックのレシピはすべてスケーラブルであり、インテル® VTune™ Amplifier 2018以降に適用できます。バージョンにより設定がわずかに異なることがあります。
ベータ版インテル® oneAPI ベース・ツールキット向けのバージョンから、インテル® VTune™
Amplifier の名称がインテル® VTune™ プロファイラーに変わりました。引き続き、インテル®
Parallel Studio XE またはインテル® System Studio のコンポーネントとして、あるいはスタ
ンドアロン版のインテル® VTune™ プロファイラーをご利用いただけます。

GitLab* Runner をインストールする
GitLab* Runner が設定されていない場合は、GitLab* 公式ドキュメント(https://docs.gitlab.com/runner/#install-gitlab-runner (英語)) の手順に従って、GitLab* Runner ソフト
ウェア・パッケージをインストールして設定します。
GitLab* Runner をインストールした後に、インテル® VTune™ プロファイラーをインストールします。手順と利用可能なインストール方法については、『インテル® VTune™ プロファイラー・インストール・ガイド』 (英語) を参照してください。
注••

root 権限なしでハードウェア・イベントベース・サンプリング収集を実行できるように、/proc/sys/kernel/perf_event_paranoid を 0 に設定してください。インテルのサンプリン
グ・ドライバーまたは root 権限を使用しないハードウェア・プロファイルについては、本クックブックの「インテルのサンプリング・ドライバーを使用しないハードウェア・プロファイル」レシピを参照してください。
パフォーマンス解析結果は、使用する Runner と解析を実行するマシンによって異なります。

自動データ収集を設定する
vtune コマンド呼び出しとアーティファクト処理コマンドを GitLab* パイプラインに追加します。例えば、次のコマンドを .gitlab-ci.yml ファイルに追加します。
vtune -collect hotspots ./<アプリケーション>
このコマンドは、最後のコマンドオプションで指定されたアプリケーションを起動して、ホットスポット解析 (英語) データを収集し、結果を別のディレクトリーに保存します。
インテル® VTune™ プロファイラーの結果と HTML サマリーレポートの任意の組み合わせをアップロードできます。例えば、アプリケーションのパフォーマンスの概要を把握するため、完全な解析結果と静的な HTML サ
マリーレポートをアップロードできます。
静的な HTML レポートを生成するには、次のコマンドを追加します。
vtune -report summary -format=html > hotspots_summary.html
インテル® VTune™ プロファイラーの完全な結果をアーティファクトとしてアップロードするには、任意のツー
ルで結果ディレクトリーをパッケージ化する必要があります。例えば、次のように、tar を使用して結果ディレク
トリーをパッケージ化します。
tar -c r00* > vtune_result.tar
注••vtune コマンドを使用して、任意のオプションを指定し、実行環境で有効な任意の解析タイプを選択できます。コマンドラインから解析を実行する方法については、『インテル® VTune™ プロファイラー・
ユーザー・ガイド』の「コマンドライン解析の実行」 (英語) を参照してください。
インテル® VTune™ プロファイラーのグラフィカル・ユーザー・インターフェイス (GUI) は、GUI で解析を設定して、必要なすべてのオプションとパラメーターを含むコマンドラインを生成してコピーできる、
コマンドライン設定生成機能 (英語) を提供します。この機能を利用してコマンドラインを簡単に生成し、後で使用できます。

手動での vtune コマンドの作成については、『インテル® VTune™ プロファイラー・ユーザー・ガイド』の「コマンドライン・インターフェイス」 (英語) を参照してください。
注
特定の環境では、実行可能な解析タイプが制限されます。例えば、マイクロアーキテクチャー全般解析は、特定の仮想マシン・ハイパーバイザーでは利用できません。

結果の自動アップロードを設定する
アップロードするファイルを .gitlab-ci.yml ファイルの artifacts/paths: セクションに追加します。例えば、結果ディレクトリーの .tar ファイルと HTML サマリーをアップロードする場合、次のように指定します。
artifacts:
paths:- <プロジェクトの相対パス>/vtune_result.tar- <プロジェクトの相対パス>/hotspots_summary.html
注結果は、GitLab* アーティファクトとしてアップロードしてください。そうでないと、インテル® VTune™ プロファ
イラーを実行するマシン上に結果が保存され、手動で取得する必要があります。

結果データを表示する
ビルドが完了したら、次の手順に従って、GitLab* ウェブ・インターフェイスから解析サマリーページにすぐにア
クセスできます。

1. GitLab* で Pipelines ページに移動します。

2. このページから、アーティファクト・バンドルをダウンロードするか、個々の HTML ページを参照して、サマリーを基に結果をダウンロードする必要があるかどうかを判断できます。

HTML ページを個別にダウンロードするには、次の操作を行います。
1. パイプライン・ステージのレポート・ページに移動して、[Browse] をクリックします。

2. HTML ページの場所に移動して、ダウンロードします。

3. 任意のブラウザーでサマリー HTML を開いて、追加の解析が必要かどうかを判断します。

インテル® VTune™ プロファイラーのグラフィカル・ユーザー・インターフェイスを使用して結果データを表示す
るには、次の操作を行います。
1. .tar アーカイブから結果ファイルを展開します。
2. インテル® VTune™ プロファイラー GUI を起動します。
3.

ボタンをクリックして、結果ファイルを参照します。結果データは新しいタブに表示されます。

(オプション) 新たに発生した問題を解決する
パフォーマンス・リグレッションが検出された場合、問題を特定して解決するため、インテル® VTune™ プロファ
イラーのほかの解析タイプを使用できます。
注
このレシピの情報は、インテル® VTune™ プロファイラー・デベロッパー・フォーラム (英語) を参照してくださ
い。

関連項目
•
•
•
•

設定レシピ
インテル® VTune™ プロファイラーのコマンドライン・インターフェイス (英語)インテル® VTune™ プロファイラーの CLI リファレンス (英語)
コマンドライン設定生成機能 (英語)ハードウェアベースの hotspot 解析向けに Hyper-V* 仮想マシンを設定する
このレシピは、インテル® VTune™ プロファイラーを使用してハードウェア・パフォーマンスをプロファイルする
ため、Hyper-V* 環境で仮想マシン・インスタンスを設定します。
コンテンツ・エキスパート: Alexey Kireev (英語)、Denis Pravdin (英語)••使用するもの手順:
1. Hyper-V* ホストを設定する
2. 仮想マシンを作成して設定する
3. ハードウェア解析向けに仮想マシンを設定する
4. hotspot 解析 (ハードウェア・イベントベース・サンプリング・モード) を実行する

使用するもの
以下は、パフォーマンス解析シナリオで使用するハードウェアとソフトウェアのリストです。
•

ツール:
ベータ版インテル® VTune™ プロファイラー (またはインテル® VTune™ Amplifier 2019)o サードパーティー製の Virtual Machine Manager (VMM) も必要になることがあります。
CPU: インテル® バーチャライゼーション・テクノロジー (インテル® VT) 対応のインテル® Xeon® プロ
セッサー
o

•

次のようなパフォーマンス・モニタリング・ハードウェア搭載のインテル® マイクロアーキテクチャーを使用することもできます。

•

インテル® マイクロアーキテクチャー
開発コード名

PMU
バージョン

PEBS

LBR

IPT

PT2GPA

Kaby Lake

4

○

○

○

×

Ice Lake

4

○

○

○

○

Cascade Lake

4

○

○

○

×

Gemini Lake

4

○

○

○

×

Skylake

4

○

○

×

×

Haswell

3

○

○

×

×

Broadwell

3

○

○

×

×

オペレーティング・システム: Microsoft* Windows Server* 2019 または Windows* 10 バージョン
1809 (October 2018 Update) 以降

•インテル® VT 対応の BIOS

注Hyper-V* には、「Hyper-V* 仮想マシンでインテル® パフォーマンス・モニタリング・ハードウェアを有効にする」で説明されている追加の要件があります。

Hyper-V* ホストを設定する
1. サーバーの BIOS セットアップでインテル® VT を有効にします。
a. 電源投入時の自己テスト (POST) 中に F2 キーを押してシステムの BIOS にアクセスします。
b. [Advanced] > [Processor Configuration] を選択します。
c. [Intel® Virtualization Technology] を選択して [Enabled] に変更します。
d. 変更を保存して再起動します。
2. [コントロール パネル] > [プログラム] > [プログラムと機能] に移動して、左のペインで [Windows*の機能の有効化または無効化] をクリックします。
[Windows* の機能] ダイアログボックスが表示されます。
3. [Hyper-V] を展開してすべてのチェックボックスをオンにします。

4. [OK] をクリックして、インストールします。
インストールが完了したら [今すぐ再起動] をクリックします。

仮想マシンを作成して設定する
Hyper-V* ホスト (以降、「ホスト」) で [スタート] メニューから Hyper-V マネージャーを実行して、新しい VM(以降、「VM」) を作成し設定します。
1. [操作] パネルで [新規] をクリックして、[仮想マシン...] を選択します。

2. [仮想マシンの新規作成ウィザード] で新しいマシンに必要なすべてのパラメーター (CPU 構成、メモ
リー、ネットワーク、ハードディスク、ほか) を指定します。
インテル® VTune™ プロファイラーの推奨システム要件は 4GB RAM、空きディスク容量 10GB 以上です。
3. インストールのソースを設定します。例えば、ローカルのインストール・イメージ (.iso) を使用できます。

4. 新しく作成した VM を起動して、OS のインストール・プロセスを開始します。

ハードウェア解析向けに仮想マシンを設定する
PMU/PEBS/LBR を VM に公開してプロファイルするターゲット・システム・インスタンスを準備します。
1. VM をシャットダウンして、[スタート] メニューから管理者権限でホストの Windows PowerShell* を起動します。
2. PowerShell* で次のコマンドを実行して、PMU、PEBS、LBR が VM に公開されるように設定します。
Set-VMProcessor -VMName your_vm_name -Perfmon pmu,pebs,lbr3. VM を起動します。
注
追加の情報は、「Hyper-V* 仮想マシンでインテル® パフォーマンス・モニタリング・ハードウェアを有効にする」
を参照してください。

hotspot 解析を実行する
VM から直接インテル® VTune™ プロファイラーを実行します。
1. VM にインテル® VTune™ プロファイラーをインストールします。
2. [スタート] メニューからインテル® VTune™ プロファイラーを実行します。
3. プロジェクトを作成します。
[Configure Analysis (解析の設定)] ウィンドウが表示されます。
4. [WHERE (どこを)] ペインでは、[Local Host (ローカルホスト)] ターゲット・システム・タイプを選択します。
5. [WHAT (何を)] ペインでは、アプリケーションの場所と作業ディレクトリーを指定します。
6. [HOW (どのように)] ペインでは、hotspot 解析の [Hardware Event-Based Sampling (ハードウェ
ア・イベントベース・サンプリング)] 収集モードを選択します。
PMU/PEBS/LBR が正しく公開されている場合、[Analysis Configuration (解析の設定)] ペインにエラーメッセージは表示されず、解析を実行できます。

7.

[Start (開始)] をクリックして解析を開始します。
解析結果は、デフォルトの [Hotspots by CPU Utilization (CPU 使用率によるホットスポット)]
ビューポイントに表示されます。

注
同時に実行している複数の VM で hotspot 解析を実行することも可能です。

関連項目
•
•
•

Hyper-V* 環境のターゲットをプロファイル (英語)Hyper-V* 仮想マシンでインテル® パフォーマンス・モニタリング・ハードウェアを有効にする
ハードウェア・イベントベース・サンプリング収集 (英語)DPC++ アプリケーションのプロファイル
このレシピは、DPC++ (データ並列 C++) アプリケーションを作成してコンパイルする方法を紹介します。また、インテル® VTune™ プロファイラーを使用して DPC++ アプリケーションの GPU 解析を実行し、結果を検証する方法も示します。
コンテンツ・エキスパート: Jackson Marusarz (英語)••使用するもの
手順:
1. DPC++ アプリケーションを作成してコンパイルする
2. DPC++ アプリケーションの GPU 解析を実行する
3. 収集データを解析する

使用するもの
このレシピの最小ハードウェア要件とソフトウェア要件は次のとおりです。
•••

アプリケーション: matrix_multiply。このサンプル・アプリケーションは、インテル® oneAPI ツー
ルキットのサンプル・コード・パッケージ (英語) に含まれています。
コンパイラー: DPC++ アプリケーションをプロファイルするには、ベータ版インテル® oneAPI ツール
キット (英語) に含まれる dpcpp コンパイラーが必要です。
ツール: ベータ版インテル® VTune™ プロファイラー: GPU 計算/メディア hotspot 解析
注インテル® VTune™ プロファイラー評価版のダウンロードと製品サポートについては、
https://www.isus.jp/intel-vtune-amplifier-xe/ を参照してください。
o このクックブックのレシピはすべてスケーラブルであり、インテル® VTune™ Amplifier 2018以降に適用できます。バージョンにより設定がわずかに異なることがあります。
o ベータ版インテル® oneAPI ベース・ツールキット向けのバージョンから、インテル® VTune™
Amplifier の名称がインテル® VTune™ プロファイラーに変わりました。引き続き、インテル®
Parallel Studio XE またはインテル® System Studio のコンポーネントとして、あるいはスタ
ンドアロン版のインテル® VTune™ プロファイラーをご利用いただけます。
マイクロアーキテクチャー:o 第 9 世代インテル® プロセッサー・グラフィックス (Gen9)o インテル® マイクロアーキテクチャー開発コード名 Kaby Lake または Coffee Lake
オペレーティング・システム: Linux* カーネル 4.14 以降 (GPU ターゲット・プロファイルの実行)
グラフィカル・ユーザー・インターフェイス:o GTK+* (2.10 以降、2.18 以降を推奨)
o Pango* (1.14 以降)
o X.Org (1.0 以降、1.7 以降を推奨)
o

•

•
•

DPC++ アプリケーションを作成してコンパイルする
独自の DPC++ アプリケーションをコンパイルする場合、oneAPI DPC++ コンパイラー・オプションの-gline-tables-only と -fdebug-info-for-profiling を必ず指定してください。これにより、パフォーマンス解析に必要なデバッグ情報が生成されます。
matrix_multiply サンプルをビルドするには、次の操作を行います。
1. サンプル・ディレクトリーに移動します。
cd <sample_dir>/VtuneProfiler/matrix_multiply
2. src ディレクトリーの multiply.cpp ファイルには、行列乗算のいくつかの DPC++ バージョンが含まれています。multiply.h で対応する #define MULTIPLY 行を編集して、バージョンを選択します。
3. サンプル DPC++ アプリケーションをコンパイルします。
cmake .
make
matrix.dpcpp 実行ファイルが生成されます。
プログラムを削除するには、次のコマンドを実行します。
make clean
make コマンドによって作成された実行ファイルとオブジェクト・ファイルが削除されます。

DPC++ アプリケーションの GPU 解析を実行する
必要条件: GPU 解析を実行するシステムを準備します。詳細は、『インテル® VTune™ プロファイラー・ユー
ザー・ガイド』 (英語) を参照してください。
1. ベータ版インテル® VTune™ プロファイラーを起動して、[Welcome (ようこそ)] ページで [New
Project (新規プロジェクト)] をクリックします。
[Create a Project (プロジェクトの作成)] ダイアログボックスが表示されます。
2. プロジェクトの名前と場所を指定したら、[Create Project (プロジェクトの作成)] ボタンをクリックします。
[Configure Analysis (解析の設定)] ウィンドウが表示されます。
3. [WHERE (どこを)] ペインで [Local Host (ローカルホスト)] が選択されていることを確認してください。
4. [WHAT (何を)] ペインで、[Launch Application (アプリケーションを起動)] ターゲットが選択されていることを確認して、プロファイルする [Application (アプリケーション)] としてmatrix_multiply を指定します。

5. [HOW (どのように)] ペインで、ボタンをクリックして [Platform Analysis (プラットフォーム解析)] グループの [GPU Compute/Media Hotspots (GPU 計算/メディア・ホットスポット)] を選択します。
これは、インテル® グラフィックスおよびインテル® VTune™ プロファイラーでサポートされるサードパーティー GPU を搭載したプラットフォームで実行中のアプリケーションを最も干渉しない方法で解析します。
6. 最初の GPU 解析では、次のデフォルトのオプションが有効になっていることを確認してください。
o [Characterization (特性)] モードと [Overview (概要)] メトリックo [Trace GPU Programming APIs (GPU プログラミング API をトレース)] チェックボックス

7. ウィンドウの下部にある [Start (開始)] ボタンをクリックして解析を開始します。
コマンドラインからこの設定を実行するには、次のコマンドを入力します。
vtune -collect gpu-hotspots -- ./matrix.dpcpp

収集データを解析する[GPU Offload (GPU オフロード)] ビューポイントから解析を開始します。[Summary (サマリー)] ウィンドウ
で、CPU と GPU リソースの利用状況に関する統計を確認して、アプリケーションが GPU 依存かどうかを判断します。この例では、GPU 利用率が非常に高いことが分かります。

[Platform (プラットフォーム)] ウィンドウに切り替えて、ソフトウェア・キューの GPU 利用率の解析に役立つ
基本的な CPU メトリックと GPU メトリックを確認します。このデータは、タイムラインで CPU 利用率に関連付けられます。[Platform (プラットフォーム)] ウィンドウで、以下の状況に関する情報を確認します。
GPU 依存アプリケーション

CPU 依存アプリケーション

プロファイル時間の大部分で GPU がビジー

プロファイル時間の大部分で CPU がビジービジーの間に小さなアイドル時間がある

ビジーの間に大きなアイドル時間がある

GPU ソフトウェア・キューがほとんどゼロにならない
注
ほとんどのアプリケーションでは、上記のような明らかな状況が見られない場合があります。すべての依存関係を理解するには、詳細な解析が重要です。例えば、ビデオ処理とレンダリングを行う GPU エンジンが交互にロードされる場合、これらのエンジンはシリアルに使用されます。アプリケーション・コードを CPU で実行する
場合、GPU のスケジュールが非効率になります。これにより、誤ってアプリケーションが GPU 依存であると解釈される可能性があります。

GPU が長時間にわたってビジーな場合、[GPU Compute/Media Hotspots (GPU 計算/メディア・ホットスポット)] ビューポイントに切り替えて、[Graphics (グラフィックス)] ウィンドウの [Platform (プラットフォーム)] タブでスレッドごとに GPU で実行されているワークの種類 (レンダリングまたは計算) を調べます。

サンプルの README ファイルを使用して、multiply.cpp のほかの実装をプロファイルします。

関連項目
•
•

GPU 計算/メディア hotspot 解析 (英語)インテル® HD グラフィックスとインテル® Iris® グラフィックスでの GPU アプリケーションの解析(英語)

FPGA 上での DPC++ アプリケーションのプロファイル
このレシピは、FPGA 上で DPC++ (データ並列 C++) アプリケーションをプロファイルします。このレシピでは、インテル® VTune™ プロファイラーの CPU/FPGA 相互作用解析タイプ (プレビュー機能) に統合されている AOCL プロファイラーを使用します。
コンテンツ・エキスパート: Dmitry Ryabtsev (英語)••使用するもの手順:
1. ツールキットをインストールして設定する
2. サンプル・アプリケーションをビルドする
3. CPU/FPGA 相互作用解析を実行する
4. 結果を解釈する使用するもの
このレシピの最小ハードウェア要件とソフトウェア要件は次のとおりです。
•••

アプリケーション: crr。この FPGA サンプルは、インテル® oneAPI DPC++ コンパイラー・サンプルのリポジトリー (英語) から入手できます。
コンパイラー: DPC++ アプリケーションをプロファイルするには、ベータ版インテル® oneAPI ツール
キット (英語) に含まれる dpcpp コンパイラーが必要です。
ツール:
o ベータ版インテル® oneAPI ベース・ツールキット (Linux* 版) (英語)o ベータ版 oneAPI ベース・ツールキット用インテル® FPGA アドオン (英語)o ベータ版インテル® VTune™ プロファイラー: CPU/FPGA 相互作用解析 (プレビュー機能)
注
o
o
o

•
•
•

インテル® VTune™ プロファイラーのダウンロードと製品サポートについては、
https://www.isus.jp/intel-vtune-amplifier-xe/ を参照してください。
このクックブックのレシピはすべてスケーラブルであり、インテル® VTune™ Amplifier 2018以降に適用できます。バージョンにより設定がわずかに異なることがあります。
ベータ版インテル® oneAPI ベース・ツールキット向けのバージョンから、インテル® VTune™
Amplifier の名称がインテル® VTune™ プロファイラーに変わりました。引き続き、インテル®
Parallel Studio XE またはインテル® System Studio のコンポーネントとして、あるいはスタ
ンドアロン版のインテル® VTune™ プロファイラーをご利用いただけます。

オペレーティング・システム: Ubuntu* 18.04
CPU: インテル® サーバー・プラットフォーム開発コード名 Cascade Lake
FPGA: インテル® プログラマブル・アクセラレーション・カード (インテル® PAC) インテル® Arria® 10
GX FPGA 搭載版または DPC++ 向けインテル® Stratix 10 GX FPGA PAC ボード (およびインストー
ル可能なアドオン)

ツールキットをインストールして設定する
インテル® PAC カードをマシンの PCIe* スロットに装着します。
1. ベータ版インテル® oneAPI ベース・ツールキット (Linux* 版) (英語) をダウンロードしてインストール
します。すべてのデフォルトのオプションを選択して、オンラインまたはオフライン・インストーラーのいずれかを選択します。
2. ベータ版 oneAPI ベース・ツールキット用インテル® FPGA アドオン (英語) をダウンロードします。
3. ベータ版 oneAPI ベース・ツールキット用インテル® FPGA アドオンを展開して、setup.sh を実行します。すべてのデフォルトのオプションを選択します。
4. oneAPI 環境をセットアップします。
source <oneAPI-install-dir>/setvars.sh
5. FPGA ボードを装着します。
aocl install
6. 診断コマンドを実行して、すべての診断にパスすることを確認します。
aocl diagnose

サンプル・アプリケーションをビルドする
1. インテル® oneAPI DPC++ コンパイラー・サンプルのリポジトリー (英語) からサンプルコードをダウンロードします。
git clone https://github.com/intel/BaseKit-code-samples.git
2. crr サンプルフォルダーを開きます。
cd BaseKit-code-samples/FPGAExampleDesigns/crr
3. src/CMakeLists.txt ファイルを開きます。
4. set(HARDWARE_LINK_FLAGS から始まる、ハードウェア・フラグをリストしているコード行に移動します。
5. リストに -Xsprofile を追加します。
6. サンプルのメイン・ディレクトリーに戻ります。build という名前の新しいフォルダーを作成して開きます。
mkdir build
cd build
7. サンプルをコンパイルします。
cmake ..
make fpga
この処理には数時間かかります。処理が終了すると、crr.fpga という名前の実行ファイルが生成されます。

これで、FPGA ハードウェア上で crr.fpga を実行できます。

CPU/FPGA 相互作用解析を実行する
1. インテル® VTune™ プロファイラーを起動して、[Welcome (ようこそ)] ページで [New Project (新規プロジェクト)] をクリックします。
[Create a Project (プロジェクトの作成)] ダイアログボックスが表示されます。
2. プロジェクトの名前と場所を指定したら、[Create Project (プロジェクトの作成)] ボタンをクリックします。
[Configure Analysis (解析の設定)] ダイアログボックスが開きます。
3. [WHERE (どこを)] ペインで、[Local Host (ローカルホスト)] を選択します。
4. [WHAT (何を)] ペインで、ターゲットとして [Launch Application (アプリケーションを起動)] を選択します。
o [Application (アプリケーション)] フィールドに、crr.fpga 実行ファイルのパスを指定します。
o [Application parameters (アプリケーションのパラメーター)] フィールドに、
ordered_inputs.csv を入力します。

5. [HOW (どのように)] ペインで、[Platform Analysis (プラットフォーム解析)] グループの[CPU/FPGA Interaction (preview) (CPU/FPGA 相互作用 (プレビュー))] を選択します。

6. 解析の設定で、[FPGA profiling data source (FPGA プロファイル・データソース)] に [AOCL
Profiler (AOCL プロファイラー)] を選択します。

7. ウィンドウの下部にある [Start (開始)] ボタンをクリックして解析を開始します。

結果を解釈するデータ収集が完了すると、[CPU/FPGA Interaction (CPU/FPGA 相互作用)] ビューポイントでファイナライ
ズされた結果を確認できます。最初に、[Summary (サマリー)] ウィンドウで次の詳細を確認します。
••

FPGA の上位計算タスク
CPU の上位のタスクとホットスポット

[Bottom-up (ボトムアップ)] ウィンドウに切り替えて、以下を含むカーネルレベルの詳細情報を確認します。
•
•
•
•

ストール
占有率
データ転送サイズ
転送データの平均帯域幅

タイムライン・ビューを使用して、カーネル・インスタンスに関する次の情報を確認します。
••••

開始時間/終了時間
全体のストール
占有率
帯域幅メトリック[Bottom-up (ボトムアップ)] ウィンドウで、カーネルを右クリックしてコンテキスト・メニューから [View
Source (ソースを表示)] を選択します。
[Source (ソース)] ビューが開いて、特定のカーネルソース行のメトリックを確認できます。

関連項目
•
•

設定レシピ
CPU/FPGA 相互作用解析 (英語)インテルのサンプリング・ドライバーを使用しないハードウェ
ア・プロファイル
この一連のレシピは、インテル® VTune™ プロファイラーでドライバーを使用しない Linux* perf ベースのパフォーマンス・プロファイルを設定して、その利点と制限に対する回避策を理解するのに役立ちます。
コンテンツ・エキスパート: Alexey Budankov (英語)、Alexey Bayduraev (英語)インテル® プロセッサーは、コードがハードウェア・リソースをどの程度有効に利用しているか解析するのに使用できるパフォーマンス・モニタリング・ユニット (PMU) イベントを提供します。インテル® VTune™ プロファイ
ラーは、HPC パフォーマンス特性、メモリーアクセス、マイクロアーキテクチャー全般など、マイクロアーキテ
クチャー解析タイプで PMU を収集して解析できます。また、解析に必要なサンプリング間隔が短い場合など、必要に応じて、hotspot とスレッド解析タイプでも、デフォルトのユーザーモード・サンプリングの代わりに
PMU イベントベース・サンプリングを使用するように設定できます。
PMU イベントベース解析では、インテル® VTune™ プロファイラーはインテルのサンプリング・ドライバー (英語) を使用します。このドライバーをターゲットシステムにインストールするには、管理者権限が必要です。管理
者権限がない場合、またはサードパーティーのドライバーのインストールが許可されていない環境の場合、
インテル® VTune™ プロファイラーはインテルのサンプリング・ドライバーを介して PMU イベントにアクセスし、ハードウェア・パフォーマンスのボトルネックを特定することができません。そのような場合、インテル®
VTune™ プロファイラーは、Linux* の perf パフォーマンス・モニタリング・システムを介してハードウェア・パフォーマンス・モニタリング機能を提供します。
インテル® VTune™ プロファイラーは、次の場合にドライバーを使用しない perf によるハードウェア・イベント
ベース・サンプリング解析を有効にします。
•••

インテルのサンプリング・ドライバーがインストールできない (例: root 権限なしでインストールした場
合など)
非ゼロのスタックサイズでスタックを含む収集が選択され、ドライバーを使用しない収集の要件が満たされている
ドライバーを使用しない収集を使用するオプションが有効になっており、ドライバーを使用しない収集の要件が満たされている

インテル® VTune™ プロファイラーの最新バージョンは、Linux* perf (ドライバーを使用しない) サポートが拡張されており、インテルのサンプリング・ドライバーベースのソリューションに匹敵するプロファイル機能、収集
オーバーヘッド、およびトレースサイズを提供します。しかし、ドライバーを使用しないモードでのインテル®
VTune™ プロファイラーの機能は Linux* OS の設定に依存し、以下のレシピに示すようないくつかの制限が
あります。
注
•

インテルのサンプリング・ドライバーで提供されるハードウェア・プロファイル機能と同等のドライバー
を使用しない perf 収集を有効にするには、管理者権限で次のシステムオプションを設定する必要が
あります。

•

解析に使用されたコレクターの種類 (perf またはインテルのサンプリング・ドライバー (SEP)) は、[Summary (サマリー)] ウィンドウの [Collection and Platform Info (収集とプラットフォーム情報)] セクションで確認できます。

•

使用するもの:インテル® VTune™ プロファイラー (またはインテル® VTune™ Amplifier 2019) は、次の要件を満たす場合にドライバーを使用しないモードを使用できます。
o

o

o
•

コアとアンコアイベント。インテル® VTune™ プロファイラーのすべてのハードウェア・イベン
トベース収集はコア PMU イベントを使用します。メモリーアクセスや IO など一部の解析タイ
プは、DRAM 帯域幅、QPI/UPI 帯域幅、PCI 帯域幅などのメトリックの収集を可能にするアン
コアイベントへのアクセスが必要です。
Linux* カーネル 2.6.32 以降の perf。Linux* カーネルは、/sys/bus/event_source/devices/cpu および/sys/bus/event_source/devices/uncore_* ディレクトリーを利用して PMU イベン
トを認識します。ディレクトリーが空の場合、システム設定が PMU イベント収集をサポートしていない可能性があります。この場合、OS をアップデートするか、インテルのサンプリング・ド
ライバーをインストールしてください。
/proc/sys/kernel/perf_event_paranoid の値が 1 以下。

制限のレシピ:o システム全体またはユーザープロセスのプロファイルを有効にする
o コアとアンコアイベントの収集を有効にする
o マルチプロセスのプロファイルを有効にする
o マルチコアシステムで多数の PMU イベントをプロファイルするo スタックのサンプリングを有効にする
o コンテキスト・スイッチを収集する
o カーネル関数のシンボルを解決する
o NMI ウォッチドックとのリソース競合を回避する
o 収集オーバーヘッドを軽減する
o 必要に応じてドライバーを使用しないモードを有効にする

注インテル® VTune™ プロファイラーに付属の vtune-self-checker.sh スクリプトを実行して、解析システ
ムの製品機能を検証できます。このスクリプトは、安定したベンチマークで解析タイプの代表的なセットを実行
して、システムでインテル® VTune™ プロファイラーが直面した制限について通知します。診断の推奨事項は、ドライバーを使用しない perf 収集向けにシステムを適切に設定したり、システムを設定できない場合はインテルのサンプリング・ドライバーをインストールするのを支援します。スクリプトを実行するには、次のコマンドを使用します。
<vtune_install_dir>/bin64/vtune-self-checker.shシステム全体またはユーザープロセスのプロファイルを有効にする
解析タイプ: すべて。
概念: システム全体の解析は、システムサービスなどを含む、システムで実行中のすべてのプロセスに関するパフォーマンス情報を収集します。
ドライバーを使用しないモードの制限: システム全体またはユーザープロセスのプロファイルを有効にするには、追加の設定が必要です。
ドライバーを使用しないモードでシステム全体の解析を有効にする
1. インテル® VTune™ プロファイラーのプロジェクトを設定します。[WHAT (何を)] ペインで [Profile
System (システムをプロファイル)] ターゲットまたは [Launch Application (アプリケーションを起動)] ターゲットを選択して、[Analyze system-wide (システム全体を解析)] オプションを有効にします。
2. 次のコマンドを実行して、/proc/sys/kernel/perf_event_paranoid ファイルの値を確認します。
cat /proc/sys/kernel/perf_event_paranoid
値が 1 未満の場合、インテル® VTune™ プロファイラーはシステム全体の収集を続行できます。
3. perf_event_paranoid 値が 1 の場合 (収集はユーザープロセスのみに制限されます) または 1 よりも大きい場合 (インテル® VTune™ プロファイラーはドライバーを使用しない perf モードを使用できません)、システム全体の収集を行うため perf_event_paranoid 値を 0 に設定します。
echo 0 > /proc/sys/kernel/perf_event_paranoid
注
一部の環境では、perf_event_paranoid はセキュリティー・ポリシーによって規制されます。Linux* perf のセキュリティー要件の詳細は、https://www.kernel.org/doc/html/latest/admin-guide/perfsecurity.html (英語) を参照してください。
インテルのサンプリング・ドライバーの制限: デフォルトでは、インテルのサンプリング・ドライバーはシステム全体の収集をサポートします。しかし、--per-user オプションを指定してビルドおよびロードされている場
合、収集はユーザープロセスのみに制限されます。

コアとアンコアイベントの収集を有効にする
解析タイプ: メモリーアクセス、HPC パフォーマンス特性、その他のアンコア・イベント・ベースの解析タイプ
コアイベントは、システム全体とユーザープロセスごとのどちらでも収集できます。ドライバーを使用しない
perf モードでアンコアイベントを収集するには、システム全体の解析を有効にします。

ドライバーを使用しないモードの制限:••

メモリーアクセス解析は、アンコアイベントにアクセスする必要があり、それらを収集することができない場合実行されません。HPC パフォーマンス特性など、その他の解析タイプは実行されますが、DRAM 帯域幅、OPA インターコネクト帯域幅、パケットレートなど、アンコア・イベント・ベースのメト
リックは提供されません。
ドライバーを使用しないモードでのアンコアイベントの収集は、Intel Atom® プロセッサーではサポートされていません。

ドライバーを使用しないモードでアンコアイベントを収集する
perf_event_paranoid 値を 0 に設定してシステム全体のパフォーマンス・モニタリングを有効にします。
これは、アンコアイベント収集の必要条件です。
インテルのサンプリング・ドライバーの制限: なし。

マルチプロセスのプロファイルを有効にする
解析タイプ: すべて。
デフォルトでは、Linux* カーネルはパフォーマンス・データの収集に利用可能なメモリーサイズを 518KB に制限します。現在の値を確認するには、次のコマンドを使用します。
cat /proc/sys/kernel/perf_event_mlock_kb
ドライバーを使用しないモードの制限: マルチコアシステム (64 論理コアを超える) のユーザープロセス収集
モードで一部の並列アプリケーション (例えば、ノードごとに複数のランクがある MPI アプリケーション) は、
518KB 制限に達しデータ収集が利用できません。
マルチコアシステムでマルチプロセスの収集を有効にする
perf_event_paranoid 値を 0 に設定して、システム全体のパフォーマンス・モニタリングを有効にします。
インテルのサンプリング・ドライバーの制限: なし。デフォルトの設定で任意の数のプロセスをプロファイルできます。

マルチコアシステムで多数の PMU イベントをプロファイルする
解析タイプ: マイクロアーキテクチャー全般。
ドライバーを使用しないモードの制限: Linux* perf は、各 CPU で設定されている PMU イベントごとにファイ
ル記述子を割り当てます。そのため、マルチコアシステムで多数のイベントを利用するマイクロアーキテク
チャー全般などの解析を行う場合、制限に達しドライバーを使用しないモードでの収集が利用できません。

ドライバーを使用しないモードで多数の PMU イベントをプロファイルする
1. オープンファイルの上限を確認します。
ulimit -n
2. 必要に応じて、/etc/security/limits.conf ファイルに次の行を追加するか、既存の行を変更して上限を増やします。
o soft nofile 65535
o hard nofile 65535
注
管理者権限が必要です。
インテルのサンプリング・ドライバーの制限: なし。

スタックのサンプリングを有効にする
解析タイプ: hotspot (ハードウェア・イベントベース・サンプリング・モード)、スレッド (ハードウェア・イベント
ベース・サンプリング・モードおよびスタック・スティッチ・モード)、HPC パフォーマンス特性 ([Collect stacks(スタックを収集)] オプションがオン)、GPU 計算/メディア hotspot ([Collect stacks (スタックを収集)] オプ
ションがオン)。
ドライバーを使用しないモードの制限:••関数がスタックに多くのデータを割り当てる場合、デフォルトの 1024 バイトのスタックサイズではス
タックを完全にアンワインドできない場合があります。この場合、収集データに [Skipped stack
frame(s)] が表示されます。
バージョン 3.7 よりも古い Linux* カーネルは、フレームポインター (FP) ベースのスタック・アンワイ
ンドのみをサポートしています。つまり、インテル® VTune™ プロファイラーは、フレームポインターを含めない (-fomit-frame-pointer コンパイラー・オプション) でビルドされたバイナリーのスタックを提供できません。また、glibc スタックもフレームポインターを含めないでビルドされているため提供できません。

ドライバーを使用しないモードでスタック・アンワインドの問題を回避する
スタックサイズを増やします。次に例を示します。
vtune -collect hotspots -knob sampling-mode=hw -knob enable-stackcollection=true -knob stack-size=2048 <application>
そうでない場合、インテルのサンプリング・ドライバーに切り替えて、[Stack size (スタックサイズ)] オプション
を 0 (無制限) に設定します。

注
インテルのサンプリング・ドライバーを使用したスタック・サンプリング収集はカーネル実装に依存するため、通常は新しいカーネルバージョンへの更新が必要であり、追加の製品保守コストが発生する可能性があります。このコストを軽減するため、インテル® VTune™ プロファイラー (およびインテル® VTune™ Amplifier
2019 Update 4 以降) では、スタック収集が有効なすべての解析タイプで、インテルのサンプリング・ドライ
バーがロードされている場合であっても、ドライバーを使用しないモードを使用します。スタックのサンプリン
グ収集をインテルのサンプリング・ドライバーに切り替える必要がある場合は、カスタム解析タイプを作成して、[Enable driverless collection (ドライバーを使用しない収集を有効にする)] オプションを無効にする
か、次に示す対応するコマンドライン設定を使用します。
vtune -collect-with runsa -knob enable-driverless-collection=false -knob
event-config=<event-list> <application>
インテルのサンプリング・ドライバーの制限: インテルのサンプリング・ドライバーは、コールスタック収集に異なるアルゴリズムを使用するため、スタック・アンワインドの制限はありません。インテル® VTune™ プロファイ
ラーでサポートされる最新のカーネルバージョンよりも新しいカーネルバージョンを使用している場合、ドライバーのアップデートが必要になることがあります。

コンテキスト・スイッチを収集する
解析タイプ: スレッド。
概念: コンテキスト・スイッチの収集は、同期またはスレッド・プリエンプションによるスレッドのインアクティブ
待機時間に基づくメトリックの取得に役立ちます。
ドライバーを使用しないモードの制限: Linux* perf は、カーネル 4.3 以降でコンテキスト・スイッチを収集します。コンテキスト・スイッチの原因 (同期またはプリエンプション) の識別は、カーネル 4.17 以降で利用できます。古いカーネルバージョンでは、インテル® VTune™ プロファイラーは、システムで利用可能な場合インテルのサンプリング・ドライバーに切り替えます。
インテルのサンプリング・ドライバーの制限: なし。

カーネル関数のシンボルを解決する
解析タイプ: すべて。
ドライバーを使用しないモードの制限: 追加で kptr_restrict ファイルを手動で設定する必要があります。
パフォーマンス・データとカーネル関数名を関連付ける
管理者権限で kptr_restrict 設定ファイルの値を 0 に設定します。
echo 0 > /proc/sys/kernel/kptr_restrict
値を 1 に設定すると、ファイル名の解決がユーザーレベルのモジュールに制限されます。

インテルのサンプリング・ドライバーの制限: なし。/boot/System.map-<kernel_version> ファイルが読み取り可能な場合、または /proc/sys/kernel/kptr_restrict が 0 に設定されている場合、インテルのサンプリング・ドライバーはカーネルシンボルを解決します。

NMI ウォッチドックとのリソース競合を回避する
解析タイプ: すべて。
ドライバーを使用しないモードの制限: NMI ウォッチドッグ (ハード・ロックアップ検出器) は、1 つの CPU パ
フォーマンス・カウンター・レジスターを利用し、このレジスターは Linux* perf で利用できなくなります。これにより多重化グループの数が増えて、統計サンプリング・データの精度に影響します。
ドライバーを使用しないモードで多数のイベントを収集する解析の実行の精度を向上する
管理者権限で NMI ウォッチドッグを無効にします。
echo 0 > /proc/sys/kernel/nmi_watchdog
ドライバーを使用しない perf 収集が完了したら NMI ウォッチドッグを (管理者権限で) 再度有効にできます。
echo 1 > /proc/sys/kernel/nmi_watchdog
インテルのサンプリング・ドライバーの制限: なし。インテルのサンプリング・ドライバーは、このデータ精度の問題を回避するため、収集時に自動で NMI ウォッチドッグを停止します。

収集オーバーヘッドを軽減する
解析タイプ: すべて。
ドライバーを使用しないモードの制限: CPU 負荷の高いアプリケーションではすべての CPU に完全な負荷がかかるため、Linux* perf 収集でオーバーヘッドが発生する可能性があります。
ドライバーを使用しないモードで収集のオーバーヘッドを軽減する•

次のように、より積極的なアフィニティーの最適化を設定します。
vtune -collect hotspots -knob sampling-mode=hw -knob enable-stackcollection=true -run-pass-thru=--perf-affinity=cpu <application>•

スタック・サンプリング収集のトレースサイズを軽減するため、インテル® VTune™ プロファイラーが使用する Linux* perf トレース圧縮は、追加のオーバーヘッドを発生する可能性があります。これを回避するには、-run-pass-thru オプションを指定してトレース圧縮を無効にします。
vtune -collect hotspots -knob sampling-mode=hw -knob enable-stackcollection=true -run-pass-thru=--perf-compression=0 -run-pass-thru=-perf-aio=0 <application>これにより、コレクターのオーバーヘッドを軽減できることがありますが、トレースサイズが大幅に増加します。
•

Linux perf コレクターによって消費される CPU 時間の上限を設定します。例えば、10% に制限する
場合、管理者権限で次のコマンドを実行します。
cat 10 > /proc/sys/kernel/perf_cpu_time_max_percent
これにより、サンプリング周波数と統計精度が低下する可能性があります。

インテルのサンプリング・ドライバーの制限: なし。

必要に応じてドライバーを使用しないモードを有効にする
インテル® VTune™ プロファイラーは、スタック・サンプリング収集を除くすべてのケースで、インテルのサンプ
リング・ドライバーがロードされている場合はそれを使用します。インテル® VTune™ プロファイラーがスタッ
クを含まないサンプリングにドライバーを使用しない perf モードを使用するように切り替えるには、カスタム
解析タイプを作成して、GUI で [Enable driverless collection (ドライバーを使用しない収集を有効にする)]
オプションを選択するか、次のようにコマンドライン knob 値に enable-driverlesscollection=true を設定します。
vtune -collect-with runsa -knob enable-driverless-collection=true -knob
event-config=<event-list> <application>
このオプションは、インテル® VTune™ Amplifier 2019 Update 4 以降で利用できます。

関連項目
•
•
•

サンプリング・ドライバー (英語)
スタックを含むハードウェア・イベントベースのサンプリング収集 (英語)Linux* カーネル解析を有効にする (英語)MPI アプリケーションのプロファイル
このレシピは、インテル® VTune™ Amplifier を使用して MPI アプリケーションのインバランスと通信の問題を特定し、アプリケーション・パフォーマンスを向上します。
コンテンツ・エキスパート: Carlos Rosales-fernandez (英語)••使用するもの手順:
1. アプリケーションをビルドする
2. 全体的なパフォーマンス特性を確立する
3. HPC パフォーマンス特性解析を設定して実行する
4. インテル® VTune™ Amplifier GUI で結果を解析する
5. (オプション) インテル® VTune™ Amplifier GUI でコマンドラインを生成する
6. (オプション) コマンドライン・レポートを使用して結果を解析する
7. (オプション) 選択したコード領域をプロファイルする

使用するもの
以下は、パフォーマンス解析シナリオで使用するハードウェアとソフトウェアのリストです。
••

アプリケーション: heart_demo サンプル・アプリケーション。GitHub*
https://github.com/CardiacDemo/Cardiac_demo.git (英語) からダウンロードできます。
ツール:o インテル® C++ コンパイラーo インテル® MPI ライブラリー 2019o インテル® VTune™ Amplifier2019
o インテル® VTune™ Amplifier アプリケーション・パフォーマンス・スナップショット
注
インテル® MPI ライブラリーは、https://www.isus.jp/intel-mpi-library/ から利用できます。
o インテル® VTune™ プロファイラー評価版のダウンロードと製品サポートについては、
https://www.isus.jp/intel-vtune-amplifier-xe/ を参照してください。
o このクックブックのレシピはすべてスケーラブルであり、インテル® VTune™ Amplifier 2018以降に適用できます。バージョンにより設定がわずかに異なることがあります。
オペレーティング・システム: Linux*
CPU: インテル® Xeon® Platinum 8168 プロセッサー (開発コード名 Skylake)
ネットワーク・ファブリック: インテル® Omni-Path アーキテクチャー (インテル® OPA)
o

•
•
•

アプリケーションをビルドする
インテル® VTune™ Amplifier がパフォーマンス・データをソースコードとアセンブリーに関連付けることができるように、デバッグシンボル付きでアプリケーションをビルドします。
1. GitHub* リポジトリーのアプリケーションをローカルシステムにクローンします。
git clone https://github.com/CardiacDemo/Cardiac_demo.git
2. インテル® C++ コンパイラーとインテル® MPI ライブラリーの環境を設定します。
source <compiler_install_dir>/bin/compilervars.sh intel64
source <mpi_install_dir>/bin/mpivars.sh
3. サンプルパッケージのルートレベルに build ディレクトリーを作成し、作成したディレクトリーに移動します。
mkdir build
cd build
4. 次のコマンドを使用してアプリケーションをビルドします。
mpiicpc ../heart_demo.cpp ../luo_rudy_1991.cpp ../rcm.cpp ../mesh.cpp g -o heart_demo -O3 -std=c++11 -qopenmp -parallel-source-info=2
heart_demo 実行ファイルが現在のディレクトリーに作成されます。

全体的なパフォーマンス特性を確立する
インテル® ソフトウェア開発ツールを使用するアプリケーション・チューニングの推奨ワークフローでは、最初にアプリケーション・パフォーマンスのスナップショットを取得してから、最適なツールを使用して問題に注目します。インテル® VTune™ Amplifier のアプリケーション・パフォーマンス・スナップショットは、シンプルなイ
ンターフェイスと低オーバーヘッドの実装で、アプリケーションの全体的なパフォーマンス特性を提供します。
特定の問題を詳しく調査する前に、アプリケーション・パフォーマンス・スナップショットを使用してアプリケー
ションの一般的な特性を理解します。

インテル® Xeon® スケーラブル・プロセッサー (開発コード名 Skylake) を使用して、デュアル・ソケット・ノードのセットのパフォーマンス・スナップショットを取得します。この例では、ソケットあたり 24 コアのインテル®
Xeon® Platinum 8168 プロセッサーを使用して、ノードごとに 4 MPI ランク、ランクごとに 12 スレッドで実行するように設定します。ランクとスレッドの数は、使用しているシステムの要件に応じて変更してください。
対話型セッションまたはバッチスクリプトで次のコマンドを実行して、4 ノードのパフォーマンス・スナップ
ショットを取得します。
export OMP_NUM_THREADS=12
mpirun –np 16 –ppn 4 aps ./heart_demo -m ../mesh_mid -s ../setup_mid.txt -t
100
解析が完了すると、aps_result_YYYYMMDD という名前のディレクトリーとプロファイル・データが生成されます。ここで、YYYY は収集の年、MM は月、DD は日を表します。次のコマンドを実行して、結果の HTML ス
ナップショットを生成します。
aps --report=./aps_result_20190125
作業ディレクトリーに aps_report_YYYYMMDD_<stamp>.html ファイルが作成されます。<stamp> 番号
は、既存のレポートが上書きされるのを防ぐために追加されます。レポートには、MPI と OpenMP* のインバラ
ンス、メモリー・フットプリントと帯域幅の利用率、浮動小数点演算のスループットを含む、全体的なパフォー
マンスに関する情報が含まれます。レポートの上部の説明は、アプリケーションの主な問題を示しています。

このアプリケーションは全体的に MPI 通信に依存していますが、メモリーとベクトル化の問題もあります。
[MPI Time (MPI 時間)] セクションは、MPI インバランスや使用された上位の MPI 関数呼び出しなど、追加の情報を提供します。この情報から、コードは主にポイントツーポイント通信を使用しており、インバランスは中程度であることが分かります。

この結果は、コードに複雑な問題があることを示しています。パフォーマンスの問題をさらに詳しく調査し、問題を切り分けるため、インテル® VTune™ Amplifier の HPC パフォーマンス特性解析を使用します。

HPC パフォーマンス特性解析を設定して実行する
ほとんどのクラスターは、ログインノードと計算ノードで構成されています。通常、ユーザーはログインノードに接続し、スケジューラーを使用してジョブを計算ノードに送信し、ジョブが実行されます。クラスター環境でインテル® VTune™ Amplifier を使用して MPI アプリケーションをプロファイルする最も実用的な方法は、コマンドラインでデータを収集し、ジョブが完了したら GUI でパフォーマンス解析を行います。
MPI 関連のメトリックのレポートは、コマンドラインから簡単に取得できます。一般に、分散環境で実行する最も簡単な方法は、次のようにコマンドを作成することです。
<mpi launcher> [options] amplxe-cl [options] –r <results dir> -<application> [arguments]

注
•
•
•

コマンドは、対話型セッションで使用することも、バッチ送信スクリプトに含めることもできます。
MPI アプリケーションでは、結果ディレクトリーを指定する必要があります。
インテル® MPI ライブラリーを使用していない場合は、-trace-mpi を追加します。

次の手順に従って、コマンドラインから HPC パフォーマンス特性解析を実行します。
1. 関連するインテル® VTune™ Amplifier ファイルを source して環境を設定します。bash シェルを使用するデフォルトのインストールでは、次のコマンドを使用します。
source /opt/intel/vtune_amplifier/amplxe-vars.sh
2. hpc-performance 解析を使用して heart_demo アプリケーションのデータを収集します。このア
プリケーションは、OpenMP* と MPI の両方を使用して、前述の構成 (インテル® MPI ライブラリーを使用して 4 つの計算ノード、16 の MPI ランク) で実行されます。実行には、インテル® Xeon®
Platinum 8168 プロセッサーと MPI ランクごとに 12 の OpenMP* スレッドを使用します。
export OMP_NUM_THREADS=12
mpirun –np 16 –ppn 4 amplxe-cl –collect hpc-performance –r vtune_mpi - ./heart_demo -m ../mesh_mid -s ../setup_mid.txt -t 100
解析が開始され、次の命名規則に従って 4 つの出力ディレクトリーが生成されます:
vtune_mpi.<node host name>。
注
ほかの MPI ランクを同時に実行しながら、特定の MPI ランクのみプロファイル・データを収集するよ
うに選択できます。詳細は、「選択した MPI ランクのプロファイル」 (英語) を参照してください。

インテル® VTune™ Amplifier GUI で結果を解析する
インテル® VTune™ Amplifier のグラフィカル・インターフェイスは、収集したパフォーマンス・データを解析するため、コマンドラインよりも豊富な機能とインタラクティブな体験を提供します。次のコマンドを実行して、結果をインテル® VTune™ プロファイラー GUI で開きます。
amplxe-gui ./vtune_mpi.node_1
注インテル® VTune™ Amplifier GUI を表示するには、ローカルシステムで実行されている X11 マネージャー、またはシステムに接続されている VNC セッションが必要です。システムはそれぞれ異なるため、推奨される方法についてはローカル管理者に相談してください。
結果がインテル® VTune™ Amplifer で開き、アプリケーション・パフォーマンスの概要を示す [Summary (サマリー)] ウィンドウが表示されます。heart_demo は MPI 並列アプリケーションであるため、[Summary (サマリー)] ウィンドウに通常のメトリックに加えて、[MPI Imbalance (MPI インバランス)] 情報と実行クリティカ
ル・パスの MPI ランクに関する詳細が表示されます。

•••[MPI Imbalance (MPI インバランス)] は、ノード上のすべてのランクの平均 MPI ビジー待機時間です。この値は、バランスが理想的であれば節約できる時間を示します。
[MPI Rank on the Critical Path (クリティカル・パス上のランク)] は、最小ビジー待機時間のランクです。
[MPI Busy Wait Time (MPI ビジー待機時間)] と [Top Serial Hotspots (上位のシリアル・ホット
スポット)] は、クリティカル・パスのランクに対して表示されます。通常、インバランスやビジー待機メ
トリックの値が高い場合スケーラビリティーが制限されるため、これはスケーラビリティーの問題を特定する良い方法です。マルチノード実行でクリティカル・パス上のランクの [MPI Busy Wait Time
(MPI ビジー待機時間)] が大きい場合、ほかのノード上に外れ値のランクがある可能性があります。

この例では、インバランスがあり、コードのシリアル領域で多くの時間が費やされています (以下の図には表示されていません)。

プロファイルはノード全体で収集されるかもしれませんが、すべての MPI データを確認するには、各ノードの結果を個別にロードする必要があります。詳細な MPI トレースには、インテル® Trace Analyzer & Collector
を推奨します。
インテル® VTune™ Amplifer 2019 以降では、[Summary (サマリー)] ウィンドウにインテル® Omni-Path
アーキテクチャー (インテル® OPA) ファブリックの使用分布図が含まれます。これらのメトリックは帯域幅とパケットレートを表示し、実行時間に占めるコードが高帯域幅使用率や高パケットレート使用率によって制限されていた割合 (%) を示します。heart_demo アプリケーションは、帯域幅やパケットレートによって制限されていませんが、分布図は平均に近い 1.8GB/秒の最大帯域幅使用率を示しています。これは、MPI 通信の継続的で非効率的な使用を示唆しています。

[Bottom-up (ボトムアップ)] タブに切り替えてさらに詳しく調査します。次のような表示になるように、[Grouping (グループ化)] で Process (プロセス) がトップレベルになるように設定します。

このコードは MPI と OpenMP* の両方を使用するため、[Bottom-up (ボトムアップ)] ウィンドウには通常のCPU とメモリーのデータに加えて、両方のランタイムに関連したメトリックが表示されます。この例では、クリティカル・パスから最も離れている MPI ランクの [MPI Busy Wait Time (MPI ビジー待機時間)] メトリックが赤色で示されています。また、最も大きな [OpenMP Potential Gain (OpenMP* 潜在的なゲイン)] も赤色で示されています。これは、スレッド化を改善することで、パフォーマンスが向上する可能性を示唆しています。
[Bottom-up (ボトムアップ)] ウィンドウの下部で DDR と MCDRAM 帯域幅、CPU 時間、インテル® OPA 使
用率を含むいくつかのメトリックの実行タイムラインを確認します。このコードのインターコネクト帯域幅のタ
イムラインは、適度な帯域幅 (GB/秒単位) で継続的な使用率を示しています。これは、分散コンピューティング
で一般的な間違いの 1 つである、小さなメッセージの通常の MPI 交換が原因です。

より興味深いことは、スレッドごとの詳細な実行時間と [Effective Time (有効時間)]、[Spin and Overhead
Time (スピンとオーバーヘッド時間)]、および [MPI Busy Wait Time (MPI ビジー待機時間)] の内訳です。デフォルトのビューは [Super Tiny (最小)] 設定で、パフォーマンスのビジュアルマップにすべてのプロセスとス
レッドをまとめて表示します。

このケースでは、ほとんどのスレッドで有効時間がわずかしかなく (緑色)、MPI オーバーヘッドの量もわずかです (黄色)。これは、スレッド化の実装に潜在的な問題があることを示しています。
さらに詳しく調査するため、グラフの左側の灰色の領域を右クリックして、[Rich (最大)] ビューを選択します。
次に、各 MPI ランクと各スレッドの役割がより明確になるように、グラフの右側で [Process/Thread (プロセス/スレッド)] を選択して結果をグループ化します。このグループ化を使用することで、各プロセスの最上部のバーはすべての子スレッドの平均結果を示し、その下に各スレッドがスレッド番号とプロセス ID とともにリス
トされます。
この例では、マスタースレッドが各 MPI ランクのすべての MPI 通信を明確に処理しています。これはハイブ
リッド・アプリケーションでは一般的です。実行の最初の 10 秒間は、MPI 通信 (黄色) に多くの時間が費やされています。ここでは、問題のセットアップとデータの分配が行われていると考えられます。その後は通常の MPI通信となり、[Bandwidth Utilization (帯域幅使用率)] タイムラインと [Summary (サマリー)] レポートの結果と一致しています。

スピンとオーバーヘッド (デフォルトでは赤色で表示) が高いことが分かります。これは、アプリケーションのス
レッド化の実装に問題があることを示しています。[Bottom-up (ボトムアップ)] ウィンドウの上部で、[OpenMP Region / Thread / Function / Call Stack (OpenMP* 領域/スレッド/関数/コールスタック)] を選択してデータをグループ化し、ウィンドウ下部のフィルターを適用して [Functions only (関数のみ)] を表示します。ツリーを展開すると、init_send_bufs 関数はスレッド 0 以外から呼び出されていないことが分かります。これが、パフォーマンス低下の原因です。この行をダブルクリックするとソースコード・ビューが開きます。
コードを調査すると、関数の外側のループを並列化し、この問題を修正する簡単な方法があることが分かります。

(オプション) インテル® VTune™ Amplifier GUI でコマンドラインを生成する
インテル® VTune™ Amplifier のあまり知られていない便利な機能は、GUI を使用して解析を設定し、対応するコマンドラインを保存して、コマンドラインから直接使用できます。これは、高度にカスタマイズされたプロファイルや複雑なコマンドを素早く作成するのに便利です。
1. インテル® VTune™ Amplifier を起動して、[New Project (新規プロジェクト)] をクリックするか、既存のプロジェクトを開きます。
2. [Configure Analysis (解析の設定)] をクリックします。
3. [WHERE (どこを)] ペインで [Arbitrary Host (not connected) (任意のホスト (未接続))] を選択し、ハードウェア・プラットフォームを指定します。

4. [WHAT (何を)] ペインで次の操作を行います。

a. アプリケーションを指定して、引数と作業ディレクトリーを設定します。
b. [Use MPI launcher (MPI ランチャーを使用)] チェックボックスをオンにして、MPI 実行に関連した情報を指定します。
c. (オプション) プロファイルする特定のランクを選択します。
5. [HOW (どのように)] ペインでデフォルトの [Hotspots (ホットスポット)] 解析から [HPC
Performance Characterization (HPC パフォーマンス特性)] 解析に変更し、利用可能なオプション
をカスタマイズします。

6. ウィンドウの下部にある [Command Line (コマンドライン)] ボタン

をクリックします。ポップ

アップ・ウィンドウが開き、GUI で設定したカスタム解析に対応するコマンドラインが表示されます。必要に応じて、コマンドにその他の MPI オプションを追加できます。
注インテル® MPI ライブラリーの場合、コマンドラインは -gtool オプションで生成されます。これにより、選択したランクのプロファイル構文が非常に簡潔になります。

(オプション) コマンドライン・レポートを使用して結果を解析する
インテル® VTune™ Amplifier は、有益なコマンドライン・テキスト・レポートを提供します。例えば、サマリーレ
ポートを取得するには、次のコマンドを実行します。
amplxe-cl -report summary -r ./results_dir
結果のサマリーが画面に出力されます。結果を直接ファイルに保存したり、別のファイル形式 (csv、xml、html)で保存するオプションなど、その他のオプションも利用できます。コマンドライン・オプションの詳細は、
amplxe-cl -help コマンドで確認するか、ユーザーガイド (英語) を参照してください。

(オプション) 選択したコード領域をプロファイルする
デフォルトでは、インテル® VTune™ Amplifier はアプリケーション全体のパフォーマンス統計を収集します
が、バージョン 2019 Update 3 以降では MPI アプリケーションのデータ収集を制御する機能が追加されました。この機能を使用することで、高速に処理可能な小さな結果ファイルを生成して、対象コード領域に注目できます。
領域の選択は、MPI_Pcontrol 関数を使用して行います。MPI_Pcontrol(0) 呼び出しでデータ収集を一時停止し、MPI_Pcontrol(1) 呼び出しで再開します。API と -start-paused コマンドライン・オプション
を一緒に使用して、アプリケーションの初期化フェーズを除外できます。この場合、初期化の直後に
MPI_Pcontrol(1) を呼び出してデータ収集を再開します。この方法では、スタティック ITT API ライブラ
リーへのリンクが必要な ITT API 呼び出しを使用する場合とは異なり、アプリケーションのビルドプロセスの変更が不要です。

関連項目
•
•
•
•

インテル® VTune™ Amplifier インストール・ガイド - Linux* (英語)MPI とインテル® Advisor およびインテル® VTune™ Amplifier の使用 (英語)Cray* XC システムでのインテル® VTune™ Amplifier の使用 (英語)
チュートリアル: MPI/OpenMP* ハイブリッド・アプリケーションの解析 (英語)注
このレシピの情報は、デベロッパー・フォーラム (英語) を参照してください。

最適化に関する注意事項
インテル® コンパイラーでは、インテル® マイクロプロセッサーに限定されない最適化に関して、他社製マイクロプロセッサー用に同等の最適化を行えないことがあります。これには、インテル® ストリーミング SIMD
拡張命令 2、インテル® ストリーミング SIMD 拡張命令 3、インテル® ストリーミング SIMD 拡張命令 3 補足命令などの最適化が該当します。インテルは、他社製マイクロプロセッサーに関して、いかなる最適化の利用、機能、または効果も保証いたしません。本製品のマイクロプロセッサー依存の最適化は、インテル® マイ
クロプロセッサーでの使用を前提としています。インテル® マイクロアーキテクチャーに限定されない最適化のなかにも、インテル® マイクロプロセッサー用のものがあります。この注意事項で言及した命令セットの詳細については、該当する製品のユーザー・リファレンス・ガイドを参照してください。
注意事項の改訂 #20110804

Node.js* の JavaScript* コードのプロファイル
このレシピは、Node.js* をリビルドし、インテル® VTune™ Amplifier を使用して、JavaScript* フレームとネ
イティブフレーム (ネイティブコード、例えば、JavaScript* コードから呼び出されたシステム・ライブラリーやネ
イティブ・ライブラリー) から成る混在モードのコールスタックを含む JavaScript* コードのパフォーマンスを解析するための設定手順を説明します。
コンテンツ・エキスパート: Denis Pravdin (英語)••使用するもの手順:
1. Node.js* でインテル® VTune™ Amplifier のサポートを有効にする
2. Node.js* で動作している JavaScript* コードをプロファイルする

使用するもの
以下は、パフォーマンス解析シナリオで使用するハードウェアとソフトウェアのリストです。
•••

アプリケーション: sample.js。このアプリケーションはデモ用であり、ダウンロードすることはできません。
JavaScript* 環境: Node.js* 8.0.0、Chrome* V8 5.8.283.41
パフォーマンス解析ツール: インテル® VTune™ Amplifier 2018: 高度な hotspot 解析
注インテル® VTune™ プロファイラー評価版のダウンロードと製品サポートについては、
https://www.isus.jp/intel-vtune-amplifier-xe/ を参照してください。
o このクックブックのレシピはすべてスケーラブルであり、インテル® VTune™ Amplifier 2018以降に適用できます。バージョンにより設定がわずかに異なることがあります。
o ベータ版インテル® oneAPI ベース・ツールキット向けのバージョンから、インテル® VTune™
Amplifier の名称がインテル® VTune™ プロファイラーに変わりました。引き続き、インテル®
Parallel Studio XE またはインテル® System Studio のコンポーネントとして、あるいはスタ
ンドアロン版のインテル® VTune™ プロファイラーをご利用いただけます。
オペレーティング・システム: Microsoft* Windows* 10o•Node.js* でインテル® VTune™ Amplifier のサポートを有効にする
1. Node.js* のソース (nightly build) をダウンロードします。
2. ルートの node-v8.0.0 フォルダーから vcbuild.bat スクリプトを実行します。
echo vcbuild.bat enable-vtune
このスクリプトは、インテル® VTune™ プロファイラーが JavaScript* コードのプロファイルをサポートするように Node.js* をビルドします。

注••Linux* システムでは、enable-vtune フラグと fully-static 設定フラグを同時に使用しないでください。この組み合わせは互換性がなく、Node.js* 環境がクラッシュします。
Microsoft* Visual Studio* 2015 以降の IDE を使用する場合は、node-v8.0.0win\deps\v8\src\third_party\vtune\vtune-jit.cc ファイルに #define_SILENCE_STDEXT_HASH_DEPRECATION_WARNINGS を追加します。
#include <string.h>#ifdef WIN32#define _SILENCE_STDEXT_HASH_DEPRECATION_WARNINGS#include <hash_map>
using namespace std;
#else
...

Node.js* で動作している JavaScript* コードをプロファイルする
このレシピはサンプル JavaScript* アプリケーションを使用します。
function say(word) {console.log("Calculating ...");
var res = 0;
for (var i = 0; i < 20000; i++) {for (var j = 0; j < 20000; j++) {res = i * j / 2;}}
console.log("Done.");console.log(word);}function execute(someFunction, value) {someFunction(value);}
execute(say, "Hello from Node.js!");インテル® VTune™ Amplifier を使用してこのアプリケーションをプロファイルするには、次の操作を行います。
1. インテル® VTune™ Amplifier を起動します。
amplxe-gui.exe
2. ツールバーの [New Project (新規プロジェクト)]アイコンをクリックして新規プロジェクトを作成します。
3. [Analysis Target (解析ターゲット)] タブで、[Application (アプリケーション)] フィールドにnode.exe、[Application parameters (アプリケーションのパラメーター)] フィールドに
sample.js を指定します。

4. [Analysis Type (解析タイプ)] タブに切り替えて、左ペインから [Advanced Hotspots (高度なhotspot)] 解析タイプを選択し、[Start (開始)] をクリックして解析を実行します。
注
高度な hotspot 解析は、インテル® VTune™ Amplifier 2019 で汎用の hotspot 解析 (英語) に統合されました。ハードウェア・イベントベース・サンプリング収集モードで利用できます。

解析が完了すると、インテル® VTune™ Amplifier はデフォルトの [Hotspots (Hotspot)] ビューポイントに結果を表示します。[Bottom-up (ボトムアップ)] ウィンドウを使用して、サンプルが JavaScript* 関数にどのように分散されているか調べます。最も CPU 時間がかかっている関数をダブルクリックしてソースコードを表示
し、最もホットなコード行を特定します。

Docker* コンテナーでのプロファイル
このレシピは、インテル® VTune™ Amplifier の解析向けに Docker* コンテナーを構成して、独立したコンテ
ナー環境で動作しているアプリケーションの hotspot を特定します。
コンテンツ・エキスパート: Denis Pravdin (英語)••使用するもの
手順:
1. Docker* コンテナーをインストールして設定する
2. アタッチモードで高度な hotspot 解析を実行する
3. コンテナーで収集したデータを解析する

注
高度な hotspot 解析は、インテル® VTune™ Amplifier 2019 で汎用の hotspot 解析 (英語) に統合されました。ハードウェア・イベントベース・サンプリング収集モードで利用できます。

使用するもの
以下は、パフォーマンス解析シナリオで使用するハードウェアとソフトウェアのリストです。
••

アプリケーション: MatrixMultiplication。この Java* アプリケーションはデモ用であり、ダウンロードすることはできません。
ツール: インテル® VTune™ Amplifier 2018: 高度な hotspot 解析
注インテル® VTune™ プロファイラー評価版のダウンロードと製品サポートについては、
https://www.isus.jp/intel-vtune-amplifier-xe/ を参照してください。
o このクックブックのレシピはすべてスケーラブルであり、インテル® VTune™ Amplifier 2018以降に適用できます。バージョンにより設定がわずかに異なることがあります。
o ベータ版インテル® oneAPI ベース・ツールキット向けのバージョンから、インテル® VTune™
Amplifier の名称がインテル® VTune™ プロファイラーに変わりました。引き続き、インテル®
Parallel Studio XE またはインテル® System Studio のコンポーネントとして、あるいはスタ
ンドアロン版のインテル® VTune™ プロファイラーをご利用いただけます。
Linux* コンテナーランタイム: docker.io
オペレーティング・システム: Ubuntu* 17.04
CPU: インテル® プロセッサー (開発コード名 Skylake)、8 論理 CPU
o

•
•
•

Docker* コンテナーをインストールして設定する
1. [オプション] 必要に応じて、ホストシステムから以前の Docker* バージョンを削除します。
host> sudo apt-get remove docker

2. Docker* をインストールします。
host> sudo apt-get update
host> sudo apt-get install docker.io
注Docker* コンテナーランタイムのバージョンはオペレーティング・システムのバージョンに依存します。apt-cache search "container runtime" と入力すると、正しいバージョンが表示されます。
o パッケージをインストールできない場合、Docker* の systemd サービスファイルでプロキ
シーサーバーが設定されていることを確認してください。詳細は、https://docs.docker.com/engine/admin/systemd/#httphttps-proxy (英語) を参照してください。ステップ 1 から 6 に従い、例のプロキシー名を使用するプロキシー名に変更します。
o インストールの詳細は、https://docs.docker.com/engine/installation/linux/dockerce/ubuntu/#install-docker-ce (英語) を参照してください。
3. Docker* イメージを作成します。
ohost> cd /tmp
host> touch Dockerfile
host> echo FROM ubuntu:latest > ./Dockerfile
host> docker build -t myimage .
Sending build context to Docker daemon 6.295 MB
Step 1: FROM ubuntu:latest
e0a742c2abfd: Pull complete
486cb8339a27: Pull complete
dc6f0d824617: Pull complete
4f7a5649a30e: Pull complete
672363445ad2: Pull complete
Digest:sha256:84c334414e2bfdae99509a6add166bbb4fa4041dc3fa6af08046a66fed3005f
Status: Downloaded newer image for ubuntu:latest---> 14f60031763d
Successfully built 14f60031763d
イメージ myimage が作成されたことを確認します。
host> docker images
REPOSITORYTAG
IMAGE ID
CREATED
SIZE
myimagelatest14f60031763d
2 weeks ago
119.5 MB注
docker load -i image.tar コマンドを使用して、ファイルから圧縮されたリポジトリーをロードすることもできます。
4. -t および -d オプションを使用してコンテナーを実行します。
host> docker run -td myimage

注インテル® VTune™ Amplifier のアルゴリズム解析 (基本 hotspot、並行性、ロックと待機) 向けに
Docker* コンテナーを実行するには、次のように ptrace サポートを有効にします。
host> docker run --cap-add=SYS_PTRACE -td myimage
または、privileged モードでコンテナーを起動します。
host> docker run –-privileged -td myimage
5. コンテナー ID を確認します。
host> docker ps
CONTAINER ID
STATUS
98fec14f0c08
Up 9 seconds

IMAGE
PORTS
myimage

COMMAND
NAMES"/bin/bash"
sharp_thompson

CREATED
10 seconds ago

6. コンテナー ID を使用してバックグラウンド・モードで (bash シェルを起動して) コンテナーに入ります。
host> docker exec -it 98fec14f0c08/bin/bash

7. Java* アプリケーションと JVM を動作中の Docker* インスタンスにコピーします。次に例を示します。
host> docker cp /home/samples/jdk1.8.tar 98fec14f0c08:/var/local
host> docker cp /home/samples/matrix.tar 98fec14f0c08:/var/local
8. matrix.tar および jdk アーカイブを展開します。

アタッチモードで高度な hotspot 解析を実行する
1. ホストでインテル® VTune™ Amplifier を起動します。
host> cd /opt/intel/vtune_amplifier_2018.0.2.522558
host> source ./amplxe-vars.sh
host> amplxe-gui
2. プロジェクト (例: matrix_java) を作成します。
3. コンテナー内で Java* アプリケーションを実行します。
container> cd /var/local/matrix
container> /var/local/jdk1.8.0_72-x64/bin/java -cp .
MatrixMultiplication 2000 2000 2000 2000
4. top コマンドを実行して java プロセスの PID を取得します。
5. [Analysis Target (解析ターゲット)] タブで次の項目を設定します。
o [local host (ローカルホスト)] ターゲット・システム・タイプ
o [Attach To Process (プロセスにアタッチ)] ターゲットタイプ

ojava の PID (プロセス ID) (例: 24116)o

右の [Binary/Source Search (バイナリー/ソース検索)] ボタンをクリックして、ホスト上のソースが配置されている場所を指定します。

インテル® VTune™ Amplifier は、このパスを検索して、hotspot の原因であるソースコードとマシン命令を関連付けます。
6. [Analysis Type (解析タイプ)] タブに切り替えて、[Advanced Hotspots (高度な hotspot)] 解析タ
イプを選択し、[Hotspots and stacks (hotspot とスタック)] オプションを選択します。

7. [Start (開始)] をクリックして解析を開始します。

コンテナーで収集したデータを解析する
データ収集が完了すると、インテル® VTune™ Amplifier はデフォルトの [Hotspots (hotspot)] ビューポイン
トに結果を表示します。

[Summary (サマリー)] ビューの [Top Hotspots (上位の hotspot)] セクションは、ターゲット・アプリケー
ションの multiply 関数に最も CPU 時間がかかっていることを示しています。リストの関数をクリックして[Bottom-up (ボトムアップ)] タブに切り替え、この hotspot 関数のスタックフローを確認します。

詳細に解析するため、hotspot 関数をダブルクリックして関数の hotspot ソース行を特定し、この行で収集されたメトリックデータを解析します。
Docker* コンテナーモジュールの統計を取得するには、[Module/Function/Call Stack (モジュール/関数/
コールスタック)] でデータをグループ化し、モジュールパスの docker エントリーでコンテナーモジュールを識別します。

注
このレシピの情報は、デベロッパー・フォーラム (英語) を参照してください。

関連項目
•
•

Java* コード解析 (英語)
コンテナーターゲットのプロファイル (英語)Singularity* コンテナーでのプロファイル
このレシピは、インテル® VTune™ Amplifier の解析向けに Singularity* コンテナーを構成して、独立したコンテナー環境で動作しているアプリケーションの hotspot を特定します。
コンテンツ・エキスパート: Denis Pravdin (英語)••使用するもの手順:
1. Singularity* コンテナーをインストールして設定する
2. コンテナー内でパフォーマンス解析を実行する

使用するもの
以下は、パフォーマンス解析シナリオで使用するハードウェアとソフトウェアのリストです。
•

アプリケーション: MatrixMultiplication。
この Java* アプリケーションはデモ用であり、ダウンロードすることはできません。

•

ツール: インテル® VTune™ Amplifier 2018注インテル® VTune™ プロファイラー評価版のダウンロードと製品サポートについては、
https://www.isus.jp/intel-vtune-amplifier-xe/ を参照してください。
o このクックブックのレシピはすべてスケーラブルであり、インテル® VTune™ Amplifier 2018以降に適用できます。バージョンにより設定がわずかに異なることがあります。
o ベータ版インテル® oneAPI ベース・ツールキット向けのバージョンから、インテル® VTune™
Amplifier の名称がインテル® VTune™ プロファイラーに変わりました。引き続き、インテル®
Parallel Studio XE またはインテル® System Studio のコンポーネントとして、あるいはスタ
ンドアロン版のインテル® VTune™ プロファイラーをご利用いただけます。
Linux* コンテナーランタイム: singularity
オペレーティング・システム: Ubuntu* 16.04
CPU: インテル® プロセッサー (開発コード名 Skylake)、8 論理 CPU
o

•
•
•

Singularity* コンテナーをインストールして設定する
1. Singularity* ソフトウェア (例えばバージョン 2.4.5) をインストールします。
host> VERSION=2.4.5
host> wget
https://github.com/singularityware/singularity/releases/download/$VERSI
ON/singularity-$VERSION.tar.gz
host> tar xvf singularity-$VERSION.tar.gz
host> cd singularity-$VERSION
host>./configure --prefix=/usr/local

host> makehost> sudo make install
注
詳しいインストール手順は、https://singularity.lbl.gov/install-linux (英語) を参照してください。
2. 新しい Singularity* コンテナーを、例えば Docker* Hub を使用して作成します。
host> singularity build ubuntu.img docker://ubuntu:latest
Docker image path: index.docker.io/library/ubuntu:latest
Cache folder set to /root/.singularity/docker
Importing: base Singularity environment
Importing:/root/.singularity/docker/sha256:d3938036b19cfa369e1081a6776b07b54be961
2bc4c8fed7f139370c8142b79f.tar.gz
Importing:/root/.singularity/docker/sha256:a9b30c108bda615dc10e402f62d712f413214e
a92c7ec4354cd1cc0f3450bc58.tar.gz
Importing:/root/.singularity/docker/sha256:67de21feec183fcd009a5eddc4de8c346ee0f4
369a20047f1a302a90716fc741.tar.gz
Importing:/root/.singularity/docker/sha256:817da545be2ba4bac8f6b4da584bca0fb48449
38ecc462b9feab1001b5df7405.tar.gz
Importing:/root/.singularity/docker/sha256:d967c497ce230b63996a7b1fc6ec95b741aea9348118d3328c676f13be789fa7.tar.gz
Importing:/root/.singularity/metadata/sha256:c6a9ef4b9995d615851d7786fbc2fe72f723
21bee1a87d66919b881a0336525a.tar.gz
Building Singularity image...
Singularity container built: ubuntu.img
Cleaning up...
注
Ubuntu.img ファイルが現在のディレクトリーに作成されることを確認してください。
3. コンテナーを実行します。
Singularity* は、ホストシステム上のディレクトリーをコンテナー内にマップできます。これにより、簡単にホストシステム上のデータを読み書きできます。例えば、インテル® VTune™ Amplifier と Java*
アプリケーションでホストフォルダー /tmp/vtune を使用する場合、コンテナーを実行して/tmp/vtune をコンテナー内の /local/vtune へマップする必要があります。
host> singularity shell --bind /tmp/vtune:/local/vtune ./ubuntu.img
Singularity: Invoking an interactive shell within container...
Singularity ubuntu.img:~>コンテナー内でパフォーマンス解析を実行する
Singularity* コンテナーからインテル® VTune™ Amplifier のコマンドライン・インターフェイス amplxe-clを起動して、Java* アプリケーションの解析を実行します。例えば、MatrixMultiplication アプリケー
ションの高度な hotspot 解析を実行するには、次のコマンドを入力します。
Singularity ubuntu.img:~> cd /local/vtune/matrix/
Singularity ubuntu.img:/local/vtune/matrix> /local/vtune/bin64/vtune -collectadvanced-hotspots -- /local/vtune/jdk9.0.1-x64/bin/java -cp .
MatrixMultiplication 2000 2000 2000 2000
注••

Singularity* コンテナーで動作しているターゲット・アプリケーションをプロファイルするには、同じコンテナーからインテル® VTune™ Amplifier を起動します。Singularity* プロファイルでは、コンテ
ナー外からのインテル® VTune™ Amplifier の実行はサポートされていません。
高度な hotspot 解析は、インテル® VTune™ Amplifier 2019 で汎用の hotspot 解析 (英語) に統合されました。ハードウェア・イベントベース・サンプリング収集モードで利用できます。

収集後、ホストシステムにインストールされているインテル® VTune™ Amplifier の GUI から解析結果がを開き、従来の解析フローに従ってアプリケーション・パフォーマンスの概要を提供する [Summary (サマリー)]ウィンドウから開始します。

注Singularity* コンテナー外 (例えば、ホストシステムにインストールされているインテル® VTune™ Amplifierの GUI ) で解析結果を再ファイナライズする必要がある場合、モジュールに必要なすべてのバイナリーとソー
スファイルにコンテナー外からアクセスできることを確認してください。

関連項目•

Java* コード解析 (英語)Linux*、Android*、および QNX* のシステムブート時のプロファイル
このレシピは、インテル® VTune™ Amplifier のパフォーマンス解析を Linux*、Android*、および QNX* オペ
レーティング・システムのブートフローと統合する方法を示します。この解析は、OS ブート時に CPU コアで予想外に長く実行されるアクティビティーを識別するのに役立ちます。これにより、ブート順序のさらに詳しい調査が可能になります。
コンテンツ・エキスパート: Vitaly Slobodskoy (英語)、Kirill Uhanov (英語)、Dmitry Obrezchikov (英語)、Artem Shcherbak (英語)
ブート時のプロファイルでは、インテル® VTune™ Amplifier のパフォーマンス・データ収集コマンドを (初期化
スクリプトで設定するか、特定のサービスを使用して) OS ブートの初期段階に挿入します。最良の結果を得る
ため、次の要件を満たしていることを確認してください。
•••

インテル® VTune™ Amplifier データコレクターのバイナリーファイルを利用可能な最も早くロードされるファイル・ディレクトリーに配置します。
Linux* と Android* では、データコレクターはファイルシステムに書き込むため、出力ファイル名は利用可能な最も早くロードされる書き込み可能ディレクトリーを使用する必要があります。
Linux* と Android* では、インテル® VTune™ Amplifier のデータ収集コマンドはファイルシステムの可用性に依存すべきです。QNX* では、コマンドはネットワークの可用性に依存すべきです。

注
このアプローチは、OS ブート時のいくつかの問題に対処するのに適していますが、ブートプロセス全体をカバーすることはできません。例えば、カーネルの展開とファイルシステムのマウントはカバーされません。
••

使用するもの
手順:
1. ターゲットシステムのブート時をプロファイルする▪ systemd を利用する Linux* システム
▪ QNX* システム▪ Android* システム
2. 結果をインテル® VTune™ Amplifier プロジェクトへインポートする
3. プロセスの実行を解析する

使用するもの
以下は、パフォーマンス解析シナリオで使用するソフトウェアのリストです。
••

オペレーティング・システム:o systemd によりシステムを初期化する Linux* (root アクセスが有効)
o QNX*ツール:
o QNX* Momentics* ツールスイート

oo

QNX* 7.0 SDK
インテル® VTune™ Amplifier 2019 以降

oインテル® VTune™ プロファイラー評価版のダウンロードと製品サポートについては、
https://www.isus.jp/intel-vtune-amplifier-xe/ を参照してください。
このクックブックのレシピはすべてスケーラブルであり、インテル® VTune™ Amplifier 2018以降に適用できます。バージョンにより設定がわずかに異なることがあります。
ベータ版インテル® oneAPI ベース・ツールキット向けのバージョンから、インテル® VTune™
Amplifier の名称がインテル® VTune™ プロファイラーに変わりました。引き続き、インテル®
Parallel Studio XE またはインテル® System Studio のコンポーネントとして、あるいはスタ
ンドアロン版のインテル® VTune™ プロファイラーをご利用いただけます。

注ooLinux* ターゲットシステムのブート時をプロファイルする
必要条件:
•
•

ターゲット Linux* システムにインテル® VTune™ Amplifier をインストール (英語) します。
システムの初期化方法をチェックします。システムが systemd を使用していることを確認するには、次のコマンドを実行します。
systemctl | grep "\-\.mount"systemd が使用されている場合、次の出力になります。
-.mount

loadedactivemounted/Linux* システムのブート時をプロファイルする
1. /boot_profile ファイルを作成して、インテル® VTune™ Amplifier のハードウェア解析 (hotspot、
I/O、ほか) を実行するように設定します。
例えば、高精度のデータが得られるように短いサンプリング間隔でシステム全体の hotspot 解析を
30 秒間実行するには、次のコマンドを使用します。
#!/bin/bash/opt/intel/vtune_amplifier/bin64/amplxe-cl -c hotspots -knob samplingmode=hw -knob sampling-interval=0.1 -d 30 -finalization-mode=none -r/tmp/boot_profile &注oo

ファイル内のパスがインテル® VTune™ Amplifier のインストール・ディレクトリーを正しく指定していることを確認してください。デフォルトでは、Linux* のインストール・ディレクトリー
は、/opt/intel/vtune_amplifier です。
boot_profile スクリプトのパスは、/tmp など、初期ブート段階で利用可能な任意のローカルパスにすることができます。

2. データ収集起動スクリプトの権限を変更します。
chmod 755 /boot_profile
3. 次の内容で /etc/systemd/system/vtune_boot.service ファイルを作成します。
[Unit]
Description=VTune Amplifier boot profile service[Service]
Type=forking
ExecStart=/boot_profile[Install]WantedBy=multi-user.target
4. サービスを有効にします。
systemctl enable vtune_boot
5. システムを再起動して、OS ブートプロセス中にインテル® VTune™ Amplifier のデータ収集を開始します。
データ収集が完了すると、/tmp/boot_profile に結果ディレクトリーが生成されます。このディレクトリー
は root ユーザー以下にあります。通常のユーザーで結果を開く必要がある場合、フォルダーのアクセス権限を変更してください。
sudo chmod -R a+w /tmp/boot_profile
追加のコマンド•

サービスを無効にします。
systemctl disable vtune_boot•

障害が発生した場合、OS ブートプロセス中にインテル® VTune™ Amplifier コレクター の出力を解析します。
sudo journalctl -u vtune_bootAndroid*ターゲットシステムのブート時をプロファイルする
必要条件:
1. ホストシステムにインテル® VTune™ Amplifier をインストールします。
2. Android* ターゲットシステムで lsmod コマンドを実行して、インテルのサンプリング・ドライバーが利用できることを確認します。

ドライバー (pax.ko、sep5.ko、socperf3.ko) が見つからない場合、以降のステップをスキップしてドライバーを使用しないモードで続行するか、以降のステップに従ってドライバーをビルドして署名します。
a. ホストシステムで次のコマンドを実行します。
<vtune-install-dir>/target/<android-version-arch>/sepdk/builddriverb. 入力を求められたら、ターゲットシステムのビルドに使用する GCC* コンパイラーとAndroid* カーネル・ソース・ディレクトリーのパスを指定します。
例えば、カーネル・ソース・ディレクトリーは <android-source-dir>/out/target/
product/<name>/obj/kernel で、コンパイラー・ディレクトリーは <androidsource-dir>/prebuilts/gcc/linux-x86/x86/x86_64-linux-android<version>/bin/x86_64-linux-android-gcc です。
ビルドしたドライバーは次のディレクトリーにあります。
▪

<vtune-install-dir>/target/<android-version-arch>/sepdk/pax/pax.ko▪ <vtune-install-dir>/target/<android-version-arch>/sepdk/
sep5.ko▪ <vtune-install-dir>/target/<android-version-arch>/sepdk/
src/socperf/src/socperf.ko
c. 次のように、ドライバーに署名します。
$KERNEL_DIR/scripts/sign-file $(CONFIG_MODULE_SIG_HASH)$KERNEL_DIR/$(CONFIG_MODULE_SIG_KEY)$KERNEL_DIR/certs/signing_key.x509 <driver_file_name.ko>
ここで、<driver_file_name.ko> は署名するドライバーの名前です。各ドライバーは個別に署名する必要があります。
KERNEL_DIR にあるカーネルの config ファイルを使用して、CONFIG_MODULE_SIG_HASH と CONFIG_MODULE_SIG_KEY パラメーターの値を取得します。
Android* システムのブート時をプロファイルする
1. インテル® VTune™ Amplifier のターゲットコレクターをインストールします。
a. 通常の方法でターゲットシステムをブートします。
b. インテル® VTune™ Amplifier GUI を実行して新しいプロジェクトを作成します。
c. 新しい解析を設定します。[WHERE (どこを)] ペインで、[Android Device (ADB) (Android*
デバイス (ADB))] 接続タイプを選択します。[ADB destination (ADB の対象)] フィールドでターゲットデバイスを選択します。これ以降、インテル® VTune™ Amplifier は自動的にター
ゲットコレクターをターゲットシステムへアップロードします。
2. ターゲットコレクターを利用可能な最も早くロードされるファイルシステムの場所 (例: /vendor) へ
コピーします。
adb shell cp -rf /data/data/com.intel.vtune/perfrun /vendor/vtune

3. インテルのサンプリング・ドライバーが利用可能な場合、pax.ko、sep5.ko、および socperf3.ko
ドライバーを /vendor/vtune へコピーします。
4. 収集トレースの出力先として、利用可能な最も早くロードされる書き込み可能な場所を選択します。例
えば、/data/vtune を選択して、次のインテルのサンプリング・ドライバー・モードまたはドライバー
を使用しないモードのいずれかで実行スクリプト (/vendor/vtune/vtune.sh) を作成します。
インテルのサンプリング・ドライバー・モード

ドライバーを使用しないモード#!/bin/sh
rm -rf /data/vtune
mkdir /data/vtune 0777
/system/bin/insmod /vendor/vtune/pax.ko/system/bin/insmod/vendor/vtune/socperf3.ko/system/bin/insmod /vendor/vtune/sep5.ko
LD_LIBRARY_PATH=/vendor/vtune/perfrun/lib64
SEP_BASE_DIR=/vendor/vtune/perfrun/lib64/
vendor/vtune/perfrun/bin64/sep -start -d 10-out /data/vtune/android_boot.tb7#!/bin/sh rm -rf /data/vtune
mkdir /data/vtune 0777
echo 0 >/proc/sys/kernel/perf_event_paranoidecho 0 >/proc/sys/kernel/kptr_restrict/vendor/vtune/perfrun/bin64/amplxe-perf
record-a -o /data/vtune/android_boot.data-- sleep 10

5. このスクリプトは、hotspot 収集を開始して 10 秒間実行します。
6. このスクリプトをターゲットの init.rc に追加します。実際のブートフローに応じて、post-fs やほかのトリガーの使用を検討してください。
on fs
start vtune
service vtune /vendor/vtune/vtune.shuser rootgroup rootseclabel u:r:init:s0
oneshot
disabled
注
読み取り専用のファイルシステムでは、ホストでこれらのファイルを変更して、ソースコートから
Android* システムをビルドすることを検討してください。
7. オプションで、OS の設定に応じて、次の行を /system/sepolicy/private/file_contexts
ファイルに追加します。
/system/bin/toolbox+ /system/bin/insmod+ /system/bin/sep+ /system/bin/shu:object_r:toolbox_exec:s0
u:object_r:toolbox_exec:s0
u:object_r:toolbox_exec:s0
u:object_r:toolbox_exec:s0

注Android* デバイスが permissive モードでブートされていることを確認します。
8. Android* ターゲットシステムを再起動して、データが収集されるのを待ちます。

9. 詳しく解析するため、/data/vtune/android_boot.tb7 ファイルをホストシステムへコピーします。

QNX* システムのブート時をプロファイルする
必要条件:
•
•
•
•

QNX* Momentics* Tool Suite をホストにインストールします。
QNX* 7.0 SDK をインストールします。
[File] > [Import] > [QNX] > [QNX Source Package and BSP] を選択して BSP を QNX*
Momentics* ワークスペースにインポートします。
ホストシステムにインテル® VTune™ Amplifier をインストール (英語) します。

QNX* システムのブート時をプロファイルする
1. <vtune-install-dir>/target/qnx_x86_64 から <qnx-sdk-path>\qnx700\target\
qnx7\x86_64\usr\bin へターゲット・プロファイル・エージェント (sep バイナリー) をコピーします。
2. QNX* イメージの *.build ファイルを変更します。
a. 文字列 /usr/bin/gzip=gzip を検索して、その後に /usr/bin/sep=sep を追加します。
b. 起動スクリプトセクションに sep -p1 & を追加します。
[+script] startup-script = {...
# NOTE: Temporary enable for UART devices on OCP bridge# will be able to removed once ABL is fixed
ocp_init -d 0:24:0 0x200=0xffff04b5 0x204=7
ocp_init -d 0:24:1 0x200=0xffff04b5 0x204=7
ocp_init -d 0:24:2 0x200=0xffff04b5 0x204=7 # console
ocp_init -d 0:24:3 0x200=0xffff04b5 0x204=7# the sep run before this could move system to unstable# state and crash it
sep -p1 -d 10 &sep ターゲット・プロファイル・エージェントのオプションは、次のとおりです。
▪

-p<mode> は、収集モードを設定します。
0 は、通常のデフォルトのモードです。プロファイル・エージェントは、ホストからのTCP/IP 接続を待機します。
1 は、エージェントがスタックを含まない事前定義済みの収集を開始します。収集サン
プルはターゲットのメモリーに格納されます。ホストへデータを転送するには、
TCP/IP 接続が必要です。
2 は、エージェントがサンプル・コールスタックを含む事前定義済みの収集を開始します。収集サンプルはターゲットのメモリーに格納されます。ホストへデータを転送するには、TCP/IP 接続が必要です。

-d <sec> は、収集の最大期間 (秒) を設定します。収集は、指定した時間が経過した後、またはメモリーバッファーが一杯になると停止します。
▪ -s <sec> は、指定した時間が経過した後に収集を開始します。
▪ -b <size_ratio> は、収集バッファーサイズを設定します (1 ^ size_ratio バイト)。例えば、単一の CPU コアの場合、８MB バッファーサイズは -b 23 と指定します。
エージェントは、CPU コアごとのターゲットメモリーの使用量が 16MB になるように、バッファーの切り替えにダブルバッファー・スキーマを使用します。4 CPU コアの場合、エージェントの合計メモリー使用量は 64MB になります。デフォルト値は 19(0.5MB) です。
3. QNX* イメージをリビルドしてフラッシュします。
4. システムを再起動して、OS ブートプロセス中にインテル® VTune™ Amplifier のデータ収集を開始します。
5. 収集結果をホストに転送します。
▪

事前定義済みの収集モード (-p1 または -p2) では、ターゲット・エージェントはメモリーバッファー内のワークロードを指定された期間プロファイルして、リスニングモードに切り替わり、次のようなメッセージをコンソールに出力します: ‘sep5_0: Waiting for control connection from host on port
XXXX...’ (sep5_0: ポート XXXX でホストからの制御接続を待機しています...)。このメッセージが出力されたら、ホストで sep ユーティリティーを起動して、ネットワーク経由でターゲットから収集データをコピーできます。使用するホストのコマンドライン・オプションがターゲット・エージェントのオプションと対応していることを確認してください。例えば、-p1 モードの場合、ホストコマンドは次のようになります。
<vtune-install-dir>/bin64/sep -start -target-ip <target-system-ipaddress> -target-port 9321 -out /tmp/qnx_boot.tb7-p2 の場合は次のようになります。
<vtune-install-dir>/bin64/sep -start -target-ip <target-system-ipaddress> -target-port 9321 -lbr call_stack -out /tmp/qnx_boot.tb7

結果をインテル® VTune™ Amplifier プロジェクトへインポートする
1. ホストシステムでインテル® VTune™ Amplifier スタンドアロン GUI を起動して、結果のファイナライ
ズ中に適切なバイナリーファイルを選択します。
例えば、Windows* システムでインテル® VTune™ Amplifier を起動するには、次のコマンドを使用します。
<vtune-install-dir>/bin64/amplxe-gui.exe
2. 新しいインテル® VTune™ Amplifier プロジェクトを作成して (英語)、バイナリー/シンボル検索ディレ
クトリー (英語) にカーネルやドライバーのデバッグファイルのパスを設定します。
Linux* ホストでは、kptr_restrict value (英語) を 0 に変更してカーネル関数名の解決を有効にできます。
3. 結果をプロジェクトへインポートする

oLinux* の結果をインポートするには、[Import a result into the current project (現在のプロジェクトに結果をインポート)] オプションを使用します。次に例を示します。

oAndroid* または QNX* から結果をインポートするには、[Import raw data (生のトレース
データをインポート)] オプションを使用して、参照ボタンをクリックして必要な *.tb7 ファイ
ルを選択します。

*.tb7 ファイルがインポートされ結果がファイナライズされたら、[Hotspots by CPU
Utilization (CPU 利用率によるホットスポット)] ビューポイントに切り替えます。

プロセスの実行を解析する
収集結果を開いて [Bottom-up (ボトムアップ)] タブ (英語) をクリックし、最も多くの CPU リソースを占有していたプロセスを特定します。

[Platform (プラットフォーム)] タブに切り替えて、プロセス/サービスの実行シーケンスを解析します。次の操作を行います。
1. タイムラインのグループ化を [Process/Thread (プロセス/スレッド)] に変更します。
2. 右クリックしてコンテキスト・メニューを開き、[Sort by (ソート)] から [Row Start Time (開始時間行)] と [Ascending (昇順)] を選択して行をソートします。

3. プロセスの実行順序を解析します。

関連項目
•
•

QNX* ターゲット (英語)
結果とトレースをインテル® VTune™ Profiler GUI へインポートする (英語)システム・アナライザーによるリアルタイム・モニタリング
このレシピは、システム・アナライザーの概要を紹介し、ターゲットシステムをリアルタイムにモニタリングして、CPU、GPU、メモリー、ディスク、ネットワークによる制限を特定します。
コンテンツ・エキスパート: Jeffrey K. Reinemann (英語)システム・アナライザーは、継続的なリアルタイム・モニタリングに加えて、基本パフォーマンスとリソースの使用状況に関するデータのレポートを可能にします。これは、インテル® VTune™ Amplifier 2019 Update 2 で追加されたプレビュー機能です。ユーザーからのフィードバックに応じて、将来のアップデートやリリースで利便性やユーザー体験が改善されたり、あるいは削除される可能性があります。
注
ベータ版インテル® oneAPI ベース・ツールキット向けのバージョンから、インテル® VTune™ Amplifier の名称がインテル® VTune™ プロファイラーに変わりました。引き続き、インテル® Parallel Studio XE またはインテル® System Studio のコンポーネントとして、あるいはスタンドアロン版のインテル® VTune™ プロ
ファイラーをご利用いただけます。
データが収集される「ターゲットシステム」には、Linux* または Windows* システムを利用できます。選択したデータを GUI で表示する「ホストシステム」には、Linux*、macOS*、または Windows* システムを利用できます。システム・アナライザーは、ほぼリアルタイムでターゲットシステムをモニタリングし、その高度な結果に基づいて、詳細なプロファイル向けに適切なインテル® VTune™ Amplifier の解析を設定できます。
システム・アナライザーは、ターゲット・データ・コレクターと、パフォーマンス・メトリックのタイムライン・グラフを表示するグラフィカル・ユーザー・インターフェイス (GUI) で構成されています。次のパフォーマンス・メトリッ
クと表示オプションを利用できます。
••••

CPU 使用率と周波数
メモリー使用率 (Linux* のみ)
ネットワーク・スループット (Linux* のみ)
GPU 使用率とその他のグラフィックス・メトリック (インテル® グラフィックス・ドライバーがインストー
ルされている場合)

システム・アナライザーは、インテル® グラフィックス・パフォーマンス・アナライザー (インテル® GPA) パッケージにも含まれます。グラフィックス・レンダリングのワークロードとボトルネックを解析するには、システム・アナ
ライザーとインテル® GAP パッケージに含まれるほかのツールを使用します。
••

使用するもの手順:
1. システム・アナライザーを起動する
2. [System View] を設定する
3. 詳細な解析向けに異常を特定する
4. 異常を検出するようにインテル® VTune™ Amplifier を設定する
5. システム・アナライザーとインテル® VTune™ Amplifier を実行する

使用するもの
以下は、パフォーマンス解析シナリオで使用するソフトウェアのリストです。
•

ツール: インテル® VTune™ Amplifier 2019 (システム・アナライザー・パッケージを含む)
ホスト上のシステム・アナライザー・パッケージのインストール・フォルダーは、<installdir>/system_analyzer です。<install-dir> は、インテル® VTune™ Amplifier のバージョン
により異なります。
o

o
o

o

ベータ版インテル® oneAPI ベース・ツールキットに含まれるインテル® VTune™ プロファイ
ラー: [Program Files]\inteloneapi\vtune\<version> (Windows*)、/opt/intel/inteloneapi/vtune/<version> (Linux*)
スタンドアロン: [Program Files]\IntelSWTools\VTune Profiler <version>(Windows*)、/opt/intel/vtune_profiler_version (Linux* および Android*)
インテル® System Studio: [Program
Files]\IntelSWTools\system_studio_<version>\VTune Profiler(Windows*)、Linux* は次のいずれか:▪ スーパーユーザーの場合:/opt/intel/system_studio_version/vtune_profiler▪ 通常のユーザーの場合:$HOME/intel/system_studio_version/vtune_profiler
Apple* macOS* システム: /Applications/Intel VTune Profiler<version>.app

プロファイルされるターゲットシステムが以前にインテル® VTune™ Amplifier によってプロファイル
されたことがある場合、インテル® VTune™ Amplifier ファイルはホストから設定されたディレクトリーにあります。例えば、/opt/intel/vtune_amplifier_version (root ユーザーのデフォルト) ま
たは /tmp/vtune_amplifier_version (非 root ユーザーのデフォルト)。ターゲット・システム・
アナライザー・ファイルは、system_analyzer/target/ サブディレクトリーにあります。
注ooo

すべてのケースで、ターゲット・システム・コレクター・ファイルは target サブディレクトリーにあり、ホスト GUI は host サブディレクトリーにあります。
システム・アナライザーでサポートされるホスト OS とターゲット OS のリストは、「サポートされるプラットフォームとアプリケーション」 (英語) を参照してください。
インテル® VTune™ Amplifier 評価版のダウンロードと製品サポートについては、
https://www.isus.jp/intel-vtune-amplifier-xe/ を参照してください。

システム・アナライザーを起動する
必要条件:•

ターゲットシステムがホストシステムと異なる場合、ターゲット・データ・コレクター・ファイルをター
ゲットシステムにコピーします。

•Linux* ターゲットシステムで非ルートユーザーとして gpa_router を実行するには、次のコマンドを実行して /proc/sys/dev/i915/perf_stream_paranoid を 0 に設定します。
echo 0 > /proc/sys/dev/i915/perf_stream_paranoid

1. ターゲットシステムでシステム・アナライザー・コレクターをセットアップします。
o Windows* ターゲットシステムでは、システム・アナライザー・コレクター・ディレクトリーに移動して gpa_router を起動します。オプションで、ホストの IPv4 アドレスを指定して、システ
ム・アナライザー GUI を実行し、このインスタンスへの接続を許可することができます。
target> gpa_router.exe --ip-whitelist 10.7.158.142
oLinux* ターゲットシステムでは、システム・アナライザーのターゲット・コレクター・ディレクトリーに移動して gpa_router を起動します。オプションで、ホストの IPv4 アドレスを指定して、システム・アナライザー GUI を実行し、このインスタンスへの接続を許可することができます。
target> ./gpa_router --ip-whitelist 10.0.0.2
システム・アナライザー GUI がターゲットシステムに接続すると、gpa_router は着信接続をレポートします。次に例を示します。
target> ./gpa_router --ip-whitelist 10.0.0.2
Start listening for new connections from port #27072
New incoming connection established with 10.0.0.2.

注使用する TCP ポートを指定するための構文を含む、gpa_router コマンドライン・オプションの詳細を確認するには、gpa_router --help と入力します。
2. システム・アナライザーを起動します。
例えば、Windows* ホストシステムでは、次のコマンドを実行します。
host> SystemAnalyzer.exe
注ターゲットシステムで実行中の gpa_router が「Incoming connection from host <IPv4> wasrejected since address is not in ip-whitelist. (ホスト <IPv4> からの着信接続は、ip-whitelist にないため拒否されました。)」エラーを報告した場合、--ip-whitelist オプションでホストシステムの IPv4 アドレスを指定して gpa_router を再起動します。

3. localhost を指定するか、ターゲットシステムの名前または IPv4 アドレスを指定して、[Connect]
ボタンをクリックします。

[System View] を設定する
1. システム・アナライザーがターゲットシステムに接続したら、[System Profiling] の下にある[System View] オプションを選択します。

2. [System View] では、マウスでグラフの表示領域へメトリックをドラッグアンドドロップして、モニタリングするメトリックを指定します。カウンターを追加する場合は、Ctrl キーを押しながらグラフの表
示領域へカウンターをドラッグします。タイムラインを追加する場合は、メトリックを下部のタイムライ
ン・グラフへドラッグします。

例えば、次に示すような CPU 使用率と周波数、ネットワーク I/O、ディスク I/O のタイムライン・グラフを設定します。

注
グラフに表示するため現在選択されているデータをカンマ区切りのファイルへエクスポートするには、システ
ム・アナライザー GUI ウィンドウの上部にある [CSV] アイコンをクリックします。システム・アナライザー GUI
は、エクスポート先のディレクトリーと *.csv ファイルの名前をタイトルバーに表示します。

詳細な解析向けに異常を特定するシステム・アナライザーが準ランダムで周期的な異常を示す場合 (例えば、ターゲットシステムのネットワーク
負荷がときどき突然ゼロに近くなることがある場合)、インテル® VTune™ Amplifier の入力と出力解析やマイクロアーキテクチャー全般解析で詳しく調査し、原因を特定する必要があります。
この例では、グラフのいくつかの個所で、ディスクへの書き込みとネットワーク・トラフィックが同時にやや低下しています。そして、ある個所ではディスクへの書き込みが通常の倍以上に急増し、同時にネットワーク・トラ
フィックがゼロに近くなっています。

この場合、ディスクへの書き込みが急増する直前にインテル® VTune™ Amplifier の詳細なデータ収集を開始
し、数秒後に停止すべきです。しかしこのケースでは、ディスクへの書き込みが急増するタイミングを正確に事前予測することは困難です。そこで、リングバッファーを使用して、ディスクへの書き込みが急増しネットワー
ク・トラフィックが低下した周辺データの最後の数秒間のみを保存するようにデータ収集を設定すべきです。

異常を検出するようにインテル® VTune™ Amplifier を設定する
最後の 1 ～ 20 秒間のみが保存されディスクへ書き込まれるリングバッファーを使用して、システムの詳細な
プロファイルを行うようにインテル® VTune™ Amplifier を設定できます。
インテル® VTune™ Amplifier GUI では、[WHAT (何を)] ペインの [Attach to Process (プロセスにアタッチ)]、[Profile System (システムをプロファイル)]、または [Launch Application (アプリケーションを起動)]
で、[Limit collected data by: (収集データを制限)] にある [Time from collection end (収集終了からの時間)] オプションを使用してリングバッファーを設定できます。

コマンドラインからリングバッファーを設定し解析を実行するには、--ring-buffer オプションを使用します。

システム・アナライザーとインテル® VTune™ Amplifier を実行する
インテル® VTune™ Amplifier とシステム・アナライザーを同時に実行して、インテル® VTune™ Amplifier の解析により詳細なパフォーマンス・メトリックを取得し、システム・アナライザーによりメトリックの表示をモニタリングしてインテル® VTune™ Amplifier のデータ収集を停止するタイミングを特定します。これにより、想定外の動作が発生する直前、最中、直後のシステムを解析できるだけでなく、収集期間の短縮によりディスクへの書き込みとストレージ要件が軽減され、収集のオーバーヘッドを最小化できます。
このレシピでシステム・アナライザーによって検出されたディスク I/O 問題の場合、入力と出力解析を[System Disk IO API (システムディスク I/O API)] モード （デフォルト） で実行します。

コマンドラインからインテル® VTune™ Amplifier の収集を実行するには、次のコマンドを入力します。
amplxe-cl -collect io -knob collect-memory-bandwidth=true -ring-buffer=20 -duration unlimited
収集したデータを入力と出力ビューポイントで確認します。フィルターを使用したり、タイムラインのディスクへの書き込みが急増しネットワーク・トラフィックが低下している部分へズームインすることで、調査対象を絞り込むことができます。例えば、［Bottom-up (ボトムアップ)] ウィンドウでは、次のように表示されます。

[Platform (プラットフォーム)] ウィンドウでは、次のように表示されます。

関連項目
•
•
•

入力と出力解析 (英語)インテル® グラフィックス・パフォーマンス・アナライザー (インテル® GPA) for Windows* ホスト(英語)インテル® グラフィックス・パフォーマンス・アナライザー (インテル® GPA) for Ubuntu* ホスト (英語)チューニング・レシピ
ベータ版インテル® VTune™ プロファイラーと従来のインテル® VTune™ Amplifier で検出可能な最も一般的なパフォーマンスの問題を調査し、パフォーマンスを最適化するためのステップを提供します。
•

•

•

•

•

•

•

•

•

•

•

•

フォルス・シェアリング
このレシピは、インテル® VTune™ Amplifier の全般解析とメモリーアクセス解析を使用してメモリー
依存の linear_regression アプリケーションをプロファイルします。
頻繁な DRAM アクセス
このレシピは、インテル® VTune™ Amplifier のマイクロアーキテクチャー全般解析とメモリーアクセ
ス解析を使用してメモリー依存の matrix アプリケーションをプロファイルし、頻繁な DRAM アクセスの原因を理解します。
低いポート使用率
このレシピは、インテル® VTune™ Amplifier のマイクロアーキテクチャー全般解析を使用してコア依存の matrix アプリケーションをプロファイルし、低いポート使用率の原因を理解します。また、インテル® Advisor を使用してコンパイラーがベクトル化を行うようにします。
命令キャッシュミス
このレシピは、インテル® VTune™ Amplifier の全般解析を使用してフロントエンド依存のアプリケー
ションをプロファイルし、PGO オプションを指定して ICache ミスを減らします。
非効率な同期
このレシピは、スタック収集を有効にしてインテル® VTune™ Amplifier の高度な hotspot 解析を実行し、コードの非効率な同期を特定する方法を説明します。
非効率な TCP/IP 同期
このレシピは、タスク収集を有効にしてインテル® VTune™ Amplifier のロックと待機解析を実行し、コードの非効率な TCP/IP 同期を特定する方法を説明します。
I/O 問題: リモート・ソケット・アクセス
このレシピは、インテル® VTune™ Amplifier の全般解析を使用して、マルチソケット・システムにおける潜在的な構成ミス問題について DPDK ベースのアプリケーションを解析します。このレシピは、I/O
依存のワークロードにも使用できます。
I/O 問題: 高いレイテンシーと低い PCIe* 帯域幅
このレシピは、I/O 依存のサンプル・アプリケーションに対してインテル® VTune™ Amplifier のディス
ク I/O 解析を実行します。そして、PCIe* デバイス向けにアフィニティーを変更して、読み取りアクセスの帯域幅が向上するように最適化します。
OS スレッド・マイグレーション
このレシピは、インテル® VTune™ Amplifier の高度な hotspot 解析を使用して NUMA アーキテク
チャーの OS スレッド・マイグレーションを特定する手順を説明します。
OpenMP* インバランスとスケジュール・オーバーヘッド
このレシピは、バリアやスケジュール・オーバーヘッドのインバランスなど、OpenMP* プログラムでよくある並列ボトルネックを検出して修正する方法を説明します。
低いプロセッサー・コア利用率: OpenMP* シリアル時間
このレシピは、OpenMP* で並列化されたアプリケーションのシリアル実行部分を特定し、追加の並列化の機会を見つけ、アプリケーションのスケーラビリティーを向上します。
インテル® TBB アプリケーションのスケジュール・オーバーヘッド
このレシピは、インテル® スレッディング・ビルディング・ブロック (インテル® TBB) アプリケーションのスケジュール・オーバーヘッドを検出して修正する方法を説明します。

•

PMDK アプリケーションのオーバーヘッド
このレシピは、PMDK ベースのアプリケーションのメモリーアクセスのオーバーヘッドを検出して修正する方法を説明します。

フォルス・シェアリング
このレシピは、インテル® VTune™ Amplifier の全般解析とメモリーアクセス解析を使用してメモリー依存のlinear_regression アプリケーションをプロファイルします。
コンテンツ・エキスパート: Dmitry Ryabtsev (英語)••使用するもの手順:
1. 全般解析を実行する
2. ボトルネックを特定する
3. 競合するデータ構造を見つける
4. フォルス・シェアリング問題を修正する

注
全般解析は、インテル® VTune™ Amplifier 2019 でマイクロアーキテクチャー全般解析に改名されました。

使用するもの
以下は、パフォーマンス解析シナリオで使用するハードウェアとソフトウェアのリストです。
••

アプリケーション: linear_regression。linear_regression.tgz サンプルパッケージは、製品の <install-dir>/samples/en/C++ ディレクトリーに含まれています。
https://github.com/kozyraki/phoenix/tree/master/sample_apps/linear_regression (英語) からダウンロードすることもできます。
パフォーマンス解析ツール:o インテル® VTune™ Amplifier 2018: 全般解析、メモリーアクセス解析
注インテル® VTune™ プロファイラー評価版のダウンロードと製品サポートについては、
https://www.isus.jp/intel-vtune-amplifier-xe/ を参照してください。
o このクックブックのレシピはすべてスケーラブルであり、インテル® VTune™ Amplifier 2018以降に適用できます。バージョンにより設定がわずかに異なることがあります。
o ベータ版インテル® oneAPI ベース・ツールキット向けのバージョンから、インテル® VTune™
Amplifier の名称がインテル® VTune™ プロファイラーに変わりました。引き続き、インテル®
Parallel Studio XE またはインテル® System Studio のコンポーネントとして、あるいはスタ
ンドアロン版のインテル® VTune™ プロファイラーをご利用いただけます。
オペレーティング・システム: Ubuntu* 16.04 64 ビット
CPU: インテル® Core™ i7-6700K プロセッサー
o••

全般解析を実行する
サンプル・アプリケーションの潜在的なパフォーマンス・ボトルネックを理解するため、まず、インテル®
VTune™ Amplifier の全般解析を実行します。

1. ツールバーの [New Project (新規プロジェクト)] ボタンをクリックして、新規プロジェクトの名前 (例:linear_regression) を指定します。
2. [Analysis Target (解析ターゲット)] ウィンドウで、ホストベースの解析として [local host (ローカルホスト)] ターゲット・システム・タイプを選択します。
3. [Launch Application (アプリケーションを起動)] ターゲットタイプを選択して、右ペインで解析する
アプリケーションを指定します。
4. 右の [Choose Analysis (解析の選択)] ボタンをクリックし、[Microarchitecture Analysis (マイクロアーキテクチャー解析)] > [General Exploration (全般)] を選択して、[Start (開始)] をクリックします。
インテル® VTune™ Amplifier は、アプリケーションを起動してデータを収集し、収集したデータをファ
イナライズして、シンボル情報を解決します。この情報は、ソース解析で必要になります。

ボトルネックを特定する
ハードウェア・メトリックごとのアプリケーション・レベルの統計が表示される [Summary (サマリー)] ビュー
から始めます。
一般に、パフォーマンス解析では、ベースラインを作成して以降の最適化を測定することを推奨します。このケースでは、アプリケーションの [Elapsed Time (経過時間)] をベースラインとして使用します。

サマリーメトリックから、メモリーアクセスの競合によりアプリケーションのパフォーマンスが制限されていることが分かります。

競合するデータ構造を見つける[Contested Accesses (アクセス競合)] メトリックの値が高い原因を調べるため、[Analyze dynamic
memory objects (動的メモリー・オブジェクトを解析)] オプションを有効にしてメモリーアクセス解析を実行します。この解析は、競合問題の原因になっているデータ構造へのアクセスを見つけるのに役立ちます。

[Summary (サマリー)] ビューから、ファイル stddefines.h の行 52 のメモリー割り当てデータ・オブジェ
クトでアプリケーション実行のレイテンシーが高くなっていることが分かります。割り当てのサイズは 512 バイ
トと非常に小さいため、L1 キャッシュに完全に収まるはずです。詳細を確認するため、このオブジェクトをクリックして [Bottom-up (ボトムアップ)] ビューに切り替えます。

このオブジェクトの平均アクセス・レイテンシーは 59 サイクルと、L1 キャッシュ上にあると予想されるメモ
リーサイズとしては非常に高い値になっています。これがアクセス競合パフォーマンス問題の原因になっている可能性があります。
グリッドの stddefines.h:52 (512B) メモリー・オブジェクトを展開して割り当てスタックを表示します。割り当てスタックをダブルクリックして [Source (ソース)] ビューを開きます。オブジェクトが割り当てられているコー
ド行がハイライトされます。

lreg_args の内容を次に示します。
typedef struct{
pthread_t tid;
POINT_T *points;
int num_elems;
long long SX;long long SY;long long SXX;
long long SYY;
long long SXY;
} lreg_args;
次のように、lreg_args 配列にアクセスしているコードをスレッド化します。
// ADD Up RESULTS
for (i = 0; i < args->num_elems; i++){//Compute SX, SY, SYY, SXX, SXY
args->SX += args->points[i].x;
args->SXX += args->points[i].x*args->points[i].x;
args->SY += args->points[i].y;args->SYY += args->points[i].y*args->points[i].y;args->SXY += args->points[i].x*args->points[i].y;}
各スレッドは別々に配列の要素にアクセスしているため、フォルス・シェアリング問題が考えられます。
サンプルの lreg_args 構造のサイズは 64 バイトで、キャッシュラインのサイズと一致しています。しかし、これらの構造の配列を割り当てるときに、この配列が 64 バイトでアライメントされる保証はありません。その結果、配列要素がキャッシュライン境界を超えて、意図しない競合問題 (フォルス・シェアリング) が発生することがあります。

フォルス・シェアリング問題を修正する
このフォルス・シェアリング問題を修正するため、メモリーを 64 バイト・アライメントで割り当てる_mm_malloc 関数に変更します。

再コンパイルしてインテル® VTune™ プロファイラーのアプリケーション解析を再度実行すると、結果は次のようになりました。

Elapsed Time (経過時間) は 0.5 秒になり、オリジナルの 3 秒からパフォーマンスが大幅に向上しました。メ
モリー依存のボトルネックが解消し、フォルス・シェアリング問題が修正されました。
注
このレシピの情報は、デベロッパー・フォーラム (英語) を参照してください。

関連項目
•
•
•

マイクロアーキテクチャー全般解析 (英語)
メモリーアクセス解析 (英語)
トップダウン・マイクロアーキテクチャー解析法

頻繁な DRAM アクセス
このレシピは、インテル® VTune™ Amplifier のマイクロアーキテクチャー全般解析とメモリーアクセス解析を使用してメモリー依存の matrix アプリケーションをプロファイルし、頻繁な DRAM アクセスの原因を理解します。
コンテンツ・エキスパート: Dmitry Ryabtsev (英語)••使用するもの
手順:
1. ベースラインを作成する
2. マイクロアーキテクチャー全般解析を実行する
3. ハードウェアの hotspot を特定する
4. メモリーアクセス解析を実行する
5. ホットなメモリーアクセスを特定する
6. ループ交換の最適化を適用する

使用するもの
以下は、パフォーマンス解析シナリオで使用するハードウェアとソフトウェアのリストです。
••

アプリケーション: 2048x2048 サイズの 2 つの行列を乗算する行列乗算サンプル (要素は double型)。matrix_vtune_amp_axe.tgz サンプルパッケージは、製品の <installdir>/samples/en/C++ ディレクトリーに含まれています。https://software.intel.com/enus/product-code-samples (英語) からダウンロードすることもできます。
パフォーマンス解析ツール:o インテル® VTune™ Amplifier 2019: マイクロアーキテクチャー全般解析 (旧: 全般解析)、メ
モリーアクセス解析
注
インテル® VTune™ プロファイラー評価版のダウンロードと製品サポートについては、
https://www.isus.jp/intel-vtune-amplifier-xe/ を参照してください。
o このクックブックのレシピはすべてスケーラブルであり、インテル® VTune™ Amplifier 2018以降に適用できます。バージョンにより設定がわずかに異なることがあります。
o ベータ版インテル® oneAPI ベース・ツールキット向けのバージョンから、インテル® VTune™
Amplifier の名称がインテル® VTune™ プロファイラーに変わりました。引き続き、インテル®
Parallel Studio XE またはインテル® System Studio のコンポーネントとして、あるいはスタ
ンドアロン版のインテル® VTune™ プロファイラーをご利用いただけます。
オペレーティング・システム: Ubuntu* 16.04 64 ビット
CPU: インテル® Core™ i7-6700K プロセッサーo••ベースラインを作成する
サンプルコードの初期バージョンは、次のコードにより、メインカーネルに単純な乗算アルゴリズムを実装しています。
void multiply1(int msize, int tidx, int numt, TYPE a[][NUM], TYPE v[][NUM],
TYPE c[][NUM], TYPE t[][NUM]){
int i,j,k;// Naive implementation
for(i=tidx; i<msize; i=i+numt) {for(j=0; j<msize; j++) {for(k=0; k<msize; k++) {c[i][j] = c[i][j] + a[i][k] * b[k][j];}}}}コンパイルしたアプリケーションの実行には約 22 秒かかります。これが、以降の最適化で使用するパフォーマ
ンスのベースラインとなります。

マイクロアーキテクチャー全般解析を実行する
サンプル・アプリケーションの潜在的なパフォーマンス・ボトルネックを理解するため、まず、インテル®
VTune™ プロファイラーのマイクロアーキテクチャー全般解析を実行します。
1. ツールバーの[New Project (新規プロジェクト)] ボタンをクリックして、新規プロジェクトの名

前 (例: matrix) を指定します。
2. [Configure Analysis (解析の設定)] ウィンドウの [WHERE (どこを)] ペインで、[Local Host (ローカルホスト)] ターゲット・システム・タイプを選択します。
3. [WHAT (何を)] ペインで、[Launch Application (アプリケーションを起動)] ターゲットタイプを選択して、解析するアプリケーションを指定します。
4. [HOW (どのように)] ペインで、[...] ボタンをクリックして [Microarchitecture (マイクロアーキテクチャー)] グループから [Microarchitecture Exploration (マイクロアーキテクチャー全般)] 解析を選択します。

5.

[Start (開始)] ボタンをクリックします。
インテル® VTune™ Amplifier は、アプリケーションを起動してデータを収集し、収集したデータをファ
イナライズして、シンボル情報を解決します。この情報は、ソース解析で必要になります。

ハードウェアの hotspot を特定する
マイクロアーキテクチャー全般解析を実行すると、コードの主要なボトルネックを確認できます。解析したアプ
リケーションの CPU マイクロアーキテクチャーの効率と CPU パイプライン・ストールが表示される[Summary (サマリー)] ビューの [µPipe (µ パイプ)] から解析を始めます。以下の [µPipe (µ パイプ)] では、
出力パイプのフローが非常に狭いため、アプリケーションのパフォーマンスを向上するには、[Retiring (リタイア)] メトリックの値を増やす必要があります。このパイプの主な問題は、[Memory Bound (メモリー依存)]
メトリックの値です。

左側のメトリックツリーから、パフォーマンスは主に DRAM アクセスによって制限されていることが分かります。
[Bottom-up (ボトムアップ)] ビューに切り替えると、アプリケーションに 1 つの大きな hotspot 関数
multiply1 があることが分かります。

この関数をダブルクリックして [Source (ソース)] ビューを開きます。最もパフォーマンス・クリティカルなコー
ド行がハイライトされます。

ほとんどの時間が、3 つの配列 (a、b、および c) を操作しているソース行 51 で費やされています。

メモリーアクセス解析を実行する
最も時間がかかった配列アクセスを調べるため、[Analyze dynamic memory objects (動的メモリー・オブジェクトを解析)] オプションを有効にしてメモリーアクセス解析を実行します。

ホットなメモリーアクセスを特定する
次のように、メモリーアクセス解析結果の [Summary (サマリー)] ウィンドウに、上位のメモリー・オブジェク
トが表示されます。

リストの最初の hotspot オブジェクト matrix.c:121 をクリックして [Bottom-up (ボトムアップ)] ビューに切り替えた後、グリッドでハイライトされているこのオブジェクトをダブルクリックして [Source (ソース)]ビューを開き、このメモリー・オブジェクトの行を確認します。

buf2 変数が addr2 に代入され、それが配列 b に代入されていることが分かります。つまり、問題のある配列
は b と考えられます。ツールバーの[Open Source File Editor (ソース・ファイル・エディターを開く)] ボ

タンをクリックして、コードを再度確認します。

void multiply1(int msize, int tidx, int numt, TYPE a[][NUM], TYPE v[][NUM],
TYPE c[][NUM], TYPE t[][NUM]){
int i,j,k;// Naive implementation
for(i=tidx; i<msize; i=i+numt) {for(j=0; j<msize; j++) {for(k=0; k<msize; k++) {c[i][j] = c[i][j] + a[i][k] * b[k][j];}}}}問題の根本的な原因が分かりました。最内サイクルが非効率な方法で配列 b を反復しているため、各反復で大きなメモリーチャンクにジャンプしています。

ループ交換の最適化を適用する
次のように、j と k にループ交換アルゴリズムを適用します。
for(i=tidx; i<msize; i=i+numt) {for(k=0; k<msize; k++) {for(j=0;j<msize; j++) {c[i][j] = c[i][j] + a[i][k] * b[k][j];}}}新しいコードをコンパイルして実行すると、実行時間は 1.3 秒になり、オリジナル (26 秒) の 20 倍にパフォー
マンスが向上しました。

次のステップ
最適化したコードでマイクロアーキテクチャー全般解析を再度実行します。[µPipe (µ パイプ)] 図の [Retiring(リタイア)] メトリックの値が 10.06% から 63.28% へ大幅に増加しました。

その他のフラグの付いているメトリックに注目して、さらなるパフォーマンス向上の可能性 (例えば、低いポー
ト使用率) を特定します。

関連項目
•
•
•

ハードウェア問題のマイクロアーキテクチャー全般解析 (英語)
メモリーアクセス解析 (英語)
トップダウン・マイクロアーキテクチャー解析法

低いポート使用率
このレシピは、インテル® VTune™ Amplifier のマイクロアーキテクチャー全般解析を使用してコア依存のmatrix アプリケーションをプロファイルし、低いポート使用率の原因を理解します。また、インテル® Advisorを使用してコンパイラーがベクトル化を行うようにします。
コンテンツ・エキスパート: Dmitry Ryabtsev (英語)••使用するもの
手順:
1. ベースラインを作成する
2. マイクロアーキテクチャー全般解析を実行する
3. 低いポート使用率の原因を特定する
4. ベクトル化のオプションを調べる
5. 最新の命令セットを使用してコンパイルする

使用するもの
以下は、パフォーマンス解析シナリオで使用するハードウェアとソフトウェアのリストです。
••

アプリケーション: 2048x2048 サイズの 2 つの行列を乗算する行列乗算サンプル (要素は double型)。matrix_vtune_amp_axe.tgz サンプルパッケージは、製品の <installdir>/samples/en/C++ ディレクトリーに含まれています。https://software.intel.com/enus/product-code-samples (英語) からダウンロードすることもできます。
パフォーマンス解析ツール:o インテル® VTune™ Amplifier 2019: マイクロアーキテクチャー全般解析 (英語)注インテル® VTune™ プロファイラー評価版のダウンロードと製品サポートについては、https://www.isus.jp/intel-vtune-amplifier-xe/ を参照してください。
▪ このクックブックのレシピはすべてスケーラブルであり、インテル® VTune™
Amplifier 2018 以降に適用できます。バージョンにより設定がわずかに異なることがあります。
▪ ベータ版インテル® oneAPI ベース・ツールキット向けのバージョンから、インテル®
VTune™ Amplifier の名称がインテル® VTune™ プロファイラーに変わりました。引
き続き、インテル® Parallel Studio XE またはインテル® System Studio のコンポー
ネントとして、あるいはスタンドアロン版のインテル® VTune™ プロファイラーをご利用いただけます。
o インテル® Advisor: ベクトル化解析 (英語)
オペレーティング・システム: Ubuntu* 16.04 64 ビット
CPU: インテル® Core™ i7-6700K プロセッサー▪

••

ベースラインを作成する
単純な乗算アルゴリズムを実装した matrix コードの初期バージョンを最適化することにより (「頻繁なDRAM アクセス」レシピを参照)、実行時間は 26 秒から 1.3 秒になりました。これが、以降の最適化で使用する新しいパフォーマンスのベースラインとなります。

マイクロアーキテクチャー全般解析を実行する
サンプル・アプリケーションの潜在的なパフォーマンス・ボトルネックを理解するため、全般解析を実行します。
1. ツールバーの[New Project (新規プロジェクト)] ボタンをクリックして、新規プロジェクトの名

前 (例: matrix) を指定します。
[Configure Analysis (解析の設定)] ウィンドウが表示されます。
2. [WHERE (どこを)] ペインで、[Local Host (ローカルホスト)] ターゲット・システム・タイプを選択します。
3. [WHAT (何を)] ペインで、[Launch Application (アプリケーションを起動)] ターゲットタイプを選択して、解析するアプリケーションを指定します。
4. [HOW (どのように)] ペインで、[...] ボタンをクリックして [Microarchitecture (マイクロアーキテクチャー)] > [Microarchitecture Exploration (マイクロアーキテクチャー全般)] を選択します。
5. オプションで、最適化した matrix アプリケーションのように小さなワークロードで、サンプリング間
隔を 0.1 秒にして信頼性のあるメトリック値が得られるか確認します。
6. [Start (開始)] をクリックして解析を開始します。

インテル® VTune™ プロファイラーは、アプリケーションを起動してデータを収集し、収集したデータをファイナライズして、シンボル情報を解決します。この情報は、ソース解析で必要になります。

低いポート使用率の原因を特定する
ハードウェア・メトリックごとのアプリケーション・パフォーマンスの統計が表示される [Summary (サマリー)]ビューから始めます。

主要なボトルネックが [Core Bound (コア依存)] > [Port Utilization (ポート利用率)] に移動し、ほとんどの時間で 3 つ以上の実行ポートが同時に使用されていることが分かります。[Vector Capacity Usage (ベクトル能力の使用)] メトリックもクリティカルな値としてフラグが付いていることに注意してください。これは、コードがベクトル化されていないか、ベクトル化の効率が悪いことを意味します。確認のため、次のように、カーネルの [Assembly (アセンブリー)] ビューに切り替えます。
1. [Vector Capacity Usage (FPU) (ベクトル能力の使用 (FPU))] メトリックをクリックして、このメト
リックでソートされた [Bottom-up (ボトムアップ)] ビューに切り替えます。
2. ホットな multiply1 関数をダブルクリックして [Source (ソース)] ビューを開きます。
3. ツールバーの [Assembly (アセンブリー)] ボタンをクリックして、逆アセンブルしたコードを表示します。

スカラー命令が使用されていることが分かります。コードはベクトル化されていません。

ベクトル化のオプションを調べる
インテル® Advisor のベクトル化アドバイザー・ツールを使用して、コードのベクトル化を妨げている原因を調べます。

インテル® Advisor は、依存関係が仮定されたためにループがベクトル化されなかったと報告しました。詳細に確認するため、ループをマークしてインテル® Advisor の依存関係解析を実行します。

レポートによれば、依存関係は存在していません。インテル® Advisor は、コンパイラーが仮定された依存関係を無視するように #pragma を使用することを推奨しています。

次の ように、matrix コードに #pragma を追加します。
void multiply2_vec(inte msize, int tidx, int numt, TYPE a[][NUM],
TYPE b[][NUM], TYPE c[][NUM], TYPE t[][NUM]{
int i,j,k;for(i=tidx; i<msize; i=i+numt) {for(k=0; k<msize; k++) {#pragma ivdepfor(j=0; j<msize; j++) {c[i][j] = c[i][j] + a[i][j] * b[i][j];}}}}更新したコードをコンパイルして実行すると、実行時間は 0.7 秒になりました。

最新の命令セットを使用してコンパイルする
最新バージョンのコードでインテル® VTune™ プロファイラーのマイクロアーキテクチャー全般解析を再度実行すると、結果は次のようになりました。

[Vector Capacity Usage (ベクトル能力の使用)] は 50% まで向上していますが、まだパフォーマンス・クリ
ティカルのフラグが付いたままです。詳細な情報を得るため、[Assembly (アセンブリー)] ビューを再度調べます。

[Assembly (アセンブリー)] ビューから、ここで使用している CPU はインテル® アドバンスト・ベクトル・エクス
テンション 2 (インテル® AVX2) 命令セットをサポートしているにも関わらず、コードはインテル® ストリーミ
ング SIMD 拡張命令 (インテル® SSE) を使用していることが分かります。新しい命令セットをサポートするため、-xCORE-AVX2 オプションを指定してコードを再コンパイルし、全般解析を再度実行します。
再コンパイルしたコードでは、実行時間は 0.6 秒になりました。マイクロアーキテクチャー全般解析を再度実行して最適化を確認します。[Vector Capacity Usage (ベクトル能力の使用)] メトリックの値は 100% にな
りました。

関連項目
•
•

ハードウェア問題のマイクロアーキテクチャー全般解析 (英語)
トップダウン・マイクロアーキテクチャー解析法

命令キャッシュミス
このレシピは、インテル® VTune™ Amplifier の全般解析を使用してフロントエンド依存のアプリケーション
をプロファイルし、PGO オプションを指定して ICache ミスを減らします。
コンテンツ・エキスパート: Dmitry Ryabtsev (英語)••使用するもの手順:
1. 全般解析を実行する
2. ハードウェアの hotspot を特定する
3. PGO オプションを指定してコードを再コンパイルする
4. 最適化を確認する

注
全般解析は、インテル® VTune™ Amplifier 2019 でマイクロアーキテクチャー全般解析に改名されました。

使用するもの
以下は、パフォーマンス解析シナリオで使用するハードウェアとソフトウェアのリストです。
••

アプリケーション: sqlite データベース・ベースのテストサンプル。このアプリケーションはデモ用であり、ダウンロードすることはできません。
ツール:o インテル® VTune™ Amplifier 2018: 全般解析
注
インテル® VTune™ プロファイラー評価版のダウンロードと製品サポートについては、https://www.isus.jp/intel-vtune-amplifier-xe/ を参照してください。
▪ このクックブックのレシピはすべてスケーラブルであり、インテル® VTune™
Amplifier 2018 以降に適用できます。バージョンにより設定がわずかに異なることがあります。
▪ ベータ版インテル® oneAPI ベース・ツールキット向けのバージョンから、インテル®
VTune™ Amplifier の名称がインテル® VTune™ プロファイラーに変わりました。引
き続き、インテル® Parallel Studio XE またはインテル® System Studio のコンポー
ネントとして、あるいはスタンドアロン版のインテル® VTune™ プロファイラーをご利用いただけます。
o インテル® C++ コンパイラー
オペレーティング・システム: Microsoft* Windows* 7
CPU: インテル® プロセッサー (開発コード名 Skylake)▪

••全般解析を実行する
サンプル・アプリケーションの潜在的なパフォーマンス・ボトルネックを理解するため、まず、インテル®
VTune™ Amplifier の全般解析を実行します。
1. ツールバーの[New Project (新規プロジェクト)] ボタンをクリックして、新規プロジェクトの名

前 (例: sqlite) を指定します。
2. [Analysis Target (解析ターゲット)] ウィンドウで、ホストベースの解析として [local host (ローカルホスト)] ターゲット・システム・タイプを選択します。
3. [Launch Application (アプリケーションを起動)] ターゲットタイプを選択して、右ペインで解析する
アプリケーションを指定します。
4. 右の [Choose Analysis (解析の選択)] ボタンをクリックし、[Microarchitecture Analysis (マイクロアーキテクチャー解析)] > [General Exploration (全般)] を選択して、[Start (開始)] をクリックします。
インテル® VTune™ Amplifier は、アプリケーションを起動してデータを収集し、収集したデータをファ
イナライズして、シンボル情報を解決します。この情報は、ソース解析で必要になります。

ハードウェアの hotspot を特定する
全般解析を実行すると、コードの主要なボトルネックを確認できます。ハードウェア・メトリックごとのアプリ
ケーション・レベルの統計が表示される [Summary (サマリー)] ビューから解析を始めます。フラグの付いているパフォーマンス問題に注目します。

サンプル・アプリケーションは、フロントエンド依存 (パイプライン・スロットの 29.3%) で、命令キャッシュミス
が主要なボトルネック (クロック数の 7.1%) です。
[Bottom-up (ボトムアップ)] タブに切り替えてコードの問題を調べます。[Grouping (グループ)] ツールバーの横の[Customize Grouping (グループのカスタマイズ)] ボタンをクリックして、新しいカスタムグルー

プ [Module/Source File (モジュール/ソースファイル)] を作成します。

新しいグループを収集した結果に適用すると、sqlite3.c ファイルがほとんどの CPU サイクルを費やしているメインの hotspot であると表示されます。

ICache Misses (ICache ミス) メトリックに移動すると、sqlite3.c ファイルの値も高いことが分かります。

PGO オプションを指定してコードを再コンパイルする
インテル® C++ コンパイラーを使用して、プロファイルに基づく最適化 (PGO) を sqlite ライブラリーに適用します。
1. /Qprof-gen オプションを指定してコードを再コンパイルします。
2. ベンチマークを実行します。
3. /Qprof-use オプションを指定してコードを再コンパイルします。
詳細は、「プロファイルに基づく最適化の概要」 (英語) を参照してください。

最適化を確認する最適化したコードで全般解析を再度実行します。新しい結果では、Elapsed Time (経過時間) は 30.3 秒になり、オリジナルの 31.5 秒からパフォーマンスが約 4% 向上しました。

sqlite ライブラリーで ICache ミスによりストールしていたクロック数は 9.3% から 6.4% に減りました。

関連項目
•
•
•

ハードウェア問題のマイクロアーキテクチャー全般解析 (英語)
トップダウン・マイクロアーキテクチャー解析法

非効率な同期
このレシピは、スタック収集を有効にしてインテル® VTune™ Amplifier の高度な hotspot 解析を実行し、コードの非効率な同期を特定する方法を説明します。
••

使用するもの手順:
1. スタック収集を有効にして高度な hotspot 解析を実行する
2. タイムラインで同期を見つける
3. 平均待機メトリックを解析する
4. 同期コンテキスト・スイッチを解析する

注
高度な hotspot 解析は、インテル® VTune™ Amplifier 2019 で汎用の hotspot 解析 (英語) に統合されました。ハードウェア・イベントベース・サンプリング収集モードで利用できます。

使用するもの
以下は、パフォーマンス解析シナリオで使用するハードウェアとソフトウェアのリストです。
••

アプリケーション: sample.exe (OpenMP* ランタイムを使用)。このアプリケーションはデモ用であり、ダウンロードすることはできません。
パフォーマンス解析ツール: インテル® VTune™ Amplifier 2017: 高度な hotspot 解析
注インテル® VTune™ プロファイラー評価版のダウンロードと製品サポートについては、
https://www.isus.jp/intel-vtune-amplifier-xe/ を参照してください。
o このクックブックのレシピはすべてスケーラブルであり、インテル® VTune™ Amplifier 2018以降に適用できます。バージョンにより設定がわずかに異なることがあります。
o ベータ版インテル® oneAPI ベース・ツールキット向けのバージョンから、インテル® VTune™
Amplifier の名称がインテル® VTune™ プロファイラーに変わりました。引き続き、インテル®
Parallel Studio XE またはインテル® System Studio のコンポーネントとして、あるいはスタ
ンドアロン版のインテル® VTune™ プロファイラーをご利用いただけます。
オペレーティング・システム: Microsoft* Windows* 8
CPU: インテル® プロセッサー (開発コード名 Skylake)o••

スタック収集を有効にして高度な hotspot 解析を実行する
インテル® VTune™ Amplifier を起動して解析するプロジェクトを設定します。
1. ツールバーの[New Project (新規プロジェクト)] ボタンをクリックして、新規プロジェクトの名

前 (例: sqlite) を指定します。

2. [Analysis Target (解析ターゲット)] ウィンドウで、ホストベースの解析として [local host (ローカルホスト)] ターゲット・システム・タイプを選択します。
3. [Launch Application (アプリケーションを起動)] ターゲットタイプを選択して、右ペインで解析する
アプリケーションを指定します。
4. 右の [Choose Analysis (解析の選択)] ボタンをクリックし、[Algorithm Analysis (アルゴリズム解析)] > [Advanced Hotspots (高度な hotspot)] を選択して、[Hotspots and stacks (hotspot とスタック)] オプションを選択します。
5. [Start (開始)] をクリックします。
インテル® VTune™ Amplifier は、アプリケーションを起動してデータを収集し、収集したデータをファ
イナライズして、シンボル情報を解決します。この情報は、ソース解析で必要になります。

タイムラインの同期を見つける[Hardware Event (ハードウェア・イベント)] ビューポイントで、解析中に収集されたデータを開きます。

[User/system functions (ユーザー/システム関数)] コールスタック・モードを選択して、[CallStack (コールスタック)] ペインにユーザー関数とシステム関数の両方を表示します。
[Call Stack (コールスタック)] ペインで、ドロップダウン・メニューから [Synchronization Context
Switch Count (同期コンテキスト・スイッチ・カウント)] タイプを選択して、[Timeline (タイムライン)] ペインで選択した同期コンテキスト・スイッチのコールスタックを確認します。

タイムラインの頻繁な同期を見つけて、コンテキスト・スイッチの上にカーソルを移動します。ツール
ヒントに詳細が表示されます。例えば、上記の高度な hotspot 解析の結果では、NtDelayExecution スレッドに同期が原因の大量のコンテキスト・スイッチが含まれています。タイ
ムラインのコンテキスト・スイッチを選択すると、[Call Stack (コールスタック)] ペインが更新され、スレッド実行が中断された呼び出しシーケンスが表示されます。

平均待機メトリックを解析する(change) リンクをクリックして [Hotspots (hotspot)] ビューポイントを開きます。

同期コンテキスト・スイッチあたりの平均待機時間 (秒単位) である、[Wait Rate (待機レート)] メトリッ
クデータを解析します。このメトリックは、非効率で頻繁な同期および消費電力問題を特定するのに役立ちます。
インテル® VTune™ プロファイラーは、低い待機レートメトリック値 (1 ミリ秒未満) をパフォーマンス
問題として判断し、ピンクでハイライトします。これらの値は、スレッド間の競合およびシステム API の非効率な使用を示すことがあるためです。
待機時間が短く CPU 時間が長い (すべてのシステムコール時間の約半分の) 同期スタックを特定し、ダブルクリックして hotspot 関数のソースコードを調べます。

同期コンテキスト・スイッチを解析する(change) リンクをクリックして [Hardware Event (ハードウェア・イベント)] ビューポイントを開きます。デ
フォルトでは、[Event Count (イベントカウント)] グリッドはクロック数イベントでソートされます。最も CPU
時間 (クロック数) がかかっていて、最も頻繁に同期を行っているホットな関数を特定します。

このサンプル OpenMP* アプリケーションでは、インテル® VTune™ Amplifier は InterpolateN 関数をOpenMP* 領域から呼び出された計算 hotspot として表示しています。OpenMP* ランタイム内部のWaitForSingleObject で競合が発生し、約 30% のパフォーマンス損失 (待機関数のクロック数/hotspot
関数のクロック数) が発生していることも分かります。
InterpolateN 関数をダブルクリックしてソースコードを表示し、非効率な同期の原因を特定します。
for(i = 0; i < block_no; i++){#pragma omp parallel for
for(j = 0; j < lines_in_block; j++){/// do processing} /// implicit barrier causing contention and overhead}
サンプル・アプリケーションのコード解析により、ブロック行でピクチャーを処理して各ブロックを個別に並列化するために過度の OpenMP* バリアが追加されていることが判明しました。この問題を解決するには、
nowait 節を使用するか、ピクチャー全体に parallel_for を適用して、動的ワーク・スケジューリングを使用します。

最適化した結果では、Sleep() の競合の相対的なコストが低くなりました (26,997)。
1 つの parallel_for と動的ワーク・スケジューリングを WaitForSingleObject 関数に使用すること
で、競合とパフォーマンスへの悪影響を 1% 未満に減らすことができました。
2 つ目の最適化した結果では、Sleep() 関数でも多くの競合が発生していることが分かります (同期コンテキスト・スイッチ・メトリックが 26,997)。しかし、その実行時間を確認すると、実行時間は最上位の hotspot (表示されていません) の 2% 以内であり、それほど重要ではありません。ただし、多くのプロセッサー上でアプリケー
ションを実行した場合、この関数が問題になる可能性があります。
注
最初の (最適化前の) サンプルデータ収集セッションは一定の時間間隔で行われたものです。最適化バージョンでは、アプリケーションが制限なしで実行されています。

関連項目•

スタックを含むハードウェア・イベントベースのサンプリング収集 (英語)

非効率な TCP/IP 同期
このレシピは、タスク収集を有効にしてインテル® VTune™ Amplifier のロックと待機解析を実行し、コードの非効率な TCP/IP 同期を特定する方法を説明します。
コンテンツ・エキスパート: Kirill Uhanov (英語)••使用するもの
手順:
1. ロックと待機解析を実行する
2. タイムラインで同期の遅延を見つける
3. ITT API カウンターを使用して send/receive バッファーサイズを検出する
4. 非効率な TCP/IP 同期の原因を特定する

注
ロックと待機解析は、インテル® VTune™ Amplifier 2019 でスレッド解析に改名されました。

使用するもの••••アプリケーション: TCP ソケット通信を使用するクライアント/サーバー・アプリケーション
パフォーマンス解析ツール: インテル® VTune™ Amplifier 2018: ロックと待機解析
サーバー・オペレーティング・システム: Microsoft* Windows Server* 2016
クライアント・オペレーティング・システム: Linux*

ロックと待機解析を実行する
クライアント・アプリケーションのウォームアップに時間がかかる場合、ロックと待機解析を実行して、同期オ
ブジェクトごとの待機統計を調査することを検討してください。
1. ツールバーの [New Project (新規プロジェクト)] ボタンをクリックして、新規プロジェクト (例:tcpip_delays) を作成します。
2. [Analysis Target (解析ターゲット)] ウィンドウで、ホストベースの解析として [local host (ローカルホスト)] ターゲット・システム・タイプを選択します。
3. [Launch Application (アプリケーションを起動)] ターゲットタイプを選択して、右ペインで解析する
アプリケーションを指定します。
4. 右の [Choose Analysis (解析の選択)] ボタンをクリックし、[Algorithm Analysis (アルゴリズム解析)] > [Locks and Waits (ロックと待機)] を選択します。
5. [Start (開始)] をクリックします。
インテル® VTune™ Amplifier は、アプリケーションを起動してデータを収集し、収集したデータをファイナライズして、シンボル情報を解決します。この情報は、ソース解析で必要になります。

タイムラインで同期の遅延を見つける
収集結果を開いて [Bottom-up (ボトムアップ)] タブをクリックし、同期オブジェクトごとのパフォーマンスの詳細を表示します。[Timeline (タイムライン)] ペインでは、テスト・アプリケーションが実行を開始すると、複数の同期の遅延が表示されます。これらの起動時の遅延を引き起こす同期オブジェクトを特定するには、ドラッグアンドドロップで最初の 9 秒間を選択し、コンテキスト・メニューから [Filter In by Selection (選択してフィルターイン)] を使用します。

フィルターバーの [Process (プロセス)] メニューで、ホストの通信プロセス別にフィルターインします。

そして、選択した期間内で待機時間が最も大きい Socket 同期オブジェクトを選択し、[Filter In by
Selection (選択してフィルターイン)] メニューを使用してデータをフィルターインします。

Socket 同期オブジェクトの待機時間を調査するには、タイムラインに注目します。

[Zoom In (ズームイン)] ボタンをクリックすると、高速と低速の 2 種類のソケット待機が表示されます。
低速の (長い) ソケット待機は約 200 ミリ秒で、高速の (短い) ソケット待機は約 937 マイクロ秒です。

高速な待機と低速な待機の原因を理解するには、ITT カウンターですべての send/receive 呼び出しをラッ
プして、send/receive バイトを計算します。

ITT API カウンターを使用して send/receive バッファーサイズを検出する
インストルメンテーションとトレース・テクノロジー (ITT) API を使用して send/receive 呼び出しをトレースするには、次の操作を行います。
1. API ヘッダーとライブラリーにアクセスできるようにシステムを設定 (英語) します。
2. ITT API ヘッダーをソースファイルにインクルードして、<vtune-install-dir>\[lib64 or
lib32]\libittnotify.lib スタティック・ライブラリーをアプリケーションにリンクします。
3. ITT カウンターを使用して send/receive 呼び出しをラップします。
#include <ittnotify.h>__itt_domain* g_domain=__itt_domain_createA("com.intel.vtune.tests.userapi_counters");__itt_counter g_sendCounter =__itt_counter_create_typedA("send_header", g_domain->nameA,__itt_metadata_s32);__itt_counter g_sendCounterArgs =__itt_counter_create_typedA("send_args", g_domain->nameA,__itt_metadata_s32);__itt_counter g_recieveCounter =__itt_counter_create_typedA("recieve_header", g_domain->nameA,__itt_metadata_s32);__itt_counter g_recieveCounterCtrl =__itt_counter_create_typedA("recieve_ctrl", g_domain->nameA,__itt_metadata_s32);__itt_counter g_incDecCounter =__itt_counter_createA("inc_dec_counter", g_domain->nameA);.....

sent_bytes = send(...);__itt_counter_set_value(g_sendCounter, &sent_bytes);.....
sent_bytes = send(...);__itt_counter_set_value(g_sendCounterArgs, &sent_bytes);.....
while(data_transferred < header_size)) {if ((data_size = recv(...) < 0) {.....
}__itt_counter_set_value(g_recieveCounter, &data_transferred);.....
while(data_transferred < data_size) {if ((data_size = recv(...) < 0) {
....
}
}
}
__itt_counter_set_value(g_recieveCounterCtrl, &data_transferred);
アプリケーションを再コンパイルして、[Analyze user tasks, events, and counters (ユーザータスク、イベ
ント、およびカウンターを解析)] オプションを有効にしてロックと待機解析を再度実行します。

非効率な TCP/IP 同期の原因を特定する
新しい結果では、[Timeline (タイムライン)] ペインに ITT API を介して収集された send/receive 呼び出しの分布を表示する [Global Counters (グローバルカウンター)] が追加されます。マウスでスレッドの待機やカウンター値をポイントすると、対応するカウンターのインスタント値が表示されます。この値は、長い (低速な) 待機では小さくなります。

そして、短い (高速な) 待機では大きくなります。

リモートターゲットの通信待機のプロファイルでは、対称的な結果となります。小さなサイズのバッファーでは待機時間が長くなり、十分なサイズのバッファーでは待機時間が短くなります。
このレシピでは、通信コマンドチャネルが分ります。ほとんどのコマンドはサイズが小さく、結果的に長い待機時間が発生します。
問題の原因は、小さなバッファーの待機時間を増やす tcp ack 遅延メカニズムにあります。
サーバー側の入力 (setsockopt (…, SO_RCVBUF, ..,)) バッファーを小さくすると、起動時間が 5 倍以上 (数
十秒から数秒へ) 高速になります。

関連項目
•

インストルメンテーションとトレース・テクノロジー API (英語)I/O 問題: リモート・ソケット・アクセス
このレシピは、インテル® VTune™ Amplifier の全般解析を使用して、マルチソケット・システムにおける潜在的な構成ミス問題について DPDK ベースのアプリケーションを解析します。このレシピは、I/O 依存のワーク
ロードにも使用できます。
コンテンツ・エキスパート: Ilia Kurakin (英語)、Roman Khatko (英語)注
全般解析は、インテル® VTune™ Amplifier 2019 でマイクロアーキテクチャー全般解析に改名されました。
このレシピで使用する最適化手法は、インテル® Xeon® プロセッサー E5 ファミリーおよびインテル® Xeon®
プロセッサー E7 v2 ファミリーの機能である、インテル® データ・ダイレクト I/O テクノロジー (インテル®
DDIO) (英語) を利用しています。インテル® DDIO では、I/O デバイスはプロセッサー・キャッシュと直接通信を行い、メインメモリーにアクセスしません。この機能はデフォルトで有効で、ソフトウェアからアクセスすることはできません。
現在、インテル® DDIO は、ローカルソケット構成でのみパフォーマンスが大幅に向上 (英語) します。そのため、インテル® DDIO を活用するには、I/O ワークロードを適切に構成する必要があります。
2 つの構成には違いがあります。
••

ローカルソケット: I/O デバイスは I/O が消費/生産されるソケットに直接アタッチされます。
リモートソケット: I/O デバイスおよびコアの消費/生産データは異なるソケットに属します。I/O デー
タはインテル® QuickPath インターコネクト (インテル® QPI) を経由して消費コアに到達します。

下記の図は、ローカルおよびリモート・ソケット・トポロジーの I/O フローを示しています。
ローカルソケット

リモートソケットDPDK は、ポーリングプロセスを特定のコアに厳密にピニングします。そのため、インテル® DDIO 機能を利用してレイテンシーを軽減して帯域幅を最大化するには、同じソケットに属するコアおよびポートのみにピニングすることが重要です。ただし、インテル® DDIO を利用して大量のソケット、コア、イーサネット・デバイスを含む複雑なシステムを適切に構成することは容易ではありません。
このレシピは、インテル® VTune™ Amplifier を使用してリモート・ソケット・アクセスを検出する方法を示します。
1. 使用するもの
2. 手順:
a. 全般解析を実行する
b. リモートキャッシュの使用率を解析する
c. リモートキャッシュにアクセスしているコアを特定する
d. DPDK アプリケーションを再構成する

使用するもの
以下は、パフォーマンス解析シナリオで使用するハードウェアとソフトウェアのリストです。
•

アプリケーション: ポート 0 で受け取ったパケットをポート 1 に L2 フォワーディングする、インテル®
Data Plane Performance Demonstrators (インテル® DPPD) PROX （英語) アプリケーション。
PROX は、次の 2 つの方法で設定されます。
ローカルソケット: DPDK はソケット 0 の
コアにピニングされる

リモートソケット: DPDK はソケット 1 のコアにピニングされる

•

ツール:
o

インテル® VTune™ Amplifier 2018: 全般解析

注
インテル® VTune™ プロファイラー評価版のダウンロードと製品サポートについては、
https://www.isus.jp/intel-vtune-amplifier-xe/ を参照してください。
o このクックブックのレシピはすべてスケーラブルであり、インテル® VTune™ Amplifier 2018以降に適用できます。バージョンにより設定がわずかに異なることがあります。
o ベータ版インテル® oneAPI ベース・ツールキット向けのバージョンから、インテル® VTune™
Amplifier の名称がインテル® VTune™ プロファイラーに変わりました。引き続き、インテル®
Parallel Studio XE またはインテル® System Studio のコンポーネントとして、あるいはスタ
ンドアロン版のインテル® VTune™ プロファイラーをご利用いただけます。
オペレーティング・システム: Red Hat* Enterprise Linux* Server 7.4
CPU: インテル® Xeon® プロセッサー E5-2695 v4 (2 基)、インテル® DDIO 有効、NIC (SUT) および
トラフィック・ジェネレーター (GEN) からのデータパケットを扱うデュアルソケット・システム
o

•
•

注
このシステム構成は、この特定のレシピの例として使用したものです。インテル® VTune™ Amplifier のソフト
ウェア要件およびハードウェア要件は、製品のリリースノート (英語) を参照してください。

全般解析を実行する
マイクロアーキテクチャーのパフォーマンス問題を分類するため、全般解析から始めます。
1. 実行中の PROX の PID を調べます。
ps aux | grep prox
2. インテル® VTune™ Amplifier コマンドライン・インターフェイス (amplxe-cl) を使用して全般解析を実行し、実行中の PROX プロセスにアタッチします。
amplxe-cl -collect general-exploration -knob collect-memorybandwidth=true -r <result_dir> --duration 25 --target-pid <PID>

リモートキャッシュの使用率を解析する
デフォルトでは、収集した結果は [General Exploration (全般)] ビューポイントに表示されます。[Summary(サマリー)] ウィンドウで、潜在的な構成ミスを判断する基本的な指標である [Remote Cache (リモートキャッシュ)] メトリックに注目します。このメトリックは、リモートキャッシュからデータを取得する間に使用されたクロック数の割合を示します。
パーフェクトなケース (ローカルソケット) では、リモート・キャッシュ・メトリックは 0 になります。

リモート・キャッシュ・メトリックが 0 でない場合、通常は、コアがリモート LLC にアクセスしていることを意味します。リモートソケット構成では、リモート・キャッシュ・メトリックは 100% で、インテル® VTune™
Amplifier はパフォーマンス問題としてフラグを付けます。

詳細に解析するため、[Memory Usage (メモリー使用)] ビューポイントに切り替えて、リモートキャッシュで処理された LLC ミスの数を示す [Remote Cache Access Count (リモート・キャッシュ・アクセス・カウント)]
メトリックを調べます。このメトリックの値が高い場合、コアと I/O デバイスが異なるソケットで動作していたことを意味します。

リモートソケット構成のメトリック値を調べます。

次に、ローカルソケット構成のメトリック値を調べます。

リモートキャッシュにアクセスしているコアを特定する
リモートキャッシュにアクセスしているコアを調べるため、[Memory Usage (メモリー使用)] ビューポイントの [Bottom-up (ボトムアップ)] ウィンドウに切り替えて、[Core (コア)] グループレベルを選択します。

[Remote Cache (リモートキャッシュ)] 列はデフォルトで折りたたまれていることに注意してください。列の名前の右側にある ">>" コントロールをクリックして列を展開します。列のメトリック階層は [Summary (サマリー)] ウィンドウのメトリック階層と同じで、このケースでは [Memory Bound (メモリー依存)] グループから始まります。
この例では、core_19 がリモート LLC にアクセスしていました。

DPDK アプリケーションを再構成する
インテル® プラットフォームで実行する DPDK アプリケーションにリモートキャッシュ問題が見つかった場合
は、『DPDK Getting Started guide (DPDK 入門ガイド)』の「How to get best performance with NICs onIntel platforms (インテル® プラットフォームで NIC の最良のパフォーマンスを得る方法)」 (英語) の構成手順に従ってください。
注
このレシピの情報は、デベロッパー・フォーラム (英語) を参照してください。

関連項目
•
•
•

ハードウェア問題のマイクロアーキテクチャー全般解析 (英語)
トップダウン・マイクロアーキテクチャー解析法
DPDK プロファイルに関する資料 (英語)I/O 問題: 高いレイテンシーと低い PCIe* 帯域幅
このレシピは、I/O 依存のサンプル・アプリケーションに対してインテル® VTune™ Amplifier のディスク I/O
解析を実行します。そして、PCIe* デバイス向けにアフィニティーを変更して、読み取りアクセスの帯域幅が向上するように最適化します。
コンテンツ・エキスパート: Roman Sudarikov (英語)
1. 使用するもの
2. 手順:
a. ディスク I/O 解析を実行する
b. 帯域幅とレイテンシーのメトリックを解析する
c. アプリケーションのアフィニティーを変更して解析を再度実行する
d. 重要なポイント
注ディスク I/O 解析は、インテル® VTune™ Amplifier 2019 で入力と出力解析に改名されました。

使用するもの
以下は、パフォーマンス解析シナリオで使用するハードウェアとソフトウェアのリストです。
••

アプリケーション: 3 秒間に連続する 128K 読み取りアクセスを実行する hdparm。
https://sourceforge.net/projects/hdparm (英語) から入手できます。
パフォーマンス解析ツール:o インテル® VTune™ Amplifier 2018: ディスク I/O 解析
注インテル® VTune™ プロファイラー評価版のダウンロードと製品サポートについては、
https://www.isus.jp/intel-vtune-amplifier-xe/ を参照してください。
o このクックブックのレシピはすべてスケーラブルであり、インテル® VTune™ Amplifier 2018以降に適用できます。バージョンにより設定がわずかに異なることがあります。
o ベータ版インテル® oneAPI ベース・ツールキット向けのバージョンから、インテル® VTune™
Amplifier の名称がインテル® VTune™ プロファイラーに変わりました。引き続き、インテル®
Parallel Studio XE またはインテル® System Studio のコンポーネントとして、あるいはスタ
ンドアロン版のインテル® VTune™ プロファイラーをご利用いただけます。
オペレーティング・システム: Red Hat* Enterprise Linux* Server 7.2
CPU: インテル® プロセッサー (開発コード名 Skylake)
I/O デバイス: インテル® SSD DC P3500/P3600/P3700 シリーズ
o

•
•
•

ディスク I/O 解析を実行する
I/O 依存のアプリケーションでは、ディスク I/O 解析から始めることを推奨します。
1. ツールバーの[New Project (新規プロジェクト)] ボタンをクリックして、新規プロジェクトの名

前 (例: hdparm) を指定します。
2. [Analysis Target (解析ターゲット)] ウィンドウで、ホストベースの解析として [local host (ローカルホスト)] ターゲット・システム・タイプを選択します。
3. [Launch Application (アプリケーションを起動)] ターゲットタイプを選択して、右ペインで解析する
アプリケーションを指定します。

4. 右の [Choose Analysis (解析の選択)] ボタンをクリックし、[Platform Analysis (プラットフォーム解析)] > [Disk Input and Output (ディスク I/O)] を選択して、[Start (開始)] をクリックします。
インテル® VTune™ Amplifier は、アプリケーションを起動してデータを収集し、収集したデータをファ
イナライズして、シンボル情報を解決します。この情報は、ソース解析で必要になります。

帯域幅とレイテンシーのメトリックを解析する
アプリケーション実行の統計が表示される [Summary (サマリー)] ビューから解析を始めます。I/O 効率の主要な指標である [I/O Wait Time (I/O 待機時間)] メトリックに注目します。

I/O 待機時間メトリックは、hdparm アプリケーションが経過時間の約 30% を I/O 待機に費やしていることを示しています。

ヒストグラムで read ディスク I/O 操作タイプを選択して、読み取りアクセスの時間分布を解析します。

不規則なフローは、通常、パフォーマンスの低下を示します。これは、デバイス仕様で宣言されている値 (20 マ
イクロ秒) よりも 3 桁大きい読み取りアクセスの値からも確認できます。

[Bottom-up (ボトムアップ)] ウィンドウに切り替えて [Storage Device/Partition (ストレージデバイス/
パーティション)] グループレベルを適用します。タイムライン・データに注目します。

タイムライン・ビューの [I/O Operations (I/O 操作)] と [Data Transfers (データ転送)] セクションは、高いI/O 待機と不規則なデータフローを示しています。
[PCIe Bandwidth (PCIe* 帯域幅)] セクションは、デバイス (package_0) の読み取り帯域幅が、デバイス仕様で宣言されている値の約 65% しかないことを示しています。
タイムラインのグループレベルを [Package / Core / H/W Context (パッケージ/コア/ハードウェア・コンテキスト)] に変更して、アプリケーションのアフィニティーを調査します。

デバイスは package_0 ですが、アプリケーションは package_1 で実行していることが分かります。これが、高いレイテンシーと低い帯域幅の原因の可能性があります。

アプリケーションのアフィニティーを変更して解析を再度実行する
ワークロードとデバイスの設定を維持したまま検出された I/O 問題を解決するため、アプリケーションのア
フィニティーを変更して、ディスク I/O 解析を再度実行します。
新しい結果は、アプリケーションの I/O 待機時間が経過時間の約 2% になったことを示しています。

ヒストグラムに読み取りアクセスの時間分布が表示されなくなりました。すべての I/O 操作がミリ秒未満で実行されています。

タイムライン・ビューでは、I/O 操作と I/O データ転送の規則的なデータフローが確認できます。これは、アフィ
ニティーの最適化によりレイテンシーが軽減されたことを示しています。

さらに、この変更により、PCIe* 帯域幅が向上し、デバイス仕様で宣言されている値の約 93% になりました。

まとめ
PCIe* 帯域幅に依存するアプリケーションの I/O パフォーマンス解析に関して、次の点を説明しました。
•
•
•
•
•

PCIe* デバイスの I/O ユニット (IOU) アフィニティーを決定する
アプリケーションを I/O ユニットに適切に分配する
デバイスの性能を理解する
合理的なパフォーマンス目標を設定する
ディスク I/O 解析 (英語) を実行して低い帯域幅の I/O ソリューションをデバッグする

OS スレッド・マイグレーション
このレシピは、インテル® VTune™ Amplifier の高度な hotspot 解析を使用して NUMA アーキテクチャーのOS スレッド・マイグレーションを特定する手順を説明します。
注
高度な hotspot 解析は、インテル® VTune™ Amplifier 2019 で汎用の hotspot 解析 (英語) に統合されました。ハードウェア・イベントベース・サンプリング収集モードで利用できます。
現代の複雑なオペレーティング・システムは、スケジューラーを使用してアプリケーション・スレッド (ソフト
ウェア・スレッド) をプロセッサー・コアに割り当てます。スケジューラーは、システムステート、システムポリ
シーなどのさまざまな異なる要因に応じて、物理コア上のアプリケーション・スレッドの配置を選択します。ソフ
トウェア・スレッドは、スワップアウトされて待機状態になるまで、コアで一定時間実行されます。ソフトウェア・
スレッドは、I/O によるブロックのようなさまざまな理由により待機します。利用可能な場合、別のソフトウェ
ア・スレッドがこのコアで実行されます。オリジナルのソフトウェア・スレッドが再度実行可能になると、スケ
ジューラーは、オリジナルのソフトウェア・スレッドが実行できるように別のソフトウェア・スレッドを別のコアに移動します。ソフトウェア・スレッドを移動すると、スレッドとすでにキャッシュにフェッチされたデータの関連付けが解消され、データアクセスのレイテンシーが大きくなるため、新しい計算アーキテクチャーでは問題が発生します。この問題は、各プロセッサーが個別のローカルメモリーを保持し、それらに直接アクセスする
NUMA (Non Uniform Memory Access) アーキテクチャーではさらに大きくなります。NUMA アーキテク
チャーでは、ソフトウェア・スレッドを別のコアに移動すると、以前のコアのローカルメモリーに格納されていたデータがリモートになり、メモリーアクセス時間が大幅に増加します。スレッド・マイグレーションはパフォーマ
ンス低下の原因となるため、アプリケーションでスレッド・マイグレーションが発生しているかどうか確認することが重要です。
1. 使用するもの
2. 手順:
a. 高度な hotspot 解析を実行する
b. スレッド・マイグレーションを特定する
c. スレッド・マイグレーションを訂正する使用するもの
以下は、パフォーマンス解析シナリオで使用するハードウェアとソフトウェアのリストです。
••

アプリケーション: OpenMP* テスト・アプリケーション。このアプリケーションはデモ用であり、ダウンロードすることはできません。
パフォーマンス解析ツール: インテル® VTune™ Amplifier 2018: 高度な hotspot 解析
注ooインテル® VTune™ プロファイラー評価版のダウンロードと製品サポートについては、
https://www.isus.jp/intel-vtune-amplifier-xe/ を参照してください。
このクックブックのレシピはすべてスケーラブルであり、インテル® VTune™ Amplifier 2018以降に適用できます。バージョンにより設定がわずかに異なることがあります。

ベータ版インテル® oneAPI ベース・ツールキット向けのバージョンから、インテル® VTune™
Amplifier の名称がインテル® VTune™ プロファイラーに変わりました。引き続き、インテル®
Parallel Studio XE またはインテル® System Studio のコンポーネントとして、あるいはスタ
ンドアロン版のインテル® VTune™ プロファイラーをご利用いただけます。
オペレーティング・システム: Ubuntu* 16.04 64 ビット
CPU: インテル® Core™ i7-6700K プロセッサーo••

高度な hotspot 解析を実行する
インテル® VTune™ Amplifier (GUI または amplxe-cl) を使用して、インテル® アーキテクチャー上で実行中のアプリケーションのソフトウェア・スレッド・マイグレーションを特定します。OS スレッド・マイグレーションを特定するには、アプリケーションで基本 hotspot 解析または高度な hotspot 解析を実行します。高度なhotspot 解析の例を次に示します。

スレッド・マイグレーションを特定する

GUI を使用してスレッド・マイグレーションを特定するには、[Core/Thread/Function/Call Stack(コア/スレッド/関数/コールスタック)] グループを選択します。
コアノードを展開してソフトウェア・スレッドの数を確認します。一般に、ソフトウェア・スレッドの数は、CPU でサポートしているハードウェア・スレッドの数以下にする必要があります。また、スレッドをコア間で均等に分散する必要もあります。いずれかのコアに予想よりも多くのソフトウェア・スレッドが表示されている場合、アプリケーションでスレッド・マイグレーションが発生しています。上記の例では、(インテル® Xeon® プロセッサーはインテル® ハイパースレッディング・テクノロジーをサポートしているため) 予想される 2 スレッドではなく 12 の OpenMP* ワーカースレッドが core_8 で実行されています。これはスレッド・マイグレーションを示しています。
[Thread/H/W Context (スレッド/ハードウェア・コンテキスト)] グループを選択して、[Timeline (タイムライン)] ペインでスレッド・マイグレーションを解析します。

スレッドのノードを展開して、このスレッドが実行された CPU の番号を確認し、経時的なスレッド実行を解析します。上記の例では、OpenMP* スレッド #0 は cpu_23 で実行された後、cpu_47 に移動しています。
次のように、コマンドラインから直接これらの結果を見ることもできます。
amplxe-cl -group-by thread,cpuid -report hotspots -r /temp/test/omp -s "H/W
Context" -q | lessThreadH/W Context CPU Time:Self------------------------------ ----------- ------------OMP Worker Thread #5 (0x3d86)
cpu_0
0.004
matmul-intel64 (0x3d52)
cpu_1
0.013
OMP Worker Thread #15 (0x3d90)
cpu_102.418
matmul-intel64 (0x3d52)
cpu_102.023
OMP Worker Thread #8 (0x3d89)
cpu_100.687
OMP Worker Thread #13 (0x3d8e)
cpu_100.097
OMP Worker Thread #6 (0x3d87)
cpu_100.065
OMP Worker Thread #4 (0x3d85)
cpu_100.059
OMP Worker Thread #1 (0x3d82)
cpu_100.048
OMP Worker Thread #9 (0x3d8a)
cpu_100.034
OMP Worker Thread #11 (0x3d8c)
cpu_100.009
多くの OpenMP* ワーカースレッドが cpu_10 で実行されていることも分かります。

スレッド・マイグレーションを訂正するスレッド・マイグレーションはスレッド・アフィニティーを設定することで訂正できます。スレッド・アフィニティー
は、特定のスレッドの実行をマルチプロセッサー・コンピューターの物理処理ユニットの一部に限定します。
インテルのランタイム・ライブラリーには、OpenMP* スレッドを物理処理ユニットにバインドする機能があります。OMP_PROC_BIND および OMP_PLACES、またはインテルのランタイム固有の KMP_AFFINITY 環境変数を使用して OpenMP* アプリケーションのスレッド・アフィニティーを設定することもできます。

関連項目•

OpenMP* コード解析

OpenMP* インバランスとスケジュール・オーバーヘッド
このレシピは、バリアやスケジュール・オーバーヘッドのインバランスなど、OpenMP* プログラムでよくある並列ボトルネックを検出して修正する方法を説明します。
コンテンツ・エキスパート: Dmitry Prohorov (英語)
バリアは、スレッドチームのすべてのスレッドがバリアに到達した後に実行できる同期ポイントです。実行作業が不規則で、作業チャンクがワーカースレッドによって均等かつ静的に分散されている場合、バリアに到達した
スレッドは、有効な作業を行う代わりにほかのスレッドを待機して時間を無駄にします。チーム内のスレッド数で正規化されたバリアでの合計待機時間は、インバランスを排除することでアプリケーションが軽減できる経過時間を示しています。
バリアのインバランスを排除する 1 つの方法は、動的スケジューリングを使用してスレッド間で動的に作業
チャンクを分散することです。ただし、細粒度のチャンクでこれを行うと、スケジュール・オーバーヘッドにより状況がさらに悪化することがあります。このレシピを参考にして、インテル® VTune™ Amplifier を使用してOpenMP* ロード・インバランスとスケジュール・オーバーヘッドの問題に対応するワークフローを学びます。
••

使用するもの
手順:
1. ベースラインを作成する
2. HPC パフォーマンス特性解析を実行する
3. OpenMP* のインバランスを特定する
4. 動的スケジューリングを適用する
5. OpenMP* スケジュール・オーバーヘッドを特定する
6. チャンク・パラメーターを使用して動的スケジューリングを適用する

使用するもの
以下は、パフォーマンス解析シナリオで使用するハードウェアとソフトウェアのリストです。
•••

アプリケーション: 特定の範囲の素数を計算するアプリケーション。メインループは、OpenMP*parallel for 構文で並列化されています。
コンパイラー: インテル® コンパイラー 13 Update 5 以降。このレシピは、インテル® VTune™
Amplifier の解析で使用されるインテルの OpenMP* ランタイム・ライブラリー内のインストルメン
テーションを実行するため、このコンパイラー・バージョンを必要とします。インテル® コンパイラーの
parallel-source-info=2 オプションを追加してコンパイルすることで、OpenMP* 領域名でソー
スファイル情報が提供され、ユーザーが識別しやすくなります。
パフォーマンス解析ツール:o インテル® VTune™ Amplifier 2018: HPC パフォーマンス特性解析
注▪

インテル® VTune™ プロファイラー評価版のダウンロードと製品サポートについては、https://www.isus.jp/intel-vtune-amplifier-xe/ を参照してください。

このクックブックのレシピはすべてスケーラブルであり、インテル® VTune™
Amplifier 2018 以降に適用できます。バージョンにより設定がわずかに異なることがあります。
▪ ベータ版インテル® oneAPI ベース・ツールキット向けのバージョンから、インテル®
VTune™ Amplifier の名称がインテル® VTune™ プロファイラーに変わりました。引
き続き、インテル® Parallel Studio XE またはインテル® System Studio のコンポー
ネントとして、あるいはスタンドアロン版のインテル® VTune™ プロファイラーをご利用いただけます。
オペレーティング・システム: Ubuntu* 16.04 LTS
CPU: インテル® Xeon® プロセッサー E5-2699 v4 @ 2.20GHz▪

••

ベースラインを作成する
サンプルコードの初期バージョンは、デフォルトの静的スケジューリングでループに OpenMP* parallel for
プラグマを使用します (行 21)。
#include <stdio.h>#include <omp.h>#define NUM 100000000
int isprime( int x ){for( int y = 2; y * y <= x; y++ ){if( x % y == 0 )return 0;}
return 1;}
int main( ){int sum = 0;
#pragma omp parallel for reduction (+:sum)for( int i = 2; i <= NUM ; i++ ){sum += isprime ( i );}printf( "Number of primes numbers: %d", sum );return 0;}
コンパイルしたアプリケーションの実行には約 3.9 秒かかります。これが、以降の最適化で使用するパフォー
マンスのベースラインとなります。

HPC パフォーマンス特性解析を実行する
サンプル・アプリケーションの潜在的なパフォーマンス・ボトルネックを理解するため、まず、インテル®
VTune™ プロファイラーの HPC パフォーマンス特性解析を実行します。
1. ツールバーの[New Project (新規プロジェクト)] ボタンをクリックして、新規プロジェクトの名

前 (例: primes) を指定します。
2. [Create Project (プロジェクトの作成)] をクリックします。
[Configure Analysis (解析の設定)] ウィンドウが表示されます。
3. [WHERE (どこを)] ペインで、[Local Host (ローカルホスト)] ターゲット・システム・タイプを選択します。
4. [WHAT (何を)] ペインで、[Launch Application (アプリケーションを起動)] ターゲットタイプを選択して、解析するアプリケーションを指定します。次に例を示します。

5. [HOW (どのように)] ペインで、[...] ボタンをクリックして [Parallelism (並列処理)] グループから[HPC Performance Characterization (HPC パフォーマンス特性)] 解析を選択します。
6.

[Start (開始)] ボタンをクリックします。

インテル® VTune™ Amplifier は、アプリケーションを起動してデータを収集し、収集したデータをファイナライズして、シンボル情報を解決します。この情報は、ソース解析で必要になります。

OpenMP* のインバランスを特定する
HPC パフォーマンス特性解析は、CPU 使用率 (並列性)、メモリーアクセス効率、ベクトル化などのパフォーマ
ンス・ボトルネックの理解に役立つ重要な HPC メトリックを収集して表示します。このレシピのようにインテルの OpenMP* ランタイムを使用するアプリケーションでは、スレッド並列処理の問題の特定を支援する特別なOpenMP* 効率メトリックが役立ちます。
アプリケーション・レベルの統計が表示される [Summary (サマリー)] ビューから解析を始めます。フラグが付いた [Effective Physical Core Utilization (効率的な物理コア利用率)] メトリック (一部のシステムでは[CPU Utilization (CPU 使用率)]) は、調査すべきパフォーマンスの問題を示しています。

[Parallel Region Time (並列領域時間)] > [OpenMP Potential Gain (OpenMP* 潜在的なゲイン)] メト
リックに移動して、非効率な並列処理を改善することで得られる最大ゲインを予測します。このサンプルでは、
1.084 秒 (アプリケーションの実行時間の 27.5%) にフラグが付いているため、parallel 構文を詳しく調べる価値があります。
このサンプル・アプリケーションでは、[Top OpenMP Regions by Potential Gain (潜在的なゲインによる上位 OpenMP* 領域)] セクションに 1 つの parallel 構文があります。テーブルで領域名をクリックして、[Bottom-up (ボトムアップ)] ビューで詳細を確認します。[Bottom-up (ボトムアップ)] グリッドの [OpenMP
Potential Gain (OpenMP* 潜在的なゲイン)] カラムを展開して非効率の詳細を表示します。このデータは、
アプリケーションではなく OpenMP* で CPU 時間が費やされている原因と、それによる経過時間への影響を理解するのに役立ちます。

グリッド行のホットな領域で [Imbalance (インバランス)] メトリックの値がハイライトされています。マウス
でこの値をポイントすると、動的スケジューリングによりインバランスを排除することを推奨するヒントが表示されます。領域内に複数のバリアがある場合は、領域ノードをバリアごとのセグメントに展開して、パフォーマ
ンス・クリティカルなバリアを特定する必要があります。

このサンプルには、インテル® VTune™ Amplifier によって分類されない重大なインバランスを持つループバ
リアと並列領域のジョインバリアがあります。
注
アプリケーションの実行中にインバランスを視覚化するには、[Timeline (タイムライン)] ビューを調査します。
有効な作業を実行している時間は緑色で示され、浪費時間は黒色で示されます。

動的スケジューリングを適用する
このインバランスは、静的な作業分散により、特定のスレッドに大きな数字を割り当てる一方で、一部のスレッ
ドは小さな数字のチャンクを短時間で処理しバリアで時間を無駄にしていることが原因です。このインバラン
スを解消するには、デフォルトのパラメーターで動的スケジューリングを適用します。

int sum = 0;
#pragma omp parallel for schedule(dynamic) reduction (+:sum)for( int i = 2; i <= NUM ; i++ ){sum += isprime ( i );}アプリケーションを再コンパイルして、その実行時間とオリジナルのパフォーマンス・ベースラインを比較して、最適化を検証します。

OpenMP* スケジュール・オーバーヘッドを特定する変更したサンプル・アプリケーションを実行すると、スピードアップせずに実行時間が 5.3 秒に増えます。これは、細粒度の作業チャンクで動的スケジューリングを適用した場合に起こる副作用です。潜在的なボトルネッ
クの詳細を把握するには、HPC パフォーマンス特定解析を再度実行して、パフォーマンス低下の原因を確認す
ることを検討してください。
1. メニューから [New (新規)] > [HPC Performance Characterization Analysis (HPC パフォーマン
ス特性解析)] を選択して、既存の primes プロジェクトの解析設定を開きます。
2. [Start (開始)] をクリックします。
[Summary (サマリー)] ビューでは、パフォーマンス・クリティカルとして [Effective Physical Core
Utilization (効率的な物理コア利用率)] メトリックにフラグが付けられており、[OpenMP Potential Gain
(OpenMP* 潜在的なゲイン)] の値がオリジナルの値の 1.084 秒よりも増えています。

このデータは、コードの並列効率が低下したことを裏付けています。原因を理解するため、[Bottom-up (ボトムアップ)] ビューに切り替えます。

以前の解析結果と比較すると、[Scheduling (スケジューリング)] オーバーヘッドはインバランスよりもさらに深刻な状況にあります。これは、ワーカースレッドごとに 1 ループ反復を割り当てるスケジューラーのデフォル
トの動作が原因です。スレッドがすぐにスケジューラーに戻るため、コンカレンシーが高すぎてボトルネックとなります。タイムラインの [Effective Time (有効な時間)] メトリックの分布 (緑色) は、スレッドによる通常の作業を示していますが、密度が低くなっています。グリッドでハイライトされている [Scheduling (スケジューリング)] メトリックの値にマウスホバーするとパフォーマンスに関するアドバイスが表示され、OpenMP*parallel for プラグマでチャンクを使用して並列処理を粗粒度にし、スケジュール・オーバーヘッドを排除するように推奨されます。

チャンク・パラメーターを使用して動的スケジューリングを適用する
次のように、schedule 節のチャンク・パラメーターを 20 にします。
#pragma omp parallel for schedule(dynamic,20) reduction (+:sum)for( int i = 2; i <= NUM ; i++ ){sum += isprime ( i );}

再コンパイルすると、アプリケーションの実行時間は 2.6 秒になりました (ベースラインと比較して 30% の向上)。[Summary (サマリー)] ビューは、理想に近い [Parallel Region Time (並列領域時間)] (98.3%) を示しています。

[Bottom-up (ボトムアップ)] ビューのタイムラインは、良好な密度の有効な作業 (緑色) を示しています。

動的スケジューリングは、頻繁に新しい作業チャンクをスレッドへ割り当てるため、キャッシュの再利用が妨げ
られ、コード実行のキャッシュ効率が低下する可能性があります。つまり、CPU を効率良く使用しバランス良く最適化されたアプリケーションのほうが、静的スケジューリングを使用するバランスの悪いアプリケーション
よりも低速になることがあります。この場合、[HPC Performance Characterization (HPC パフォーマンス特性)] ビューの [Memory Bound (メモリー依存)] セクションを調査します。
注
このレシピの情報は、デベロッパー・フォーラム (英語) を参照してください。

関連項目
•
•
•
•
•

OpenMP* コード解析 (英語)HPC パフォーマンス特性解析 (英語)
潜在的なゲイン (英語)
チュートリアル: MPI/OpenMP* ハイブリッド・アプリケーションの解析 (英語)
低いプロセッサー・コア利用率: OpenMP* シリアル時間

低いプロセッサー・コア利用率: OpenMP* シリアル時間
このレシピは、OpenMP* で並列化されたアプリケーションのシリアル実行部分を特定し、追加の並列化の機会を見つけ、アプリケーションのスケーラビリティーを向上します。
コンテンツ・エキスパート: Dmitry Prohorov (英語)
並列アプリケーションのシリアル時間は、アプリケーションが利用可能なハードウェア・リソース (アプリケー
ション・コードを実行するコアなど) を利用する能力である、アプリケーションのスケーラビリティーを妨げる要因の 1 つです。並列アプリケーションの最大スピードアップは、アムダールの法則で 1/((1-P)+(P/N)) と表されます。ここで、P はアプリケーション実行の並列部分であり、N はプロセッサー・エレメントです。そのため、P (アプリケーション実行のシリアル部分) が大きくなるほど、実行のシリアル部分によって制限される N (プロセッ
サー・エレメント) の数が多くなります。
ユーザー・アプリケーションが OpenMP* で並列化されている場合、シーケンシャル・コードの実行は、OpenMP* 領域外のコード実行、または #pragma omp master や #pragma omp single 構造内のコード実行の可能性があります。このレシピでは、1 つ目のケースの検出に注目します。このレシピを参考にして、インテル® VTune™ Amplifier で OpenMP* 領域外のコードの実行時間を検出して、シリアル・ホットスポット
関数/ループの分布を解析し、コードの並列化の可能性を理解します。
••

使用するもの
手順:
1. ベースラインを作成する
2. HPC パフォーマンス特性解析を実行する
3. OpenMP* シリアル時間を特定する
4. コードを並列化する
5. スレッドエラーを調査する

使用するもの
以下は、パフォーマンス解析シナリオで使用するハードウェアとソフトウェアのリストです。
•••

アプリケーション: miniFE 有限要素ミニアプリケーション (OpenMP* バージョン)。
https://github.com/Mantevo/miniFE (英語) からダウンロードできます。
コンパイラー: インテル® コンパイラー 13 Update 5 以降。このレシピは、インテル® VTune™
Amplifier の解析で使用されるインテルの OpenMP* ランタイム・ライブラリー内のインストルメン
テーションを実行するため、このコンパイラー・バージョンを必要とします。
パフォーマンス解析ツール:o インテル® VTune™ Amplifier 2019: HPC パフォーマンス特性解析
o インテル® Inspector 2019: スレッドエラー解析
注oインテル® VTune™ Amplifier 評価版のダウンロードと製品サポートについては、
https://www.isus.jp/intel-vtune-amplifier-xe/ を参照してください。

インテル® Inspector 評価版のダウンロードと製品サポートについては、
https://www.isus.jp/intel-inspector-xe/ を参照してください。
オペレーティング・システム: Ubuntu* 16.04 LTS
CPU: インテル® Xeon® プロセッサー E5-2699 v4 @ 2.20GHzo••

ベースラインを作成する
openmp/src/Makefile.intel.openmp メイクファイルを使用してアプリケーションをビルドします。
インテル® コンパイラーの -g オプションと -parallel-source-info=2 オプションを追加してコンパイルすることで、デバッグ情報が有効になり、OpenMP* 領域名でソースファイル情報が提供され、ユーザーが識別しやすくなります。
引数 nx=200、ny=200、nz=200 でコンパイルしたアプリケーションを、物理コア数に対応する OpenMP* ス
レッド数とコアごとに 1 スレッド (OMP_NUM_THREADS=44、OMP_PLACES=cores) で実行すると、約 12秒かかります。これが、以降の最適化で使用するパフォーマンスのベースラインとなります。

HPC パフォーマンス特性解析を実行する
サンプル・アプリケーションの潜在的なパフォーマンス・ボトルネックを理解するため、まず、インテル®
VTune™ Amplifier の HPC パフォーマンス特性解析を実行します。
1. ツールバーの [New Project (新規プロジェクト)] ボタンをクリックして、新規プロジェクトの名前 (例:miniFE) を指定します。
[Configure Analysis (解析の設定)] ウィンドウが表示されます。
2. [WHERE (どこを)] ペインで、[Local Host (ローカルホスト)] ターゲット・システム・タイプを選択します。
[WHAT (何を)] ペインで、[Launch Application (アプリケーションを起動)] ターゲットタイプを選択して、解析するアプリケーションと引数 nx 200 ny 200 nz 200 を指定します。
3. [HOW (どのように)] ペインで、[...] ボタンをクリックして [Parallelism (並列処理)] グループから[HPC Performance Characterization (HPC パフォーマンス特性)] 解析を選択します。
4.

[Start (開始)] ボタンをクリックして、解析を実行します。

コマンドラインから解析を実行するには、次の構文を使用します。
amplxe-cl -collect hpc-performance -data-limit=0 ./miniFE.x nx 200 ny 200 nz
200
インテル® VTune™ Amplifier は、アプリケーションを起動してデータを収集し、収集したデータをファイナライズして、シンボル情報を解決します。この情報は、ソース解析で必要になります。

OpenMP* シリアル時間を特定する
HPC パフォーマンス特性解析は、CPU 使用率 (並列性)、メモリーアクセス効率、ベクトル化などのパフォーマ
ンス・ボトルネックの理解に役立つ重要な HPC メトリックを収集して表示します。このレシピのようにインテルの OpenMP* ランタイムを使用するアプリケーションでは、スレッド並列処理の問題の特定を支援する特別なOpenMP* 効率メトリックが役立ちます。

アプリケーション・レベルの統計が表示される [Summary (サマリー)] ビューから解析を始めます。フラグが付いた [Effective Physical Core Utilization (効率的な物理コア利用率)] メトリック (一部のシステムでは[CPU Utilization (CPU 使用率)]) は、調査すべきパフォーマンスの問題を示しています。

メトリックの階層を深く掘り下げると、アプリケーションの [Serial Time (outside parallel regions) (シリアル時間 (並列領域外))] が経過時間の約 25% を占めていることが分かります。主なシリアル hotspot は、行列の初期化コードにあります。

コールスタック付きの HPC パフォーマンス特性解析を実行して、利用可能な最適化の可能性を調査することを検討してください。コールスタックは、適切な粒度で並列化の候補を見つけるのに役立ちます。コールスタッ
ク収集はメモリー帯域幅の解析と組み合わせることができないため、必ず [Analyze memory bandwidth(メモリー帯域幅を解析)] 設定オプションを無効にしてください。

コマンドラインからこの設定を実行するには、次のコマンドを入力します。
amplxe-cl -collect hpc-performance -data-limit=0 -knob enable-stackcollection=true -knob collect-memory-bandwidth=false ./miniFE.x nx 200 ny 200
nz 200注[Threading (スレッド化)] 解析を実行して、スタックを使用して OpenMP* シリアル時間を解析することもできます。ただし、どのパフォーマンス特性がボトルネックになっているのか分からない場合は、HPC パフォーマ
ンス特性解析を出発点としたほうが良いでしょう。

上位の hotspot を特定し、そのコールスタックを調査するには、[Bottom-up (ボトムアップ)] ビューに切り替
えて、[Serial CPU Time (シリアル CPU 時間)] カラムでソートします。

行列要素でループを反復している SparseMatrix_functions.hpp の 70 行目が並列化に適していることが分かります。

[Call Stack (コールスタック)] ペインの行をダブルクリックして、ソースファイルを開きます。上位の hotspot
ループの最もホットな行が自動的に表示されます。

コードを並列化する#pragma omp parallel for を追加して、行列の初期化を OpenMP* で並列化します。
#pragma omp parallel for
for(int i=0; i<mat_init.n; ++i) {mat_init(i);アプリケーションを再コンパイルして、その実行時間とオリジナルのパフォーマンス・ベースラインを比較して、最適化を検証します。
このレシピでは、最適化したアプリケーションの経過時間は約 10 秒になり、アプリケーションの実行は約16% スピードアップしました。
最適化したアプリケーションで HPC パフォーマンス特定解析を再度実行します。

全体的な [Effective Physical Core Utilization (効率的な物理コア利用率)] は 10% 向上しました。
OpenMP* シリアル時間は 9% に減り、インテル® VTune™ Amplifier によって問題フラグが付けられなくな
りました (メトリックのしきい値は 15% です)。
並列効率をさらに向上するには、「OpenMP*インバランスとスケジュール・オーバーヘッド」クックブック・レシ
ピで示すように、最もバランスの悪いバリアを解析できます。

スレッドエラーを調査する
並列処理の解析を完了するには、データ競合やデッドロックなどのスレッドエラーをチェックします。チェックには、一部のハードウェアでは発生せずに別の環境では問題となる、あるいは同じ環境の異なる設定で発生する潜在的なデータ競合とデッドロックも検出できる、インテル® Inspector を使用します。
コマンドライン・インターフェイスを使用し、ワークロード・サイズを減らすと、チェックを高速に行い代表的な結果が得られます。
inspxe-cl -collect ti3 ./miniFE.x nx 40 ny 40 nz 40
インテル® Inspector は並列コードの問題は検出しません。

注
このレシピの情報は、デベロッパー・フォーラム (英語) を参照してください。

関連項目
•
•
•
•

OpenMP* コード解析
HPC パフォーマンス特性解析 (英語)
スレッド解析 (英語)
チュートリアル: MPI/OpenMP* ハイブリッド・アプリケーションの解析 (英語)インテル® TBB アプリケーションのスケジュール・オーバーヘッド
このレシピは、インテル® スレッディング・ビルディング・ブロック (インテル® TBB) アプリケーションのスケ
ジュール・オーバーヘッドを検出して修正する方法を説明します。
コンテンツ・エキスパート: Dmitry Prohorov (英語)
スケジュール・オーバーヘッドは、細粒度の作業チャンクをスレッド間で動的に分散する場合に発生する典型的な問題です。スケジュール・オーバーヘッドが発生している場合、ワーカースレッドに作業を割り当てるため
スケジューラーが費やす時間と、ワーカースレッドが新しい作業の待機に費やす時間が長くなると、並列処理の効率が低下し、極端なケースでは、プログラムのスレッド化したバージョンのほうがシーケンシャル・バー
ジョンよりも遅くなります。ほとんどのインテル® TBB 構文は、オーバーヘッドを回避するためチャンク数をデフォルトの粒度よりも大きくする、デフォルトの自動パーティショナーを使用します。意図的にまたは
parallel_deterministic_reduce などの構文を使用して単純なパーティショナーを使用する場合、単純なパーティショナーは最大で 1 反復のデフォルトの粒度と等しいチャンクサイズに作業を分割するため、粒度を調整する必要があります。インテル® VTune™ Amplifier は、インテル® TBB アプリケーションのスケ
ジュール・オーバーヘッドの検出を支援し、粒度を大きくしてオーバーヘッドによる速度低下を回避するためのアドバイスを提供します。
••

使用するもの
手順:
1. ベースラインを作成する
2. スレッド解析を実行する
3. スケジュール・オーバーヘッドを特定する
4. 並列処理の粒度を大きくする

使用するもの
以下は、パフォーマンス解析シナリオで使用するハードウェアとソフトウェアのリストです。
••

アプリケーション: インテル® TBB の parallel_deterministic_reduce テンプレート関数を使用してベクトル要素の合計を計算するサンプル・アプリケーション
コンパイラー: インテル® コンパイラーまたは GNU* コンパイラー。次のコンパイラー/リンカーオプ
ションを指定します。
-I <tbb_install_dir>/include -g -O2 -std=c++11 -o vector-reduce vectorreduce.cpp -L <tbb_install_dir>/lib/intel64/gcc4.7 -ltbb•

パフォーマンス解析ツール: インテル® VTune™ Amplifier 2019: スレッド解析
注ooインテル® VTune™ プロファイラー評価版のダウンロードと製品サポートについては、
https://www.isus.jp/intel-vtune-amplifier-xe/ を参照してください。
このクックブックのレシピはすべてスケーラブルであり、インテル® VTune™ Amplifier 2018以降に適用できます。バージョンにより設定がわずかに異なることがあります。

ベータ版インテル® oneAPI ベース・ツールキット向けのバージョンから、インテル® VTune™
Amplifier の名称がインテル® VTune™ プロファイラーに変わりました。引き続き、インテル®
Parallel Studio XE またはインテル® System Studio のコンポーネントとして、あるいはスタ
ンドアロン版のインテル® VTune™ プロファイラーをご利用いただけます。
オペレーティング・システム: Ubuntu* 16.04 LTS
CPU: インテル® Xeon® プロセッサー E5-2699 v4 @ 2.20GHzo••

ベースラインを作成する
サンプルコードの初期バージョンは、デフォルトの粒度で parallel_deterministic_reduce を使用します (行 17-23)。
#include <stdlib.h>#include "tbb/tbb.h"static const size_t SIZE = 50*1000*1000;
double v[SIZE];
using namespace tbb;
void VectorInit( double *v, size_t n ){parallel_for( size_t( 0 ), n, size_t( 1 ), [=](size_t i){ v[i] = i *2; } );}
double VectorReduction( double *v, size_t n ){return parallel_deterministic_reduce(
blocked_range<double*>( v, v + n ),0.f,[](const blocked_range<double*>& r, double value)->double {return std::accumulate(r.begin(), r.end(), value);},
std::plus<double>());}
int main(int argc, char *argv[]){
task_scheduler_init( task_scheduler_init::automatic );VectorInit( v, SIZE );double sum;for (int i=0; i<100; i++)sum = VectorReduction( v, SIZE );return 0;}

統計解析向けに大きく測定可能な計算処理にするため、行 35 のループでベクトル合計計算を繰り返しています。
コンパイルしたアプリケーションの実行には約 9 秒かかりました。これが、以降の最適化で使用するパフォー
マンスのベースラインとなります。

スレッド解析を実行する
アプリケーションのスレッド並列性とスケジュール・オーバーヘッドに費やされた時間を予測するには、並行性解析を実行します。
1. ツールバーの[New Project (新規プロジェクト)] ボタンをクリックして、新規プロジェクトの名

前 (例: vector-reduce) を指定します。
2. [Create Project (プロジェクトの作成)] をクリックします。
[Configure Analysis (解析の設定)] ウィンドウが表示されます。
3. [WHERE (どこを)] ペインで、[Local Host (ローカルホスト)] ターゲット・システム・タイプを選択します。
4. [WHAT (何を)] ペインで、[Launch Application (アプリケーションを起動)] ターゲットタイプを選択して、解析するアプリケーションを指定します。
5. [HOW (どのように)] ペインで、[...] ボタンをクリックして [Parallelism (並列性)] > [Threading (スレッド化)] を選択します。
6.

[Start (開始)] ボタンをクリックします。

インテル® VTune™ Amplifier は、アプリケーションを起動してデータを収集し、収集したデータをファイナライズして、シンボル情報を解決します。この情報は、ソース解析で必要になります。
注
スレッド解析はインストルメンテーション・ベースでスタックのスティッチを使用するため、収集オーバーヘッド
により、インストルメントされたアプリケーションの経過時間はオリジナルのアプリケーションの実行よりも長くなります。

スケジュール・オーバーヘッドを特定する
アプリケーション・レベルの統計が表示される [Summary (サマリー)] ビューから解析を始めます。
[Effective CPU Utilization Histogram (効率良い CPU 利用率の分布図)] は、アプリケーションが利用可
能な 88 コアのうち平均で約 3 コアしか使用していないことを示しています。

フラグが付いた [Overhead Time (オーバーヘッド時間)] メトリックと [Scheduling (スケジューリング)])
サブメトリックは、調査すべき非効率的なスレッド化の問題を示しています。

[Top Hotspots (上位 hotspot)] セクションから [TBB Dispatch Loop] が最も時間を費やしている関数
であることが分ります。関数に関連するフラグのヒントは、並列処理の粒度を大きくして対応すべきスケジュー
ル・オーバーヘッドに関する情報を示しています。

サンプル・アプリケーションには、ベクトル要素の合計を計算する 2 つのインテル® TBB 構文
parallel_for の初期化と parallel_deterministic_reduce が含まれています。[Caller/Callee(呼び出し元/呼び出し先)] データビューを使用して、どちらのインテル® TBB 構文でオーバーヘッドが発生しているか確認します。[CPU Time: Total (CPU 時間: 合計)] > [Overhead Time (オーバーヘッド時間)] カラムを展開して、[Scheduling (スケジューリング)] カラムでグリッドをソートします。[Function (関数)] リストでインテル® TBB の並列構文を含む最初の行を見つけます。

この行は、スケジュール・オーバーヘッドが最も大きい VectorReduction 関数のparallel_deterministic_reduce 構文をポイントしています。この構文の並列処理でオーバーヘッドを排除できるように、作業チャンクをより粗粒度にします。
注
アプリケーションの実行中にインバランスを視覚化するには、[Timeline (タイムライン)] ビューを使用します。有効な作業を実行している時間は緑色で示され、浪費時間は黒色で示されます。

並列処理の粒度を大きくする
前述のとおり、ワーカースレッドに細粒度の作業チャンクを割り当てると、スケジューラーが作業割り当てに費
やす時間を相殺できません。単純なパーティショナーを使用する parallel_deterministic_reduce のデフォルトのチャンクサイズは 1 です。つまり、ワーカースレッドは 1 ループ反復を実行しただけで、スケ
ジューラーに新しい作業を要求します。次のコードのように、最小チャンクサイズを 10,000 に増やします (行5)。
double VectorReduction( double *v, size_t n ){return parallel_deterministic_reduce(
blocked_range<double*>( v, v + n, 10000 ),0.f,[](const blocked_range<double*>& r, double value)->double {return std::accumulate(r.begin(), r.end(), value);},
std::plus<double>());}
そして、スレッド解析を再度実行します。

アプリケーションの経過時間が大幅に減り、効果的な CPU 使用率の平均は約 38 論理コアになります (このメトリックにはウォームアップ・フェーズが含まれるため、計算フェーズの CPU 使用率は 80 コア近くに上ります)。インテル® TBB のスケジューリングやその他の並列処理関連の作業に費やされた CPU 時間はわずかです。このわずかなコード変更によって、アプリケーション全体では (収集時間を除いて) オリジナルバージョンと比較して 10 倍のスピードアップを達成しました。

注
このレシピの情報は、デベロッパー・フォーラムを参照してください。

関連項目•

スレッド解析 (英語)PMDK アプリケーション・オーバーヘッド
このレシピは、PMDK ベースのアプリケーションのメモリーアクセスのオーバーヘッドを検出して修正する方法を説明します。
コンテンツ・エキスパート: Kirill Uhanov (英語)
不揮発性メモリー開発キット (PMDK) は、データの一貫性と耐久性を維持するためのトランザクションおよび
アトミック操作のサポートを提供します。Linux* と Windows* の両方で利用可能なオープンソースのライブ
ラリーとツールのコレクションです。詳細は、不揮発性メモリー・プログラミングのウェブサイト pmem.io (英語) を参照してください。PMDK は、高水準言語のサポートにより、不揮発性メモリー・プログラミングの採用を容易にします。現在、完全に検証済みの C/C++ サポートを Linux* で利用できます。Windows* では早期アクセスとして利用できます。
インテルの新世代の不揮発性メモリーは、メモリー層とストレージ層に加え、DRAM よりも大容量でストレー
ジよりも高速な第 3 のメモリー層を提供します。アプリケーションは、従来のメモリーと同様に不揮発性メモ
リー内のデータ構造にアクセスでき、メモリーとストレージ間のデータブロック転送の必要性を排除します。
しかし、PMDK ライブラリーを利用すると、アプリケーションのパフォーマンスに影響することがあります。このレシピでは、インテル® VTune™ Amplifier でそのような問題を検出する方法を説明します。
••

使用するもの手順:
1. PMDK アプリケーションのメモリーアクセス解析を実行する
2. PMDK ベースのアプリケーションの hotspot を特定する
3. 冗長な PMDK 関数呼び出しを削除する

使用するもの
以下は、パフォーマンス解析シナリオで使用するハードウェアとソフトウェアのリストです。
••

アプリケーション: PMDK メモリー・アロケーターを使用して 2 つのベクトルの要素単位の合計を計算するサンプル・アプリケーション
コンパイラー: GNU* コンパイラー。次のコンパイラー/リンカーオプションを指定します。
gcc -c -o array.o -O2 -g -fopenmp -I <pmdk-install-dir>/src/include -I<pmdk-install-dir>/src/examples array.c
gcc -o arrayBefore array.o -fopenmp -L <pmdk-install-dir>/src/nondebug-lpmemobj -lpmem -pthread•

パフォーマンス解析ツール: インテル® VTune™ Amplifier 2018: メモリーアクセス解析/高度なhotspot 解析

注インテル® VTune™ プロファイラー評価版のダウンロードと製品サポートについては、
https://www.isus.jp/intel-vtune-amplifier-xe/ を参照してください。
o このクックブックのレシピはすべてスケーラブルであり、インテル® VTune™ Amplifier 2018以降に適用できます。バージョンにより設定がわずかに異なることがあります。
o ベータ版インテル® oneAPI ベース・ツールキット向けのバージョンから、インテル® VTune™
Amplifier の名称がインテル® VTune™ プロファイラーに変わりました。引き続き、インテル®
Parallel Studio XE またはインテル® System Studio のコンポーネントとして、あるいはスタ
ンドアロン版のインテル® VTune™ プロファイラーをご利用いただけます。
オペレーティング・システム: Ubuntu* 16.04 LTS
CPU: インテル® Core™ i7-6700K プロセッサー @ 4.00GHzo••

PMDK アプリケーションのメモリーアクセス解析を実行する
このレシピは、不揮発性メモリーを利用するサンプル・アプリケーションから始めます。このアプリケーション
は、よく知られている STREAM ベンチマークの Triad カーネルを使用して、DRAM 帯域幅を最大限に利用します。
統計解析向けに大きく測定可能な計算処理にするため、ループでベクトル合計計算を繰り返しています。
#include <ex_common.h>#include <stdio.h>#include <stdlib.h>#include <sys/stat.h>#include <libpmemobj.h>#include <omp.h>#define REPEATS 32
POBJ_LAYOUT_BEGIN(array);
POBJ_LAYOUT_TOID(array, int);
POBJ_LAYOUT_END(array);int
main(){
size_t size = 82955000;
size_t pool_size = 16200000000;
int i,j;int multiplier = 3;
PMEMobjpool *pop;
char* path = "test_file1";
if (file_exists(path) != 0){
if ((pop = pmemobj_create(path, POBJ_LAYOUT_NAME(array),pool_size, CREATE_MODE_RW)) == NULL){
printf("failed to create pool\n");return 1;
}

}
else
{
if ((pop = pmemobj_open(path, POBJ_LAYOUT_NAME(array))) == NULL){
printf("failed to open pool\n");return 1;}}
TOID(int) a;
TOID(int) b;
TOID(int) c;
POBJ_ALLOC(pop, &a, int, sizeof(int) * size, NULL, NULL);POBJ_ALLOC(pop, &b, int, sizeof(int) * size, NULL, NULL);POBJ_ALLOC(pop, &c, int, sizeof(int) * size, NULL, NULL);
for (i = 0; i < size; i++){
D_RW(a)[i] = (int)i;
D_RW(b)[i] = (int)i+100;
D_RW(c)[i] = (int)i+3;}
pmemobj_persist(pop, D_RW(a), size * sizeof(*D_RW(a)));pmemobj_persist(pop, D_RW(b), size * sizeof(*D_RW(b)));pmemobj_persist(pop, D_RW(c), size * sizeof(*D_RW(c)));for (j = 0; j < REPEATS; j++){#pragma omp parallel forfor (i = 0; i < size; i++){
D_RW(c)[i] = multiplier * D_RO(a)[i] + D_RO(b)[i];}}POBJ_FREE(&a);
POBJ_FREE(&b);
POBJ_FREE(&c);
pmemobj_close(pop);
return 0;}
サンプルコード内のパフォーマンスの問題を特定し、メモリーアクセスに費やされた時間を予測するには、
インテル® VTune™ Amplifier を起動してメモリーアクセス解析を実行します。
1. ツールバーの [New Project (新規プロジェクト)] ボタンをクリックして、新規プロジェクトの名前 (例:arraysum) を指定します。
2. [Analysis Target (解析ターゲット)] ウィンドウで、ホストベースの解析として [local host (ローカルホスト)] ターゲット・システム・タイプを選択します。
3. [Launch Application (アプリケーションを起動)] ターゲットタイプを選択して、右ペインで解析する
アプリケーションを指定します。

4. 右の [Choose Analysis (解析の選択)] ボタンをクリックし、[Microarchitecture Analysis (マイクロアーキテクチャー解析)] > [Memory Access (メモリーアクセス)] を選択して、[Start (開始)] をク
リックします。
インテル® VTune™ Amplifier は、アプリケーションを起動してデータを収集し、収集したデータをファ
イナライズして、シンボル情報を解決します。この情報は、ソース解析で必要になります。

PMDK ベースのアプリケーションの hotspot を特定する
ハードウェア・メトリックごとのアプリケーション・レベルの統計が表示される [Summary (サマリー)] ビュー
から解析を始めます。通常、基本パフォーマンス・ベースラインはアプリケーションの経過時間です。このサンプ
ルコードでは約 16 秒です。
この PMDK コードでは高い DRAM 使用率が予測されましたが、 [Summary (サマリー)] ビューのメトリック
はこのサンプル・アプリケーションを DRAM 帯域幅依存として定義していません。

[Bandwidth Utilization Histogram (帯域幅利用率分布図)] もアプリケーションが DRAM 帯域幅を最大限に使用していないことを示しており、[Observed Maximum (観察された最大値)] は予想を大きく下回る約
13GB/秒です。

PMDK によりコードのオーバーヘッドが増えているのは明らかです。詳細を確認するため、[Bottom-up (ボトムアップ)] ビューに切り替えて [Function/Call Stack (関数/コールスタック)] グループレベルを適用します。

最も大きな hotspot は pmemobj_direct_inline です。この関数は、D_RO マクロと D_RW マクロから呼び出されています。関数をダブルクリックして、<pmdk-install-dir>/src/include/libpmemobj/
types.h にあるソースコードを表示します。
#define DIRECT_RW(o) \(reinterpret_cast < __typeof__((o)._type) > (pmemobj_direct((o).oid)))#define DIRECT_RO(o) \(reinterpret_cast < const __typeof__((o)._type) > \(pmemobj_direct((o).oid)))#endif /* (defined(_MSC_VER) || defined(__cplusplus)) */#define D_RW
#define D_RO

DIRECT_RW
DIRECT_RO

注
アプリケーション実行中の DRAM 帯域幅の使用状況を視覚化するには、[Platform (プラットフォーム)]ビューを使用します。DRAM 帯域幅は、緑色と青色で表示されます。

冗長な PMDK 関数呼び出しを削除する
各配列のメモリーは 1 つのチャンクとして割り当てられるため、D_RO と D_RW は配列の開始アドレスを取得するため計算前に一度だけ呼び出します。
int* _c = D_RW(c);const int* _a = D_RO(a);const int* _b = D_RO(b);for (j = 0; j < REPEATS; j++){#pragma omp parallel forfor (i = 0; i < size; i++){_c[i] = multiplier * _a[i] + _b[i];}}アプリケーションを再コンパイルしメモリーアクセス解析を再度実行して、この変更がパフォーマンスにどのように影響したか確認します。

アプリケーションの経過時間が大幅に減ったことが分ります。PMDK オーバーヘッドはパフォーマンスに影響しません。
[Bandwidth Utilization Histogram (帯域幅利用率分布図)] はアプリケーションが DRAM 帯域幅を最大限に使用していないことを示しており、[Observed Maximum (観察された最大値)] は約 25GB/秒です。

注
このレシピの情報は、デベロッパー・フォーラム (英語) を参照してください。

関連項目
•
•

インテルの不揮発性メモリーを利用するプログラミングの概要 (英語)
[Memory Usage (メモリー使用)] ビューポイント (英語)

法務上の注意書き
本資料は、明示されているか否かにかかわらず、また禁反言によるとよらずにかかわらず、いかなる知的財産権のライセンスも許諾するものではありません。
インテル® テクノロジーの機能と利点はシステム構成によって異なり、対応するハードウェアやソフトウェア、またはサービスの有効化が必要となる場合があります。実際の性能はシステム構成によって異なります。絶対的なセキュリティーを提供できる製品はありません。詳細については、各システムメーカーまたは販売店にお問い合わせいただくか、http://www.intel.co.jp/ を参照してください。
インテルは、明示されているか否かにかかわらず、いかなる保証もいたしません。ここにいう保証には、商品適格性、特定目的への適合性、および非侵害性の黙示の保証、ならびに履行の過程、取引の過程、または取引での使用から生じるあらゆる保証を含みますが、これらに限定されるわけではありません。
本資料には、開発中の製品、サービスおよびプロセスについての情報が含まれています。本資料に記載されているすべての情報は、予告なく変更されることがあります。最新の予測、スケジュール、仕様、ロードマップをご希望の方は、インテルの担当者までお問い合わせください。
本資料で説明されている製品およびサービスには、不具合が含まれている可能性があり、公表されている仕様とは異なる動作をする場合があります。現在確認済みのエラッタについては、インテルまでお問い合わせください。
Intel、インテル、Intel ロゴ、Arria、Intel Core、Quartus、Xeon、VTune は、アメリカ合衆国および / またはその他の国における Intel Corporation またはその子会社の商標です。
* その他の社名、製品名などは、一般に各社の表示、商標または登録商標です。
Microsoft および Windows は、米国 Microsoft Corporation の、米国およびその他の国における登録商標
または商標です。
Java は、Oracle および / または関連会社の登録商標です。
OpenCL および OpenCL ロゴは、Apple Inc. の商標であり、Khronos の使用許諾を受けて使用しています。
本ソフトウェアおよび関連ドキュメントはインテルの著作物であり、その使用には付随する明示的なライセンスが適用されます (「ライセンス」)。ライセンスに明記されている場合を除き、インテルから事前に書面による許可なしに、ソフトウェアまたは関連ドキュメントを使用、改変、複製、公開、配布、開示、転送してはなりません。
本ソフトウェアおよび関連ドキュメントは現状のまま提供され、ライセンスに明記されている場合を除き、明示されているか否かにかかわらず、いかなる保証もいたしません。
© Intel Corporation.
コンパイラーの最適化に関する詳細は、最適化に関する注意事項を参照してください。