CPU メトリックのリファレンス

アシスタント

メトリックの説明

このメトリックは、アシストの結果として Microcode_Sequencer によって供給された CPU がリタイアした uop のサイクルの割合を推定します。アシストは、実行パイプラインで直接実行できない操作に対して、特定の用途で必要とされる長い uOps のシーケンスです。例えば、非常に小さな浮動小数点値 (デノーマルと呼ばれます) を操作する場合、浮動小数点ユニットはこの操作を直接実行することができません。代わりに、デノーマル値の計算を行う命令のシーケンスがパイプラインに投入されます。これらのマイクロコード・シーケンスは数百の命令で構成されるため、マイクロコード・アシストはパフォーマンス上有害です。

考えられる問題

実行時間の大部分がマイクロコード・アシストで費やされています。

ヒント:

メトリックの説明

バックエンド依存メトリックは、バックエンドで新しい uOps を受け入れるのに必要なリソースが不足しているため、uOps が供給されていないパイプライン・スロットの割合を表します。バックエンドはプロセッサー・コアの一部であり、準備が整った uOps をアウトオブオーダー・スケジューラーが対応する実行ユニットにディスパッチし、操作が完了すると、uOps はプログラムの順番でリタイアしていきます。例えば、データキャッシュ・ミスによるストールや、除算器のオーバーロードによるストールは、どちらもバックエンド依存に分類されます。バックエンド依存はさらにの 2 つのカテゴリーに分けられます。メモリー依存とコア依存。

考えられる問題

メトリックの説明

このメトリックは、コアの除算器に関連しない問題により、アプリケーションがストールしていたサイクルの割合を表します。そのような問題の例として、近接する命令間のデータ依存関係が多い、または特定のポートに負荷をかける命令シーケンスなどがあります。ヒント: ループのベクトル化 - 最近のコンパイラーは自動ベクトル化機能を備えています - 複数の要素が同じ uOp で計算されるため実行ポートへの負荷を軽減します。

考えられる問題

除算器に関連しないコアの問題により、かなりのサイクルがストールしています。

このメトリックは、実行ポート 4 (ストアデータ) で CPU がディスパッチした uOps のコアサイクルの割合を示します。このメトリック値は、分割ストアの問題によりハイライトされる可能性があることに注意してください。

ポート 5

メトリックの説明

このメトリックは、実行ポート 5 (SNB+: 分岐と ALU; HSW+: ALU ) で CPU がディスパッチした uOps のコアサイクルの割合を示します。

ポート 6

メトリックの説明

メトリックの説明

スーパースカラー・プロセッサーは、概念的に命令をフェッチしてそれらを構成する操作にデコードする 'フロントエンド' と、要求される計算を実行する 'バックエンド' に分かれています。フロントエンドは、各サイクルでバックエンドを通過するパイプライン・スロットに配置される最大 4 つの操作を生成します。そのため、クロックサイクルの一定の実行期間において、その期間にリタイアすることができる有用なワークを含むパイプライン・スロットの最大数を知ることは容易です。しかし、有用なワークを含むリタイアしたパイプライン・スロットの実際の数が、この最大数になることはほとんどありません。これにはいくつかの要因が関連します: フロントエンドが時間内に命令をフェッチもしくはデコードできなかったり (フロントエンド依存の実行)、バックエンドが特定の種類の操作を受け入れる準備ができていない (バックエンド依存の実行) ことにより、パイプライン・スロットを有用なワークで埋めることができないなどが考えられます。さらに、パイプライン・スロットが有効なワークを含んでいても、投機の問題によりリタイアしない可能性があります。フロントエンド依存の実行は、コードのワーキングセットが大きい、コードのレイアウトが適切でない、またはマイクロコード・アシストによって発生する可能性があります。バックエンド依存の実行は、レイテンシーの長い操作や実行リソースに対するその他の競合が原因である可能性があります。投機の問題は、ほとんどの場合、分岐予測ミスによって発生します。

考えられる問題

FP 算術演算

メトリックの説明

このメトリックは、CPU が実行 (リタイア) した全体の算術浮動小数点 (FP) uOps の割合を示します。

FP アシスト

メトリックの説明

一部の浮動小数点命令は実行パイプラインで直接実行できないため、マイクロコードを実行する必要があります (小さなプログラムを実行ストリームへ投入)。例えば、非常に小さな浮動小数点値 (デノーマルと呼ばれます) を操作する場合、浮動小数点ユニットはこの操作を直接実行することができません。代わりに、デノーマル値の計算を行う命令のシーケンスがパイプラインに投入されます。これらのマイクロコード・シーケンスは数百の命令で構成されることがあるため、マイクロコード・アシストはパフォーマンス上有害です。

考えられる問題

実行時間の大部分が浮動小数点アシストで費やされています。

ヒント

非正規数をゼロにフラッシュするには、コンパイラーで DAZ (Denormals Are Zero) オプションや FTZ (Flush To Zero) オプションを有効にすることを検討してください。アプリケーションにおいて非正規化値が重要でない場合は、このオプションによりパフォーマンスが向上する可能性があります。しかし、DAZ モードと FTZ モードは IEEE 標準 754 と互換性がないことに注意してください。

FP スカラー

メトリックの説明

このメトリックは、CPU が実行した算術浮動小数点 (FP) スカラー uOps の割合を示します。メトリック値を解析して、ベクトルコードが生成されない理由を特定します。これは通常、選択されたアルゴリズムまたはコンパイラー・オプションの不足/誤りによって発生します。

FP ベクトル

メトリックの説明

このメトリックは、CPU が実行した算術浮動小数点 (FP) ベクトル uOps の割合を示します。ベクトルの幅が期待通りであることを確認してください。

FP x87

メトリックの説明

このメトリックは、CPU が実行した浮動小数点 (FP) x87 uOps の割合を示します。これは、x87 FP 算術演算命令をカウントします。これにより、x87 の使用を回避し、最新の ISA にアップグレードする判断基準として使用できます。コンパイラー・オプションを使用して、新しい AVX (または SSE) 命令セットを生成します。これにより、より優れたベクトル化が行われます。

MS アシスト

メトリックの説明

特定の厄介なケースの操作は、実行パイプラインでネイティブに処理することができず、1 つ以上の uOps が発行されるマイクロコード・シーケンサー (MS) によって実行される必要があります。マイクロコード・シーケンサーは、マイクロコード・アシスト (実行ストリームに挿入される小さなプログラム)、フローの挿入、および命令キュー (IQ) への書き込みを実行します。例えば、非常に小さな浮動小数点値 (デノーマルと呼ばれます) を操作する場合、浮動小数点ユニットはこの操作を直接実行することができません。代わりに、デノーマル値の計算を行う命令のシーケンスがパイプラインに投入されます。これらのマイクロコード・シーケンスは数百の命令で構成されることがあるため、マイクロコード・アシストはパフォーマンス上有害です。

考えられる問題

実行時間の大部分は、マイクロコード・アシスト、挿入されたフロー、および命令キュー (IQ) への書き込みに費やされています。特定の原因を知るには、FP アシストと SIMD アシストのメトリックを調査します。

分岐予測ミス

メトリックの説明

分岐予測が誤っている場合、誤った予測のパスから一部の命令はパイプラインを通過し続けます。これらの命令で実行されるすべてのワークは、分岐が正しく予測されていれば実行されないため、無駄になります。このメトリックは、分岐予測ミスにより CPU が無駄に消費したスロットの割合を表します。これらのスロットは、誤って推測されたプログラムパスから取得された uOps によって消費されるか、マシンのアウトオブオーダーが推測パスから状態を回復する必要があるときにストールします。

考えられる問題

かなりの分岐が誤って予測され、マシンが投機的なパスから状態を回復する必要があるため、非常に多くの無駄なワークやバックエンドのストールを引き起こしています。

ヒント

1.大幅に予測が誤っている分岐を特定し、アルゴリズムをより予測可能にするか、分岐の数を減らすことを検討します。'if' 文にさらにワークを追加し、コードフローの上位に移動することで、より早期に実行することができます。'switch' と 'case' 文を使用する場合、多く実行される case 文を最初に配置します。頻繁に実行される呼び出しに仮想関数ポインターを使用しないでください。

2.コンパイラーのプロファイル・ガイド最適化を使用します。

分岐予測ミスの問題に対処する一般的な方針については、『インテル® 64 および IA-32 プロセッサー・アーキテクチャー最適化リファレンス・マニュアル』を参照してください。

