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

アシスト

メトリックの説明

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

考えられる問題

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

ヒント:

メトリックの説明

バックエンド依存のメトリックは、バックエンドで新しい 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 が無駄にしたスロットの割合を表します。これらのスロットは、誤って推測されたプログラムの実行パスからフェッチされた uOp によって浪費されるか、マシンのアウトオブオーダー機能が投機的なパスから状態をリカバリーする場合にストールします。

考えられる問題

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

ヒント

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

2.コンパイラーのプロファイルに基づく最適化を使用します。

詳細は、『インテル® 64 および IA-32 プロセッサー・アーキテクチャー最適化リファレンス・マニュアル』の「サイクルのドリルダウンと分岐予測ミス」を参照してください。

バスロック

メトリックの説明

インテル® プロセッサーは、クリティカルなメモリー操作の間システムバスや同等なリンクをロックするため自動的にアサートされる LOCK# シグナルを備えています。この出力シグナルがアサートされていると、ほかのプロセッサーやバス・エージェントからのバス制御要求はブロックされます。このメトリックは、バス上に LOCK# シグナルがアサートされている間のバスサイクル比率を測定します。キャッシュ不可なメモリーによるロックされたメモリーアクセス、2 つのキャッシュラインにまたがるロックされた操作、およびキャッシュ不可なページテーブルからのページウォークがある場合、LOCK# シグナルがアサートされます。

考えられる問題

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

ヒント

[ソース/アセンブリー] ビューの 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) は、各命令の実行にかかったおおよその時間を示す基本的なパフォーマンス・メトリックです (単位はサイクル数)。最近のスーパースカラー・プロセッサーは、1 サイクルあたり 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 値は、長いレイテンシーのメモリー、浮動小数点操作、分岐予測ミスによるリタイアしない命令、またはフロントエンドでの命令スタベーションなど軽減可能なシステム内のレイテンシーを示します。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 uOps を実行したサイクルの割合を示します。これは、ソフトウェア命令間のデータ依存関係が顕著であることや、特定のハードウェア・リソースのオーバーサブスクライブが原因である可能性があります。1_Port_Utilized と L1 依存の値が高い場合、このメトリックは、必ずしも完全な実行スタベーションが原因ではない (リンクリストの検索など、短い L1 レイテンシーが原因の) L1 データキャッシュのレイテンシーのボトルネックを示します。これには、アセンブリーの調査が役立ちます。

考えられる問題

2 ポート利用サイクル

メトリックの説明

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

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

メトリックの説明

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

除算器

メトリックの説明

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

考えられる問題

実行時間のかなりの部分で DIV ユニットがアクティブです。

ヒント

ホットな長いレイテンシー操作を検出して、排除を試みます。例えば、定数による除算は、定数の逆数の積で置き換えることを検討してください。整数除算である場合、シフトの使用を検討してください。

(情報) DSB の適用

メトリックの説明

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

考えられる問題

ほとんどの uOps は DSB (デコード済み命令キャッシュ、または uOp キャッシュと呼ばれる) から供給されていません。これは、ホットなコード領域が DSB に収まらないほど大きな場合に発生します。

ヒント

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

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

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

メトリックの説明

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

効率良い CPU 利用率

メトリックの説明

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

効率的な物理コア利用率

メトリックの説明

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

考えられる問題

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

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

最新のベクトル命令セットを使用していません。最新のベクトル命令セットを使用するようにコンパイラー・オプションを変更して、コードを再コンパイルすることを検討してください。C++ と Fortran の詳細な情報については、コンパイラーのユーザー・リファレンス・ガイドを参照してください。

フロントエンド帯域幅

メトリックの説明

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

フロントエンド帯域幅 DSB

メトリックの説明

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

フロントエンド帯域幅 LSD

メトリックの説明

このメトリックは、CPU の動作が LSD (ループストリーム検出器) ユニットによって制限されたサイクル数の割合を示します。一般に、LSD の uOp 供給は良好です。しかし、まれに LSD 構造に適していない小さなサイズ (uOps 数) のループでは、適切に uOp が供給されないことがあります。

考えられる問題

CPU のかなりのサイクルが、LSD (ループストリーム検出器) ユニットの uOps を待機するのに費やされました。一般に、LSD の uOp 供給は良好です。しかし、まれに LSD 構造に適していない小さなサイズ (uOps 数) のループでは、適切に uOp が供給されないことがあります。

フロントエンド帯域幅 MITE

メトリックの説明

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

フロントエンド依存

メトリックの説明