バスロック

メトリックの説明

インテル® プロセッサーは、特定の重要なメモリーの操作中に自動的にアサートされる、システムバスまたは同等のリンクをロックする LOCK# 信号を提供します。この出力信号がアサートされている間、他のプロセッサーまたはバス・エージェントからのバス制御要求はブロックされます。このメトリックは、バス上で LOCK# 信号がアサートされているバスサイクルの割合を測定します。LOCK# 信号は、キャッシュ不可能なメモリー、2つのキャッシュラインにまたがるロックされた操作、およびキャッシュ不可能なページテーブルからのページウォークによって、メモリーアクセスがロックされたときにアサートされます。

考えられる問題

バスロックに非常に高いパフォーマンス上のペナルティーが課せられています。メモリーの同時実行性を向上させるため、ロックされたメモリーアクセスを回避することを強く推奨します。

ヒント

[ソース/アセンブリー] 表示の BUS_LOCK_CLOCKS.SELF イベントを調査して、LOCK# 信号がアサートされている場所を特定します。問題が自身から発生している場合、メモリーのレイテンシーや再発行などバックエンドの問題を調べます。スキッドを考慮します。

キャッシュ依存

メトリックの説明

このメトリックは、マシンが L1、L2、および L3 キャッシュでストールした頻度を示します。キャッシュヒットは DRAM ヒットよりもはるかに高速に処理されますが、パフォーマンスを大幅に低下させる可能性があります。このメトリックには、共有データに対する一貫性のペナルティーも含まれます。

考えられる問題

サイクルのかなりの割合がキャッシュからのデータ取得に費やされています。L2 または L3 キャッシュへのアクセスに問題があるか確認するため、メモリーアクセス解析をチェックし、キャッシュをミスしたワークロードと同じパフォーマンス・チューニングの適用を検討してください。これには、データ・ワーキング・セットのサイズ縮小、データアクセス局所性の改善、低レベルのキャッシュに収めるためのワーキングセットのブロック化や分割、またはハードウェア・プリフェッチャーの使用が含まれます。ソフトウェア・プリフェッチャーの使用を検討してください。ただし、通常のロードの妨げとなったり、レイテンシーの増加やメモリー・サブシステムの負担が増える可能性があることに注意してください。このメトリックには、共有データに対する一貫性のペナルティーが含まれます。マイクロアーキテクチャー全般解析をチェックして、競合アクセスまたはデータ共有が問題であるかどうかを確認します。

クリアリステア

メトリックの説明

このメトリックは、マシンクリアの結果としての分岐リステアによって CPU がストールしたサイクルの割合を測定します。

考えられる問題

マシンクリアの結果として、分岐リステアによってサイクルのかなりの部分がストールする可能性があります。

命令リタイアごとのクロックティック (CPI)

メトリックの説明

リタイアした命令あたりのクロック数 (CPI) イベント比率は、1 命令あたりのサイクル数とも呼ばれ、サンプリング・モードにおけるにおけるパフォーマンス・モニタリング・カウンター (PMC) 解析としても知られる、ハードウェア・イベントベース・サンプリング収集の基本パフォーマンス・メトリックの 1 つです。この比率は、HALT (停止) 状態ではないプロセッサー・サイクル (クロックティック) をリタイアした命令数で除算することで計算されます。プロセッサーごとにクロックティックとリタイアした命令をカウントするイベントは異なることがありますが、インテル® VTune™ プロファイラーは正しいイベントを認識します。

高い CPI 値の意味は ?

アプリケーションや関数の CPI 値は、実行に及ぼすレイテンシーの影響を表します。CPI 値が高いほど、システムのレイテンシーが増加することを意味し、平均して命令がリタイアするまでのクロックティックが長くなります。システムのレイテンシーは、キャッシュミス、I/O、およびその他のボトルネックによって引き起こされます。

パフォーマンス・チューニングの労力を費やす場所を特定する場合、CPI は最初に確認すべきメトリックです。良好な CPI 率は、コードが適切に実行されていることを示します。

CPI を使用する一般的な方法は、現在の CPI 値を同じワークロードを実行するベースライン CPI 値と比較することです。例えば、システムやコードを変更した後に、インテル® VTune™ プロファイラーを実行して CPI 値を収集します。変更後アプリケーションのパフォーマンスが低下した場合、CPI が増加した関数を特定するのは、何が起こったか理解する方法の 1 つです。アプリケーションの実行時間を短縮する最適化が行われた場合、インテル® VTune™ プロファイラーのデータを調査して CPI が低下していることを確認できます。また、この情報は以降の最適化に向けた調査でも活用できます。CPI が減少する要因は ? キャッシュミスの減少、メモリー操作の減少、メモリー・レイテンシーの減少などが考えられます。

高い CPI を特定する方法は ?

実行するワークロードの CPI 値は、コード、プロセッサー、およびシステム構成の影響を受けます。

インテル® VTune™ プロファイラーは、インテルが設定するしきい値に対する CPI 値を解析します。これらの値は一般的なガイドとして使用できます。

良い	低い
0.75	4

CPI < 1 は一般的に命令依存のコードですが、CPI > 1 はメモリー依存のようなストールサイクルに依存するアプリケーションに見られます。

CPI 値がしきい値を超えると、インテル® VTune™ プロファイラーはその値をピンク色でハイライトします。

高い CPI 比率 (>1) は、コード領域の命令を実行するため多くのプロセッサー・クロックが費やされていることを示します。大部分の命令が高レイテンシーではなく、および (また) マイクロコード ROM から供給される場合、これは問題があることを示します。この場合、プロセッサー内部で命令が実行されるように効率を高めるため、コードを変更する余地があります。

インテル® ハイパースレッディング・テクノロジーが有効なプロセッサーでは、この比率は物理パッケージのスリープモードではない、つまり物理パッケージの少なくとも 1 つの論理プロセッサーが使用するフェーズの CPI を測定します。論理プロセッサーのクロックティックは、論理プロセッサーが HALT (停止) 状態 (命令を実行しない状態) であっても継続してカウントされます。クロックティック・イベントは、リタイアした命令イベントが変わらなくとも継続してカウントされるため、論理プロセッサーの CPI 比率に影響を及ぼす可能性があります。高い CPI 値はパフォーマンスの問題があることを示しますが、特定の論理プロセッサーの高い CPI 値は非効率な CPU の使用を示し、実行上は問題とはならない可能性があります。

アプリケーションがスレッド化されている場合、CPI はすべてのコードレベルに影響します。クロックティック・イベントは、各論理プロセッサーで独立してカウントされ、並列実行は考慮されません。

例えば、次のについて考えてみます。

論理プロセッサー 0 上の関数 XYZ |------------------------| 4000 クロックティック/1000 命令

論理プロセッサー 1 上の関数 XYZ |------------------------| 4000 クロックティック/1000 命令

関数 XYZ の CPI は、(8000 / 2000) 4.0 です。クロックティックで並列実行を考慮すると、CPI は (4000 / 2000) 2.0 になります。クロックティック・イベント・データを解釈するには、アプリケーションの動作に関する知識が求められます。

CPI を使用する落とし穴は ?

CPI は誤解を招く可能性があるため、その落とし穴を理解する必要があります。システム上のコードのパフォーマンスに影響を及ぼすのは、CPI (レイテンシー) だけではありません。もう一つの重要な要因は、実行される命令数です (パス長とも呼ばれます)。コードを最適化したり変更すると、命令実行時間 (CPI) や実行する命令数、またはそれら両方に影響します。実行された命令数を考慮せずに CPI を参照すると、解析結果を誤って解釈する可能性があります。例えば、コードをベクトル化し、単一の命令で複数のデータを処理するように数学演算を変更したと仮定します。これは、多数の単一データの操作命令を、少数の複数データ操作命令に置き換えることで実現されます。これにより、コード全体で実行される命令数は減少しますが、複数データ処理命令 (SIMD) は複雑で実行に時間がかかるため、CPI が上昇する可能性があります。多くの場合、CPI が上昇してもベクトル化によりパフォーマンスは向上します。

実行されたすべての命令を考慮する必要があります。実行された命令数は、インテル® VTune™ プロファイラーでは、INST_RETIRED と呼ばれます。リタイアした命令数が一定である場合、CPI はパフォーマンス・チューニングに適した指標であると言えます (例えば、システムのチューニング)。命令数と CPI の両方が変化する場合、それぞれのメトリックを調べて、パフォーマンスが向上または低下した原因を理解する必要があります。最後に、CPI に代わってトップダウン方式を適用します。

クロックティックとパイプライン・スロット・ベースのメトリック

CPI レート

メトリックの説明

リタイアした命令あたりのサイクル数 (CPI) は、各命令の実行にかかったおおよその時間を示す基本的なパフォーマンスのメトリックです (単位はサイクル数)。現代のスーパースカラー・プロセッサーはサイクルごとに最大 4 つの命令を発行し、理論上の最高 CPI は 0.25 になります。さまざまな要因 (大きなレイテンシーのメモリー、浮動小数点演算、SIMD 演算、分岐予測ミスによりリタイアしない命令、フロントエンドの命令スタベーションなど) により、測定される CPI の値は高くなる傾向があります。CPI =1 は、ハイパフォーマンス・コンピューティング (HPC) アプリケーションでは許容値と見なされますが、アプリケーション・ドメインごとに期待値は異なります。それでも、CPI はアプリケーションのパフォーマンス・チューニングにおいて、全体的な可能性を判断できる優れたメトリックです。

インテル® VTune™ プロファイラーは、クロックティックまたはパイプライン・スロットとして測定されるマイクロアーキテクチャー全般解析向けのハードウェア・イベントベースのメトリックを提供します。違いを理解ため、次の例を考えてみましょう。

例えば、2 つのスロットがパイプライン・スロットの 50% のサイクルをそれぞれ浪費していると想定します。しかし、クロックティックは、各サイクルでストールがあるため、ストールメトリックは 100% になります。さらに、各サイクルでさまざまな理由によりストールが発生する可能性があり、これはクロックティックで測定されるメトリックが重複する可能性があることを意味します。

クロックティックで測定されるメトリックは、パイプライン・スロットで測定されるメトリックよりも精度が低くなります。これは、重複によりレベルの合計が必ずしも親メトリックの値と一致しないためです。しかし、このようなメトリックは、コード内部のパフォーマンスのボトルネックを特定するのに役立ちます。

考えられる問題

CPI が非常に髙くなっています。これは、メモリーのストール、命令の不足、分岐予測ミス、または長いレイテンシーの命令などによって発生する可能性があります。高い CPI の原因を特定するには、ほかのハードウェア関連のメトリックを調査します。

CPI レート (Intel Atom® プロセッサー)

メトリックの説明

リタイアした命令あたりのサイクル数 (CPI) は、各命令の実行にかかった平均時間をサイクル単位で示す基本的なパフォーマンス・メトリックです。Intel Atom® プロセッサーの場合、理論上のスレッドあたりの最高 CPI は 0.50 ですが、2.0 を超える CPI では調査が必要です。高い CPI 値は、レイテンシーの長いメモリー、浮動小数点演算、分岐予測の誤りによるリタイアされていない命令、フロントエンドでの命令不足など、システム内のレイテンシーを削減できる可能性を示している場合があります。SIMD などの一部の最適化ではサイクルあたりで使用する命令数が少なくなり (CPI が増加)、デバッグコードでは冗長な命令が使用され、サイクルあたりで使用する命令数が多くなる (CPI が減少) 可能性があることに注意してください。

考えられる問題

CPU 時間

メトリックの説明

CPU 時間とは、CPU がアプリケーションをアクティブに実行している時間です。

コア依存

メトリックの説明

このメトリックは、コアのメモリー以外の問題がどの程度ボトルネックになったかを表します。ハードウェア計算リソース不足や依存関係のあるソフトウェア命令は、コア依存に分類されます。したがって、これはマシンの OOO リソースが不足しているか、特定の実行ユニットが過負荷になっているか、プログラムのデータまたは命令フローの依存関係によってパフォーマンスが制限されていることを示している可能性があります (FP チェーンの長いレイテンシーの算術演算など)。

CPU 周波数

メトリックの説明

クロックティック・イベントでキャプチャーされた APERF/MPERF MSR レジスターで計算される周波数です。

2 つのサンプル間の平均論理コア周波数を示すソフトウェア周波数です。サンプリング間隔が小さいほど、メトリックは実際の HW 周波数に近くなります。

CPU 時間

メトリックの説明

CPU 時間とは、CPU がアプリケーションをアクティブに実行している時間です。

CPU 利用率

メトリックの説明

このメトリックは、アプリケーションの並列処理効率を評価します。これは、並列ランタイムシステムによるオーバーヘッドを除く、アプリケーション内で費やされるシステム内のすべての論理 CPU コアの比率を推測します。100% の利用率は、アプリケーションが実行中にすべての論理 CPU コアをビジーに保つことを意味します。

解析タイプに応じて、[ボトムアップ] グリッド (HPC パフォーマンス特性)、[タイムライン] ペイン、および有効な CPU 利用率分布図の [サマリー] ウィンドウに、CPU 利用率データが表示されます。

帯域幅利用率分布図

分布図では、インテル® VTune™ プロファイラーはプロセッサー利用率スケールを識別し、ターゲット CPU 利用率を計算して、プロセッサーのコア数に応じてデフォルトの利用率範囲を定義します。必要に応じて、スライドバーを調整することで利用率範囲のしきい値を変更できます。

利用率タイプ	デフォルトの色	説明
アイドル		アイドル利用率。デフォルトでは、すべてのスレッドで CPU 時間が 1 コア CPU 時間の 100% の 0.5 未満である場合、CPU 利用率はアイドルとして分類されます。式: ∑_{i=1,ThreadsCount}(CPUTime(T,i)/T) < 0.5、ここで CPUTime(T,i) はスレッド i の間隔 T での合計 CPU 時間です。
低い		低い利用率。デフォルトでは、低い利用率は同時に実行される CPU 数が、ターゲットの CPU 利用率の 50% 未満の状態です。
OK		容認 (OK) できる利用率です。デフォルトでは、OK となる利用率は同時に実行される CPU 数が、ターゲットの CPU 利用率の 51% ～ 85% の状態です。
理想的		理想的な利用率。デフォルトでは、理想的な利用率は同時に実行される CPU 数が、ターゲットの CPU 利用率の 86% ～ 100% の状態です。

インテル® VTune™ プロファイラーは、スピンとオーバーヘッドをアイドル CPU 利用率として扱います。コールスタック情報の有無により、それぞれの解析タイプでスピンとオーバーヘッド時間の認識は異なります。そのため、解析タイプごとに CPU 利用率のグラフ表示が異なることがあります。

HPC パフォーマンス特性解析では、インテル® VTune™ プロファイラーは、インテル® Xeon Phi™ プロセッサー (開発コード名 Knights Mill と Knights Landing) を除くすべてのシステムで、効率的な物理コア利用率と効率的な論理コア利用率を区別します。

インテル® Xeon Phi™ プロセッサー (開発コード名 Knights Mill と Knights Landing) やインテル® ハイパースレッディング・テクノロジー (インテル® HT テクノロジー) が無効なシステムでは、通常の効率的な CPU 利用率メトリックのみが示されます。

CPU 利用率とスレッド効率

論理的に待機している間 (スレッドがスピンしている)、CPU でスレッドコードが実行される場合、CPU 利用率はスレッド効率 (スレッド化解析で利用可能) よりも高くなります。

次の場合に CPU 利用率はスレッド効率よりも低くなります。

並列性レベルが利用可能なコア数よりも高いと (オーバーサブスクリプション)、このレベルの CPU 利用率に達するのは困難です。一般に、オーバーサブスクリプションが頻繁に発生すると、過度なコンテキスト・スイッチが生じるため、アプリケーションのパフォーマンスに悪影響を与えます。
プロファイルされたプロセスがスワップアウトされた期間がありました。そのため、論理的には待機状態ではありませんでしたが、いずれの CPU にもスケジュールされていません。

考えられる問題

このメトリックの値が低いと、負荷インバランス、スレッド化のランタイム・オーバーヘッド、競合した同期または低いスレッド/プロセスの利用により、論理 CPU コアの利用率が低い可能性を示します。MPI と OpenMP* 並列処理の効率を推測するにはCPU 利用率のサブメトリックを調査するか、スレッド解析を実行してその他の並列化ランタイムの並列処理のボトルネックを特定します。

CPU 利用率 (OpenMP*)

メトリックの説明

このメトリックは、アプリケーションが利用可能な CPU をどれだけ効率良く利用したかを表し、アプリケーションの並列効率を評価するのに役立ちます。システム上のすべての論理 CPU による平均 CPU 使用率のパーセンテージを表示します。平均 CPU 使用率には実効時間のみが含まれ、スピンやオーバーヘッドは含まれません。100% の CPU 利用率は、すべての論理 CPU にアプリケーションの計算負荷がかかっていることを意味します。