フロントエンド依存のメトリックは、プロセッサーのフロントエンドがバックエンドを下回るスロットの割合を表します。フロントエンドは、バックエンドで実行される命令のフェッチを担当するプロセッサー・コアの最初の部分です。フロントエンド内部で、分岐予測器がフェッチする次のアドレスを予測し、キャッシュラインがメモリー・サブシステムからフェッチされ、命令に解読され、最後にマイクロオペレーション (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.ホットな関数が一緒に配置されるよう、関数を再配置するコンパイラー・オプションを使用してください。

3.アプリケーションがマクロを多用している場合、関数に変換するかリンカーオプションを使用して繰り返し実行されるコードを排除します。

4.Windows* ターゲットでは、関数分割を追加します。

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

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

メトリックの説明

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

考えられる問題

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

ヒント

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

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

MS スイッチ

メトリックの説明

このメトリックは、uOps 供給をマイクロコード・シーケンサー (MS) に切り替えたことにより、CPU がストールしたサイクルの割合を示します。一般的な命令は、DSB または MITE パイプラインによる供給向けに最適化されています。特定の操作は実行パイプラインで直接実行できないため、マイクロコードで実行する必要があります (小さなプログラムを実行ストリームへ投入します)。頻繁に MS に切り替わるとパフォーマンスに悪影響を与えます。MS は、CPIUD のような CISC 命令によって要求される長い uOp フロー、またはデノーマル値を扱う浮動小数点アシストなどの特殊な条件で供給されます。

考えられる問題

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

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

メトリックの説明

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

リタイア全般

メトリックの説明

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

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

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

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

メトリックの説明

このメトリックは、命令キャシュラインのフェッチによる損失サイクルの割合を予測します。

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

メトリックの説明

L1I ミスやその他の問題が原因でコードが供給されるのを待機するため、多くの CPU サイクルが消費されています。コードのワーキングセット、分岐予測ミス、および仮想関数の使用を減らす方法を検討します。

割り込み時間

このメトリックは、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 依存として分類されます。このメトリック値は、ストア・レイテンシーの問題によりハイライトされる可能性があることに注意してください。

分割ロード

メトリックの説明

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

メトリックの説明

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

L2 ミス依存

メトリックの説明

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

考えられる問題

L2 ロードミスが処理されるのを待機するには、高い CPU サイクル数が費やされます。

ヒント

1.データのワーキングセットを縮小し、データのアクセス局所性を向上させて L2 に収まるようにチャンク内のデータをブロック化して参照するか、ハードウェア・プリフェッチャーを効率良く活用します。

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

L2 ミスカウント

メトリックの説明

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

L2 置換比率

メトリックの説明

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

考えられる問題

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

L2 置換

このメトリックは、すべての要求タイプと両方のハードウェア SMT スレッドを考慮して、スーパーキュー (SQ) が一杯になったサイクルの割合を測定します。スーパーキューは、L2 キャッシュへのアクセス要求、またはアンコアへの要求に使用されます。

リモート DRAM によって処理された LLC ロードミス

メトリックの説明

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

考えられる問題

リモート DRAM からのメモリー要求の処理には、かなりの時間がかかります。可能であれば、同一コア、または少なくとも同じパッケージに割り当てられているデータを使用するようにしてください。

LLC ミスカウント

メトリックの説明

LLC (最終レベルキャッシュ) は、メインメモリー (DRAM) の手前にある、メモリー階層の最後の、そして最も長いレイテンシーのレベルです。すべての LLC メモリー要求ミスは、レイテンシーの長いローカルまたはリモート DRAM によって処理されます。LLC ミスカウントのメトリックは、LLC ミスした要求ロードの合計数を示します。HW プリフェッチャーによるミスは含まれません。

LLC 置換比率

メトリックの説明

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

メトリックの説明

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

考えられる問題

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

ヒント

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) マシンクリアは、別のプロセッサーからのスヌープ要求が、パイプライン内のデータ操作のソースと一致した場合にも発生します。この場合、進行中のロードやストアがリタイアする前にパイプラインはクリアされます。その後、パイプラインは直前にリタイアした命令から再開され、コア内またはコア間で、ロードやストアのメモリー順序付けを維持します。メモリー順序付けの問題は、インテル® アーキテクチャー・ベースのすべてのプロセッサーで深刻なペナルティーを引き起こします。

考えられる問題

実行時間の大部分が、メモリー順序付けを処理するためマシンクリアに費やされています。これを避けるには、ロードとストア命令 (特にロードとストアがデータを共有する場合) を並べ替えるか、共有要件を減らします。

MPI の負荷インバランス

メトリックの説明

メトリックの説明

メトリックの説明

並列領域時間は、すべての並列構造領域のすべてのインスタンスの合計持続期間です。収集時間をベースとしたパーセント値で表されます。

ポーズ時間

メトリックの説明

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

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

メトリックの説明

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

パイプライン・スロット

メトリックの説明

パイプライン・スロットは、1 つのマイクロオペレーションを操作するために必要なハードウェア・リソースを表します。

トップダウン特性化では、それぞれの 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 時間です。

フォルス・シェアリング解析を行うことを検討してください。

ストア・レイテンシー

メトリックの説明

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

考えられる問題

長いレイテンシーのストアミス (L2 キャッシュミス) の処理に、かなりの CPU サイクルが費やされています。必要のない (または容易にロード/計算できる) メモリーストアを回避するか減らしてください。このメトリック値は、ロック・レイテンシーの問題によりハイライトされる可能性があることに注意してください。

タスク時間

メトリックの説明

タスク内で費やされた合計時間を示します。

スレッドの並行性

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

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

考えられる問題

アプリケーションの多くの時間がスレッドのオーバーヘッドで費やされています。これは、スレッドのプリエンプションおよびコンテキスト・スイッチのコストにより、並列パフォーマンスに悪影響を与えます。

反復カウントの合計
メトリックの説明

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

uOps
メトリックの説明

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

VPU 利用率
メトリックの説明

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

考えられる問題

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

待機カウント
メトリックの説明

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

待機レート
メトリックの説明

同期コンテキスト・スイッチごとの平均待機時間 (ミリ秒) を示します。低いメトリック値は、スレッド間の競合の増加とシステム API の非効率な利用を示します。

考えられる問題

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

待機時間
メトリックの説明

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