考えられる問題

0 ポート利用サイクル

メトリックの説明

このメトリックは、いずれの実行ポートでも CPU によって uOps が実行されていないサイクルの割合を表します。除算などのレイテンシーが長い命令はこのメトリックに影響します。

考えられる問題

CPU は、サイクルのかなりの部分で、いずれの実行ポートでも uOps を実行しませんでした。除算などのレイテンシーが長い命令はこの問題の原因となる可能性があります。[アセンブリー] ビューと『最適化ガイドの付録 C』をチェックして、レイテンシーが 5 サイクル以上の命令を特定します。

1 ポート利用サイクル

メトリックの説明

このメトリックは、すべての実行ポートで CPU がサイクルあたり 1 uOp 以上を実行したコアサイクルの割合を示します。これは、ソフトウェアの命令間でデータ依存性が強いか、特定のハードウェア・リソースが過剰にサブスクライブされていることが原因である可能性があります。1_Port_Utilized と L1 依存の値が高い場合、このメトリックは、必ずしも完全な実行スタベーションが原因ではない (リンクリストの検索など、短い L1 レイテンシーが原因の) L1 データキャッシュのレイテンシーのボトルネックを示します。これには、アセンブリーの調査が役立ちます。

考えられる問題

2 ポート利用サイクル

メトリックの説明

このメトリックは、すべての実行ポートで CPU がサイクルあたり 2 uOps 以上を実行したコアサイクルの割合を示します。ヒント: ループのベクトル化 - 今日のコンパイラーのほとんどは自動ベクトル化機能を備えます - 、複数の要素が同じ uOp で計算されるため実行ポートへの負荷を軽減します。

3 ポート以上の利用サイクル

メトリックの説明

このメトリックは、すべての実行ポートで CPU がサイクルあたり 3 uOps 以上を実行したコアサイクルの割合を示します。

除算器

メトリックの説明

すべての算術演算に同じ時間がかかるわけではありません。除算と平方根は DIV ユニットで実行され、整数や浮動小数点の加算、減算、または乗算よりも長い時間がかかります。このメトリックは、除算 (DIV) ユニットがアクティブであったサイクルの割合を表します。

考えられる問題

DIV ユニットが実行時間の大部分でアクティブになっています。

ヒント

レイテンシーが長いホットな操作を見つけて、それを排除するようにしてください。たとえば、定数で割る操作は、その定数の逆数の積で割り算を置き換えることを検討してください。整数を除算する場合は、右シフトへの置き換えを検討してください。

(情報) DSB カバレッジ

メトリックの説明

DSB によって供給される uOps の割合 (デコード済み ICache または uOp キャッシュと呼ばれます)。

考えられる問題

uOps のかなりの部分は DSB (デコード済み ICache または uOp キャッシュと呼ばれます) によって供給されませんでした。これは、ホットなコード領域が大きすぎて DSB に収まらない場合に発生する可能性があります。

ヒント

ホットなコード領域が DSB に収まるように、コード配置の変更を検討してください (プロファイルに基づく最適化を使用して)。

『インテル® 64 アーキテクチャーおよび IA-32 アーキテクチャー最適化リファレンス・マニュアル』の「デコード済み命令キャッシュの最適化」を参照してください。

DTLB ストア・オーバーヘッド

メトリックの説明

このメトリックは、第 1 レベルのデータ TLB ストアミスの処理に費やされたサイクルの割合を表します。通常のデータキャッシュと同様に、DTLB のオーバーヘッドを最小限に抑えるため、データの局所性を改善し、ワーキングセットのサイズを抑えることに注目します。プロファイルに基づく最適化 (PGO) を使用して、頻繁に使用されるデータを同じページに配置します。頻繁に使用される大量のデータには、ラージ・ページ・サイズを使用してみてください。

効率良い CPU 利用率

メトリックの説明

アプリケーションによって使用されている論理 CPU コアの数はいくつですか? このメトリックは、アプリケーションの並列効率を評価するのに役立ちます。これは、並列ランタイムシステムによるオーバーヘッドを除く、アプリケーション内で費やされるシステム内のすべての論理 CPU コアの比率を推測します。100% の利用率は、アプリケーションの実行中ずっと、すべての論理 CPU コアがビジーに保たれていることを意味します。

効率的な物理コア利用率

メトリックの説明

このメトリックは、アプリケーションが利用可能な物理 CPU コアをどれだけ効率良く利用したかを表し、アプリケーションの並列効率を評価するのに役立ちます。システム上のすべての物理 CPU コアによる平均利用率のパーセンテージを示します。有効な物理 CPU 利用率には実効時間のみが含まれ、スピンやオーバーヘッドは含まれません。100% の利用率は、すべての物理 CPU がアプリケーションの計算をロードしていることを意味します。

考えられる問題

このメトリックの値が低いと、次の原因で物理 CPU コアの利用率が低い可能性を示します。

ロード・インバランス
スレッドランタイムのオーバーヘッド
競合する同期
スレッド/プロセスの低い利用率
物理コアではなく論理コアを利用する誤ったアフィニティー

最新のベクトル命令セットを使用していません。最新のベクトル命令セットを生成するコンパイラー・オプションを使用して、コードを再コンパイルすることを検討してください。詳細は、『インテル® C++ または Fortran コンパイラーのユーザーおよびリファレンス・ガイド』を参照してください。

フロントエンド帯域幅

メトリックの説明

このメトリックは、命令デコーダーの非効率性や DSB (デコード済み uOps キャッシュ) キャッシュに対するコード制限など、フロントエンドの帯域幅の問題により CPU がストールしたスロットの割合を表します。このような場合、フロントエンドは通常、バックエンドに最適でない量の uOps を供給します。

フロントエンド帯域幅 DSB

メトリックの説明

このメトリックは、DSB (デコード済み uOp キャッシュ) フェッチ・パイプラインにより CPU が制限を受ける可能性があるサイクルの割合を示します。例えば、非効率な DSB キャッシュ構造の使用や、読み取り時のバンク競合がここに分類されます。

フロントエンド帯域幅 LSD

メトリックの説明

このメトリックは、CPU 操作が LSD (ループ・ストリーム・ディテクター) ユニットによって制限されていたサイクルの割合を表します。通常、LSD は良好な uOp を供給します。ただし、まれに、サイズ (uOp 数) が LSD 構造に適合しない小さなループでは、最適な uOp を供給できないことがあります。

考えられる問題

LSD (ループ・ストリーム・ディテクター) ユニットの uOps を待機するのに、かなりの数の CPU サイクルが費やされています。通常、LSD は良好な uOp 供給をサポートします。ただし、まれに、サイズ (uOp 数) が LSD 構造に適合しない小さなループでは、最適な uOp を供給できないことがあります。

フロントエンド帯域幅 MITE

メトリックの説明

このメトリックは、命令デコーダーの非効率性など、MITE フェッチ・パイプラインの問題により CPU がストールしていたサイクルの割合を表します。

フロントエンド依存

メトリックの説明

フロントエンド依存のメトリックは、プロセッサーのフロントエンドがバックエンドに供給不足となるスロットの割合を表します。フロントエンドは、バックエンドで実行される命令のフェッチを担当するプロセッサー・コアの最初の部分です。フロントエンド内では、分岐予測器が次にフェッチするアドレスを予測し、キャッシュラインがメモリー・サブシステムからフェッチされ、命令に解析され、最後にマイクロオペレーション (uOps) にデコードされます。フロントエンド依存のメトリックは、バックエンドのストールがない場合に未使用の発行スロットがあることを示します (バックエンドが uOps を受け入れることが可能であるのに、フロントエンドが uOps を供給しなかったバブル)。たとえば、命令キャッシュミスによるストールは、フロントエンド依存として分類されます。

考えられる問題

フロントエンドの問題により、パイプライン・スロットの大部分が空です。

ヒント

コードのワーキングサイズが大きすぎないこと、コードの配置が 4 つのパイプライン・スロットを満たす十分な命令を取得するのにそれほど多くのメモリーアクセスを必要としないこと、またはマイクロコード・アシストを確認します。

フロントエンドその他

メトリックの説明

このメトリックは、フロントエンドから供給されなかったスロットを考慮して、一般的なフロントエンド・ストールとしてはカウントされません。

考えられる問題

フロントエンドは、一般的なフロントエンド・ストールとして分類できないパイプライン・スロットの大部分を供給できませんでした。

分岐リステア

メトリックの説明

このメトリックは、分岐リステアにより CPU がストールしたサイクルの割合を表します。

考えられる問題

分岐リステアにより、かなりのサイクルがストールしています。分岐リステアは、あらゆる種類の分岐予測ミスに続く、補正されたパスから命令をフェッチする際のフロントエンドでの遅延を予測します。例えば、多くの予測ミスを伴う分岐が多いコードは分岐リステアに分類されます。このノードの値は、兄弟コア間で重複する可能性があることに注意してください。

DSB スイッチ

メトリックの説明

このキャッシュは DSB (デコード・ストリーム・バッファー) と呼ばれ、デコード済みの uOps を保存します。MITE (マイクロインストラクション・トランスレーション・エンジン) と呼ばれる従来のデコード・パイプラインのペナルティーの多くを回避します。ただし、DSB にキャッシュされた領域から制御フローが外部に出ると、uOps の発行が DSB から MITE に切り替わるため、フロントエンドはペナルティーを被ります。DSB スイッチメトリックはこのペナルティーを測定します。

考えられる問題

サイクルの大部分が DSB から MITE への切り替えに費やされます。これは、ホットなコード領域が大きすぎて DSB に収まらない場合に発生する可能性があります。

ヒント

ホットなコード領域が DSB に収まるように、コード配置の変更検討してください (プロファイルに基づく最適化を使用)。

詳細は、『インテル® 64 および IA-32 アーキテクチャー最適化リファレンス・マニュアル』の「デコード済み命令キャッシュの最適化」を参照してください。

命令キャッシュミス

メトリックの説明

新しい uOps をパイプラインに供給するには、コアはデコード済み命令キャッシュからそれらをフェッチするか、命令自体をメモリーからフェッチしてデコードする必要があります。後者の場合、メモリーへの要求は、直近のコードのワーキングセットをキャッシュする L1I (レベル 1 命令) キャッシュを最初に通過します。フェッチされる命令が L1I に存在しない場合、フロントエンドのストールが発生する可能性があります。原因としては、コードのワーキングセットが大きいこと、またはホットコードとコールドコード間の断片化が考えられます。後者の場合、ホット命令が L1I にフェッチされると、そのキャッシュライン上のコールドコードも一緒にフェッチされます。これは、ほかのホットなコードの排出に繋がります。

考えられる問題

命令フェッチのかなりの割合が命令キャッシュ内でミスしています。

ヒント

1.プロファイル・ガイドによる最適化を使用して、ホットコード領域のサイズを縮小します。

2.ホット関数が一緒に配置されるように関数の順序を変更するコンパイラー・オプションを検討してください。

3.アプリケーションがマクロを多用している場合、関連するマクロを関数に変換するか、リンカーのオプションを使用して重複コードを削除することで、マクロを減らすようにしてください。

4.コードのフットプリントを削減するには、Os/O1 最適化レベルまたは次の最適化のサブセットを検討してください:

インライン展開はフットプリントが減少する場合にのみ使用してください。
ループアンロールを無効にします。
組込み関数を無効にします。

ITLB オーバーヘッド

メトリックの説明

x86 アーキテクチャーでは、仮想メモリーと物理メモリー間のマッピングは、メモリー内に保持されるページテーブルによって容易に行われます。このテーブルへの参照を最小限にするため、ページテーブルの最近使用されたマッピング情報は、'トランスレーション・ルックアサイド・バッファー' (TLB) の階層にキャッシュされ、以降の仮想アドレス変換で参照されます。データキャッシュと同様に、要求が満たされるまでの距離が遠いほどパフォーマンスは低下します。このメトリックは、ITLB (命令 TLB) ミスによって発生するページウォークのパフォーマンス・ペナルティーを推測します。

考えられる問題

サイクルのかなりの割合が、命令 TLB ミスの処理に費やされています。

ヒント

1.プロファイル・ガイドによる最適化と IPO を使用して、ホットコード領域のサイズを縮小します。

2.ホット関数が一緒に配置されるように関数の順序を変更するコンパイラー・オプションを検討してください。

4.Windows* ターゲットの場合は、関数の分割も行います。

5.ラージ・コード・ページの使用を検討してください。

レングス変更プリフィクス

メトリックの説明

このメトリックは、レングス変更プレフィックス (LCP) により CPU がストールしていたサイクルの割合を表します。この問題を回避するには、適切なコンパイラー・オプションを使用します。インテル® コンパイラーはデフォルトでこのフラグを有効します。

考えられる問題

このメトリックは、レングス変更プリフィクス (LCP) により CPU がストールしていたサイクルの割合を表します。

ヒント

この問題を回避するには、適切なコンパイラー・オプションを使用します。インテル® コンパイラーはデフォルトでこのフラグを有効します。

『インテル® 64 アーキテクチャーおよび IA-32 アーキテクチャー最適化リファレンス・マニュアル』の「レングス変更プリフィクス (LCP)」を参照してください。

MS スイッチ

メトリックの説明

このメトリックは、uOp の供給をマイクロコード・シーケンサー (MS) に切り替えたことにより、CPU がストールしたサイクルの割合を表します。頻繁に使用される命令は、DSB または MITE パイプラインによる供給向けに最適化されます。特定の操作は実行パイプラインでネイティブで実行できないため、マイクロコードを実行する必要があります (実行ストリームへ投入される小さなプログラム)。MS への切り替えを頻繁に行うと、パフォーマンスに悪影響を与える可能性があります。MS は、CPUID などの CISC 命令、または非正規化数を処理する際の浮動小数点アシストなどの状況で必要な長い uOp フローを供給するように設計されています。

考えられる問題

uOps 供給をマイクロコード・シーケンサー (MS) に切り替えたことにより、サイクルの大部分がストールしています。頻繁に使用される命令は、DSB または MITE パイプラインによる供給向けに最適化されます。特定の操作は実行パイプラインでネイティブで実行できないため、マイクロコードを実行する必要があります (実行ストリームへ投入される小さなプログラム)。MS への切り替えを頻繁に行うと、パフォーマンスに悪影響を与える可能性があります。MS は、CPUID などの CISC 命令、またはデノーマル数を処理する際の浮動小数点アシストなどの状況で必要な長い uOp フローを供給するように設計されています。このメトリック値は、マイクロコード・シーケンサーの問題により強調される可能性があることに注意してください。

フロントエンドのレイテンシー

メトリックの説明

このメトリックは、命令キャッシュミス、ITLB ミス、分岐予測ミス後のフェッチストールなど、フロントエンドのレイテンシーの問題により CPU がストールしていたスロットの割合を表します。この場合、フロントエンドは uOps を供給しません。

リタイア全般

メトリックの説明

このメトリックは、CPU がマイクロコード・シーケンサー (MS) から供給されていない uOps をリタイアしていたスロットの割合を表します。これは、プログラムによって実行される命令の合計数と相関します。命令ごとの uOps 比率は 1 であると想定されます。これは上位 4 つのカテゴリーのうち最も理想的ですが、高い値は改善の余地がまだあることを示します。可能であれば、命令数を減らすか、ベクトル化などさらに効率的な命令の生成に注目してください。

ハードウェア・イベント・カウント

ハードウェア・イベント・サンプル・カウント

命令キャッシュラインのフェッチ

メトリックの説明

このメトリックは、命令キャッシュラインのフェッチによって失われたサイクルの割合を推測します。

インアクティブ待機カウント

メトリックの説明

L1I ミスやその他の問題により、コードの供給を待機するのにかなりの CPU サイクル数が費やされています。コードのワーキングセット、分岐予測ミス、仮想関数の使用を削減する方法を考えます。

割り込み時間

I/O 待機時間

メトリックの説明

このメトリックは、システムにアイドル状態のコアがある場合に、スレッドが I/O 待機状態である時間を示します。

IPC

メトリックの説明

サイクルごとにリタイアした命令数 (IPC) は、サイクルごとにリタイアした命令の平均数を示します。現代のスーパースカラー・プロセッサーはサイクルごとに最大 4 つの命令を発行し、理論上の最高 IPC は 4 になります。さまざまな要因 (大きなレイテンシーのメモリー、浮動小数点演算、SIMD 演算、分岐予測ミスによりリタイアしない命令、フロントエンドの命令スタベーションなど) により、測定される IPC の値は高くなる傾向があります。IPC =1 は、ハイパフォーマンス・コンピューティング (HPC) アプリケーションでは許容値と見なされますが、アプリケーション・ドメインごとに期待値は異なります。それでも、IPC はアプリケーションのパフォーマンス・チューニングにおいて、全体的な可能性を判断できる優れたメトリックです。

考えられる問題

IPC が非常に低くなっています。これは、メモリーのストール、命令の不足、分岐予測ミス、または長いレイテンシーの命令などによって発生する可能性があります。低い IPC の原因を特定するには、ほかのハードウェア関連のメトリックを調査します。

L1 依存

メトリックの説明

考えられる問題

このメトリックは、L1 データキャッシュにミスせずマシンがストールした頻度を示します。The L1 cache typically has the shortest latency.ただし、古いストアでブロックされているロードなど特定のケースでは、L1 に保持されているにもかかわらず、ロードのレイテンシーが長くなる可能性があります。このメトリック値は、DTLB オーバーヘッドまたは 1 ポート使用サイクルの問題により強調される可能性があることに注意してください。

4K エイリアシング

メトリックの説明

このメトリックは、4K のアドレスオフセットを持つ先行するストア (プログラム順) によって、メモリー・ロード・アクセスが発生した頻度を予測します。偽一致が発生する可能性がある場合、ロードを再発行するのに数サイクルかかることがあります。ただし、短い再発行時間は、アウトオブオーダー・コアと HW の最適化によって隠匿されることがあります。そのため、階層の親ノード (L1_Bound など) に伝搬しない限り、このメトリックが高い値を示しても安全に無視できます。

考えられる問題

サイクルのかなりの割合が、ロードとストア間の誤った 4k エイリアシングの処理に費やされます。

ヒント

[ソース/アセンブリー] ビューを使用して、エイリアシングが発生するロードとストアを特定し、エイリアシングを排除するようにデータ配置を調整します。詳細は、『インテル® 64 および IA-32 プロセッサー・アーキテクチャー最適化リファレンス・マニュアル』を参照してください。

DTLB オーバーヘッド

メトリックの説明

x86 アーキテクチャーでは、仮想メモリーと物理メモリー間のマッピングは、メモリー内に保持されるページテーブルによって容易に行われます。このテーブルへの参照を最小限にするため、ページテーブルの最近使用されたマッピング情報は、'トランスレーション・ルックアサイド・バッファー' (TLB) の階層にキャッシュされ、以降の仮想アドレス変換で参照されます。データキャッシュと同様に、要求が満たされるまでの距離が遠いほどパフォーマンスは低下します。このメトリックは、第 2 レベルのデータ TLB (STLB) のヒットと、STLB ミスでのハードウェア・ページ・ウォークの実行を含む、第 1 レベルのデータ TLB (DTLB) のミスに対するパフォーマンス・ペナルティーを予測します。

考えられる問題

サイクルのかなりの割合が、第 1 レベルのデータ TLB ミスの処理に費やされています。

ヒント

1.通常のデータキャッシュと同様に、DTLB のオーバーヘッドを最小限に抑えるため、データの局所性を改善し、ワーキングセットのサイズを抑えることに注目します。

2.プロファイルに基づく最適化 (PGO) を使用して、頻繁に使用されるデータを同じページに配置します。

3.頻繁に使用される大量のデータには、ラージ・ページ・サイズを使用してみてください。

FB フル

メトリックの説明

このメトリックは、L1D フィルバッファーが利用できないため、L1D ミス・メモリー・アクセス要求の続行が制限される頻度の概略を推測します。メトリック値が高いほど、ミスするメモリー階層レベルが深くなります。多くの場合、帯域幅の上限 (L2 キャッシュ、L3 キャッシュ、または外部メモリー) に近づいていることを示唆します。

考えられる問題

ストアフォワードでブロックされたロード

メトリックの説明

パイプライン内のメモリー操作を効率化するため、ロードが読み取るデータを、実行中の前のストアが書き込んでいる場合に、ロードはメモリーを待機する必要がなくなります (‘ストアフォワード’ プロセス)。しかし、先行するストアがロードが読み取るメモリー幅よりも小さいデータを書き込んでいる場合など状況によっては、ストアフォワードが完了するまでかなりの時間ロードがブロックされます。このメトリックは、そのようなブロックされたロードのパフォーマンス・ペナルティーを測定します。

考えられる問題

ロードは、ストアフォワード中にサイクルの大部分でブロックされました。

ヒント

[ソース/アセンブリー] ビューを使用して、ブロックされたロードを特定して、問題のあるストアフォワードを見つけます。通常ストア命令はロードの前の 10 動的命令内にあります。ストアフォワードのデータ幅がロードよりも小さい場合、ストアとロードのデータ幅を同じにします。

ロック・レイテンシー

メトリックの説明

このメトリックは、ロック操作によるキャッシュミスの処理に CPU が費やしたサイクルの割合を表します。ロックのマイクロアーキテクチャー処理のため、ロックを満たすメモリソースに関係なく、ロックは L1 依存として分類されます。

考えられる問題

CPU サイクルのかなりの割合が、ロック操作によるキャッシュミスの処理に費やされました。ロックのマイクロアーキテクチャー処理のため、ロックを満たすメモリソースに関係なく、ロックは L1 依存として分類されます。このメトリック値は、ストア・レイテンシーの問題により強調される可能性があることに注意してください。

分割ロード

メトリックの説明

メモリー階層全体で、データはキャッシュラインの粒度 (1 行あたり 64 バイト) で移動します。これは、整数、浮動小数点、倍精度などの多くの一般的なデータタイプよりもはるかに大きいですが、これらのタイプまたはその他のタイプのアライメントされていない値は 2 つのキャッシュラインにまたがる場合があります。最近のインテル® アーキテクチャーでは、キャッシュ分割を処理するため分割レジスターを導入することで、'分割ロード' のパフォーマンスが大幅に向上していますが、分割ロードが多く分割レジスターが足りない場合は、依然として分割ロードが問題になることがあります。

メトリックの説明

L2 割り当ての合計数。このメトリックは、デマンドロードと HW プリフェッチャー要求の両方を考慮します。

L2 ミス依存

メトリックの説明

L2 は、メインメモリー (DRAM) や MCDRAM 直下のメモリー階層の最後のレベルであり、レイテンシーが最も長くなります。ここでミスしたメモリー要求は、かなりのレイテンシーを伴い、ローカルまたはリモート DRAM や MCDRAM によって処理される必要があります。LLC ミス依存メトリックは、L2 ミスの処理に費やされたサイクルと合計サイクルのサイクルの比率です。L2 ミスを処理するサイクル数は、L2 CACHE MISS COST * L2 CACHE MISS COUNT として計算され、ここで L2 CACHE MISS COST は典型的な DRAM アクセス・レイテンシーのサイクル数として測定される定数です。

考えられる問題

L2 ロードミスが処理されるのを待つため、多数の CPU サイクルが費やされています。

ヒント

1.ワーキングセットのデータサイズの縮小、データアクセスの局所性の改善、L2 に収まるチャンクにータをブロッキングして使用、ハードウェア・プリフェッチャーの活用が挙げられます。

2.ソフトウェア・プリフェッチャーの使用を検討してください。ただし、通常のロードの妨げとなったり、レイテンシーの増加したりメモリーシステムの負担が増える可能性があることに注意してください。

L2 ミスカウント

メトリックの説明

L2 は、メインメモリー (DRAM) や MCDRAM 直下のメモリー階層の最後のレベルであり、レイテンシーが最も長くなります。ここでミスしたメモリー要求は、かなりのレイテンシーを伴い、ローカルまたはリモート DRAM や MCDRAM によって処理される必要があります。L2 ミスカウントのメトリックは、L2 をミスしたデマンドロードの合計数を示します。HW プリフェッチャーによるミスは含まれません。

L2 置換パーセンテージ

メトリックの説明

キャッシュラインが L2 キャッシュに取り込まれると、ラインを置き換えるため他のキャッシュラインを排出する必要があります。アクティブに使用されているキャッシュラインが排出されると、データが継続的にキャッシュに戻されるため、パフォーマンスの問題が発生する可能性があります。このメトリックは、各キャッシュラインによるすべての置換の割合を測定します。例えば、グループが '関数' に設定されている場合、このメトリックは各関数によるすべての置換の割合を示し、合計は 100% となります。

考えられる問題

これは、すべての L2 キャッシュ置換の大部分に相当します。一部の置換は避けられないものであり、高い頻度の置換は必ずしも問題の可能性を示すものではありません。特定のグループに対する大量の L2 キャッシュミスの原因を調査する場合にのみ、このメトリックを考慮します。これらの置換が問題としてマークされている場合、データ構造を再配置したり (例えば、使用頻度の低いデータを頻繁に使用されるデータから切り離して、未使用のデータがキャッシュを占有しないようにする)、排出される前に可能な限りデータを再利用するように操作の順番を変更します。

L2 置換

メトリックの説明

L2 への置換

L3 依存

メトリックの説明

このメトリックは、CPU が L3 キャッシュでストールした頻度、または兄弟コアと競合した頻度を示します。キャッシュミス (L2 ミス/L3 ヒット) を回避すると、レイテンシーが改善され、パフォーマンスが向上します。

競合アクセス

メトリックの説明

競合アクセスは、1 つのスレッドによって書き込まれたデータが別のコア上の別のスレッドによって読み取られるときに発生します。競合アクセスには、ロックなどの同期、ロック変数の変更などの真のデータ共有、フォルス・シェアリングがあります。このメトリックは、すべてのサイクルに対してキャッシュシステムが競合アクセスを処理している間に生成されたサイクルの比率です。

考えられる問題

L3 レイテンシー

メトリックの説明

このメトリックは、負荷がかかるシナリオ (L3 レイテンシーの制限による可能性) で L3 キャッシュにヒットする要求ロードアクセスのサイクル数の割合を示します。プライベート・キャッシュミス (L2 ミス/L3 ヒット) を避けることで、レイテンシーを改善し、兄弟物理コア間の競合を減らして、パフォーマンスを向上します。このノードの値は、兄弟コア間で重複する可能性があることに注意してください。

LLC ヒット

メトリックの説明

LLC (最終レベルキャッシュ) は、メインメモリー (DRAM) 直下のメモリー階層の最後のレベルであり、レイテンシーが最も長くなります。LLC ヒットは DRAM ヒットよりもはるかに高速に処理されますが、パフォーマンスを大幅に低下させる可能性があります。このメトリックには、共有データに対する一貫性のペナルティーも含まれます。

考えられる問題

メトリックの説明

特定のイベントでは、パイプライン全体をクリアし、最後にリタイアした命令の直後から再開する必要があります。このメトリックは、メモリー順序違反、自己修正コード、不正なアドレス範囲からのロードという 3 つのイベントを測定します。マシンクリアのメトリックは、マシンクリアにより CPU が無駄に消費したスロットの割合を表します。これらのスロットは、クリア前にフェッチされた uOps によって消費されるか、マシンのアウトオブオーダーが推測パスから状態を回復する必要があるときにストールします。

考えられる問題

実行時間の大部分がマシンクリアの処理に費やされています。

ヒント

具体的な原因を特定するには、MACHINE_CLEARS イベントを調べてください。詳細は、『インテル® 64 および IA-32 プロセッサー・アーキテクチャー最適化リファレンス・マニュアル』の「メモリー・ディスアンビゲーション」を参照してください。

最大 DRAM シングルパッケージ帯域幅

メトリックの説明

メトリックの説明

考えられる問題

メインメモリー (DRAM) の帯域幅限界に近づくとサイクルのかなりのがストールしました。

ヒント

導入可能な手法により、データアクセスを改善してメモリーとのキャッシュライン転送を減らします。

各キャッシュラインが排出される前に、そのすべてのバイトを消費します (たとえば、構造体の要素を並べ替え、ホットではない要素を分割します)。
計算能力が制限されたループと帯域幅が制限されたループをマージします。
複数ソケットのシステムでは NUMA 最適化を行います。

UPI 利用率依存

メトリックの説明

このメトリックは、髙い UPI 利用率で費やされたシステムの経過時間のパーセンテージを示します。帯域幅利用率の分布図を調査して、低/中/高の利用率しきい値がシステムに対して適切であること確認してください。必要に応じて、手動で調整できます。

注

UPI 利用率メトリックは、インテル® マイクロアーキテクチャー開発コード名 Skylake ベースのシステムで QPI 利用率に代わるものです。

考えられる問題

システムは UPI 帯域幅を過度に消費しました。複数ソケットシステムで NUMA 最適化によりデータアクセスを改善します。

メモリー・レイテンシー

メトリックの説明

このメトリックは、メインメモリー (DRAM) のレイテンシーにより、アプリケーションがストールする可能性があるサイクル数の割合を示します。このメトリックは、他のスレッド/コア/ソケットからの要求を集計しません (詳細は、アンコアカウンターを参照してください)。データレイアウトを最適化するか、ソフトウェア・プリフェッチ (コンパイラーによる) を使用することを検討してください。

考えられる問題

このメトリックは、メインメモリー (DRAM) のレイテンシーにより、アプリケーションがストールする可能性があるサイクル数の割合を示します。

ヒント

データレイアウトの再構築やソフトウェア・プリフェッチ (コンパイラーによる) などの手法を使用して、データアクセスを改善したり、計算とインターリーブしたりします。

ローカル DRAM

メトリックの説明

このメトリックは、ローカルメモリーからのロード時に CPU がストールした頻度を示します。キャッシュを活用することでレイテンシーが改善され、パフォーマンスが向上します。

考えられる問題

ローカルメモリーからのロード時に CPU ストール数がしきい値を超えています。レイテンシーを改善し、パフォーマンスを向上させるには、データをキャッシュすることを考慮してください。

リモートキャッシュ

メトリックの説明

このメトリックは、他のソケットのリモートキャッシュからのロード時に CPU がストールした頻度を示します。これは、不適切な NUMA 割り当てによって発生します。

考えられる問題

リモートキャッシュからのロード時に CPU ストール数がしきい値を超えています。これは多くの場合、NUMA メモリーの割り当てが最適でない場合に発生します。

リモート DRAM

メトリックの説明

このメトリックは、リモートメモリーからのロード時に CPU がストールした頻度を示します。これは、不適切な NUMA 割り当てによって発生します。

1./arch コンパイラー・オプションが適切であることを確認してください。

2.子アシストメトリックを調査して、問題としてハイライトされている場合は、提示される推奨事項に従います。

MS スイッチの問題により、このメトリック値がハイライトされる可能性があることに注意してください。

リステア予測ミス

メトリックの説明

このメトリックは、実行ステージでの分岐予測ミスの結果として、分岐リスティアによって CPU がストールしたサイクルの割合を測定します。

考えられる問題

実行ステージでの分岐予測ミスの結果として、分岐リステアによってサイクルのかなりの部分がストールする可能性があります。

MO マシンクリア・オーバーヘッド

メトリックの説明

特定のイベントでは、パイプライン全体をクリアし、最後にリタイアした命令の直後から再開する必要があります。このメトリックは、メモリー順序付けによるマシンクリアのオーバーヘッドを推測します。メモリー順序付け (MO) マシンクリアは、別のプロセッサーからのスヌープ要求がパイプライン内のデータ操作のソースと一致したときに発生します。このような状況では、進行中のロードとストアがリタイアする前にパイプラインがクリアされます。次に、パイプラインは前回リタイアした命令から再開され、1 つのコア内とコア間の両方でロードとストアのメモリー順序付けが保証されます。メモリー順序の問題は、インテル® アーキテクチャー・ベースのすべてのプロセッサーで重大なペナルティーを引き起こします。

考えられる問題

実行時間の大部分は、メモリー順序付け要求を処理するマシンクリアに費やされます。これを回避するには、ロード命令とストア命令、特に共有されるデータのロードとストアの順序を変更するか、共有要求を減らします。

MPI インバランス

メトリックの説明

メトリックの説明

メトリックの説明

並列領域時間は、すべての語彙的な並列領域のすべてのインスタンスの合計継続時間です。パーセント値は収集時間に基づきます。

ポーズ時間

メトリックの説明

ポーズ時間は、解析が GUI、CLI コマンド、またはユーザー API によって一時停止された経過時間を示します。

パーシステント・メモリー幅依存

メトリックの説明

このメトリックは、インテル® Optane™ DC パーシステント・メモリーからのロードで CPU がストールする頻度を推測します。このメトリックは、インテル® Optane™ DC パーシステント・メモリーのアプリケーション・ダイレクト・モードを備えたマシンで定義されます。

パイプライン・スロット

メトリックの説明

パイプライン・スロットは、1 つの uOp を処理するのに必要なハードウェア・リソースを表します。

トップダウン特性では、各 CPU コアごとに、各クロックサイクルで複数のパイプライン・スロットが使用可能であると想定されます。この数値はパイプライン幅と呼ばれます。

OpenMP* 潜在的なゲイン

メトリックの説明

潜在的なゲインは、実行時のオーバーヘッドがないと仮定して、OpenMP* 領域が負荷のインバランスがないように最適化されている際に節約できる最大時間を示します (並列領域時間から領域理想時間を引いた値)。潜在的なゲインが大きい場合は、領域のワークロードが十分であり、ループ・スケジュールが最適であることを確認します。

インテル® VTune™ プロファイラーは、次の方法論によりスレッド数で正規化された非効率性の合計である潜在的なゲインのメトリックを計算します。

潜在的なゲイン

考えられる問題

ロード・インバランスや並列ワークの調整に浪費される時間が大きいと、アプリケーションのパフォーマンスとスケーラビリティーに悪影響を及ぼします。最も高いメトリック値を持つ OpenMP* 領域を調査します。領域のワークロードが十分であり、ループ・スケジュールが最適であることを確認します。

インバランス

メトリックの説明

OpenMP* インバランスの潜在的なゲインは、OpenMP* 構造がバランスよく最適化された場合に節約できる最大経過時間を示します。これは、バリアでスピンしているすべての OpenMP* スレッドを OpenMP* スレッド数で割った CPU 時間のサマリーとして計算されます。

考えられる問題

並列領域内の OpenMP* バリアでの待機に時間がかかる場合、ロード・インバランスに起因する可能性があります。必要に応じて、動的ワーク・スケジュールを使用して、インバランスを軽減することを検討してください。

ロック競合

メトリックの説明

OpenMP* 潜在的なゲインロック競合は、OpenMP* ロックと順序付き同期の経過時間コストを表示します。高いメトリック値は、過度に競合する同期オブジェクトと非効率な並列処理の可能性を示します。過度な同期を避けるには、可能であればリダクション、アトミック操作、またはスレッドローカル変数を使用することを検討してください。このメトリックは、CPU サンプリング・ベースにしており、パッシブな待機は含みません。

考えられる問題

並列領域内で同期オブジェクトが使用されると、ほかのスレッドとの共有リソースへのアクセス競合を避けるため、スレッドはロックが開放されるまで CPU 時間を待機に費やします。可能な場合は、リダクション操作またはアトミック操作を使用して同期を減らすか、クリティカル・セクション内で実行されるコードの量を最小限にします。

誤った事前デコード

メトリックの説明

このメトリックは、デコーダーが誤った命令長を予測したために失われたサイクルの割合を推測します。

考えられる問題

デコーダーが誤った命令長を予測したため、かなりの数の CPU サイクルが失われました。

リモート・キャッシュ・アクセス・カウント

メトリックの説明

このメトリックは、他のソケットのリモートキャッシュによって処理された LLC ミスの合計数を示します。HW プリフェッチャーによるミスは含まれません。

リモート DRAM アクセスカウント

メトリックの説明

このメトリックは、リモートメモリーによって処理された LLC ミスの合計数を示します。HW プリフェッチャーによるミスは含まれません。

リモート / ローカル DRAM 比率

メトリックの説明

NUMA (Non-Uniform Memory Architecture) マシンでは、LLC メモリー要求ミスはローカルまたはリモート DRAM によって処理されます。リモート DRAM へのメモリー要求には、ローカル DRAM へのメモリー要求よりもはるかに長いレイテンシーが必要です。頻繁にアクセスされるデータは、できるだけローカルに保持することを推奨します。このメトリックは、リモート DRAM ロードとローカル DRAM ロードの比率によって定義されます。

メトリックの説明

シリアル CPU 時間は、収集中にマスタースレッドが OpenMP* 並列領域外でアプリケーションによって並列領域で費やされた CPU 時間です (並列領域外のシリアル時間と比較されます)。これは、アプリケーションの収集時間とスケーリングに直接影響します。値が大きい場合、コードの並列化やアルゴリズムのチューニングによって解決すべきパフォーマンスの問題を示している可能性があります。

MPI ビジー待機時間

メトリックの説明

MPI ビジー待機時間は、MPI ランタイム・ライブラリーが通信操作の待機のためスピンしている CPU 時間です。高いメトリック値は、ランク間の負荷インバランス、アクティブな通信、または MPI ライブラリーの不適切な設定による可能性があります。インテル® Trace Analyzer & Collector を使用して、非効率な通信に関する情報を調査してください。

考えられる問題

メトリックの説明

実行時間の大部分は、自己修正コードのイベントによって発生するマシンクリアの処理に費やされます。動的に変更されるコード (例えば、ターゲット修正) は、SMC によるパフォーマンスの低下につながる可能性があります。これを避けるには、間接分岐とレジスター間接呼び出しを利用してデータページ (コードページではなく) 上のデータテーブルを使用します。

サイクルごとの SP FLOP

メトリックの説明

SP GFLOPS

メトリックの説明

1 秒間に計算された単精度ギガ浮動小数点操作数。すべての倍精度操作は 2 つの単精度操作に変換されます。

スピン時間

このメトリックは、スレッド・ランタイム・ライブラリー内の未分類のオーバーヘッド時間を示します。

リダクション

メトリックの説明

リダクション時間は、ランタイム・ライブラリーがループまたは領域のリダクション操作に費やす CPU 時間です。

次のステップとして、フォルス・シェアリング解析を検討してください。

ストア・レイテンシー

メトリックの説明

このメトリックは、CPU が長いレイテンシーのストアミス (第 2 レベルキャッシュのミス) の処理に費やしたサイクルの割合を表します。

考えられる問題

このメトリックは、CPU が長いレイテンシーのストアミス (第 2 レベルキャッシュのミス) の処理に費やしたサイクルの割合を表します。不要な (または簡単にロード/計算可能な) メモリーストアを回避/削減することを検討してください。ロック・レイテンシーの問題により、このメトリック値がハイライトされる可能性があることに注意してください。

タスク時間

メトリックの説明

タスク内で費やされた合計時間。

スレッドの並行性

スレッドのオーバーサブスクリプション

メトリックの説明

スレッドのオーバー・サブスクリプションは、同時に動作するスレッド数がシステムで利用可能な論理コア数よりも多いコードで費やされた時間を示します。

考えられる問題

アプリケーションがスレッドのオーバーサブスクリプションに費やした時間がかなり長くなっています。これにより、スレッドのプリエンプションとコンテキスト・スイッチのコストが発生するため、並列パフォーマンスに影響する可能性があります。

合計反復カウント

メトリックの説明

合計ループ反復カウントの統計的予測を示します。このメトリック値は、コールスタック・フィルター・モードごとには集計されません。

[uOps]

メトリックの説明

uOp または micro-op は、低レベルのハードウェア操作です。CPU フロントエンドは、アーキテクチャーの命令を表すプログラムコードをフェッチして、それらを 1 つ以上の μOp (マイクロオペレーション) にデコードします。

VPU 利用率

メトリックの説明

このメトリックは、任意のベクトル長と任意のマスクでパックされたベクトル演算を実行したマイクロオペレーションの割合を測定します。VPU 利用率メトリックとコンパイラーのベクトル化レポートを使用して、VPU 利用率を評価し、コンパイラーがコードをどのように判断したのかを理解できます。このメトリックはロードとストアを考慮せず、ベクトル長やマスクも考慮しないことに注意してください。整数パックド SIMD が含まれます。

考えられる問題

待機カウント

メトリックの説明

待機カウントは、同期をブロックまたは引き起こす API が原因でソフトウェア・スレッドが待機する回数を測定します。

待機レート

メトリックの説明

同期コンテキスト・スイッチごとの平均待機時間 (ミリ秒単位)。メトリック値が低い場合、スレッド間の競合が増加し、システム API が効率良く使用されていないことを示す可能性があります。

考えられる問題

平均待機時間が低すぎます。これは、短いタイムアウト、スレッド間の高い競合、またはシステム同期関数の過度な呼び出しによって発生する可能性があります。呼び出しスタック、タイムライン、およびソースコードを調べて、同期コンテキスト・スイッチあたりの待機時間が短縮される原因を特定します。

待機時間

メトリックの説明

待機時間は、同期をブロックまたは引き起こす API が原因でソフトウェア・スレッドが待機しているときに発生します。待機時間はスレッドごとにあるため、合計待機時間はアプリケーションの経過時間を超える可能性があります。