第 9 章 Itanium ® 2 プロセッサ向けの最適化
10.2 パフォーマンス・モニタのプログラミング・モデル
10.2.1 作業負荷の特性評価
パフォーマンス分析の出発点は、計測される作業負荷のパフォーマンス特性を理解することであ る。このために、イベント発生率とプログラム・サイクルの内訳の2つの基本的な計測基準が用 意されている。
• イベント発生率の監視:計測可能なイベント発生率には、アプリケーション全体で計測され る、1クロック当たりの平均リタイア命令数(IPC)、データ/命令キャッシュ・ミス率、分岐 の予測ミス率などがある。オペレーティング・システムまたは大規模な市販アプリケーショ ンの特性評価(例えば、OLTP分析)を行うには、TLBミス率、VHPTウォーク/秒、割り込 み数/秒、またはバス利用率などのパフォーマンスに関連するイベントを、システム・レベル で観察する必要がある。イベント発生率の監視については、10.2.1.1項「イベント発生率の監 視」で説明する。
• サイクル・アカウンティング:作業負荷のサイクルの内訳は、プログラムによって消費された サイクルの原因ごとの内訳を示す。サイクル数の増加は、プログラム内部の実行レイテンシ 以外に、通常はパイプラインのストールおよびフラッシュによって発生する。サイクル・ア カウンティングについては、10.2.1.4項「サイクル・アカウンティング」で説明する。
10.2.1.1 イベント発生率の監視
イベント発生率の監視は、作業負荷の実行の前後にプロセッサ・イベント発生カウンタを読み 取って、監視対象のイベント発生率を計算する。例えば、Itanium 2プロセッサの2つの基本的な イベント(リタイアしたItanium命令の数をカウントするイベント(IA64_INST_RETIRED.u)と、経 過したクロック・サイクル数をカウントするイベント(CPU_CYCLES))を使用して、作業負荷の1 サイクル当たりの命令数(IPC)を次のように計算できる。
• IPC = (IA64_INST_RETIRED.ut1 - IA64_INST_RETIRED.ut0) / (CPU_CYCLESt1 - CPU_CYCLESt0) 時間ベースのサンプリングは、多くのパフォーマンス・デバッグ・ツール[VTune(TM)、gprof、
WinNT]の基礎となる。図10-1に示すように、時間ベースのサンプリングを使用して、時間とと
もに変化するイベント発生率をプロットできる。これによって、作業負荷が移行していくさまざ まな状態を推定できる。
Itaniumプロセッサ上では、多くのイベント・タイプ(例えば、TLBミスや分岐の予測ミス)の発
生回数は、1クロック・サイクル当たり1回までに制限されている。このようなイベントは、「単 一発生」イベントと呼ばれる。しかし、Itanium 2プロセッサ上では、同じタイプの複数のイベン トが同一クロック内で発生する場合がある。このようなイベントは、「複数発生」イベントと呼ば
れる。Itanium 2プロセッサの複数発生イベントの例は、データ・キャッシュ読み出しミス(1ク
ロック当たり最大2つ)である。メモリ要求キュー内のエントリ数などの複数発生イベントを使用 図 10-1. 時間ベースのサンプリング
サンプル間隔 時間 t1 t0
イベント 発生率
して、メモリ・アクセスの平均回数と平均レイテンシを計算できる。次の2つの項では、単一発 生イベントと複数発生イベントを監視するためのItanium 2プロセッサの基本的な機構を説明する。
10.2.1.2 単一発生イベントと持続時間のカウント
単一発生イベントは、Itanium 2プロセッサの任意のパフォーマンス・カウンタによって監視でき る。すべての単一発生イベントについて、それに対応するカウンタは、1クロック・サイクル当た り最大1ずつインクリメントされる。ある状態が持続するクロック・サイクル数をカウントする 持続時間カウンタは、「単一発生」イベントと見なされる。Itanium 2プロセッサの単一発生イベン トの例としては、TLBミス、分岐の予測ミス、サイクルベースの評価基準などがある。
10.2.1.3 複数発生イベント、スレッショルド、平均計算
ハードウェアの並列性のために、1クロック・サイクル当たり2つ以上発生する可能性があるイベ ントは、「複数発生」イベントと呼ばれる。Itanium 2プロセッサの複数発生イベントの例には、リ タイアした命令数や、メモリ要求キュー内の有効エントリ数などがある。
スレッショルド機能は、Itanium 2プロセッサの複数発生カウンタ内で使用できる。この機能を使 用して、イベント分布ヒストグラムをプロットできる。ゼロでないスレッショルドが指定されて いる場合は、検出されたイベント数が設定されたスレッショルドを超えたサイクルごとに、モニ タが1ずつインクリメントされる。これによって、「メモリ要求キュー内に3つ以上のエントリが 入っていたサイクルの数は?」または「マシンが4つ以上の命令をリタイアさせたサイクルの数は
?」などの問いに答えられる。この機能は、マイクロアーキテクチャ上のバッファ・サイズのテス トを、実際の計測値によって支援できる。さまざまなスレッショルド値を指定してベンチマーク を実行すると、あるバッファ・サイズでのパフォーマンスを特定するヒストグラムを作成できる。
未処理のメモリ操作など、重複する同時イベントは、同時に未処理になっている要求の平均数と、
要求が未処理になっている期間の平均サイクル数が問題になる。メモリ・キュー内の複数の未処 理の要求の平均数または平均レイテンシを計算するには、要求の合計回数(ntotal)と、1サイクル当 たりの有効な要求の数(nlive/cycle)がわかっていなければならない。複数発生カウンタを使用して 有効な要求の数(nlive/cycle)を合計すると、∑nliveはハードウェアによって直接計測される。要求 の平均数と平均レイテンシを次のように計算できる。
• 1サイクル当たりの未処理の要求の平均数 = ∑nlive / ∆t
• 要求1回当たりの平均レイテンシ = ∑nlive / ntotal
表10-1に、この計算の例を示す。この表では、1サイクル当たりの未処理の要求の平均数 = 15/8 = 1.825、要求1回当たりの平均レイテンシ = 15/5 = 3サイクルである。
Itanium 2プロセッサは、イベント発生率を監視するための以下の機能を搭載している。
• クロック・サイクル・カウンタ
• リタイア命令カウンタ
• イベント発生カウンタおよび持続時間カウンタ
表 10-1. 要求1回当たりの平均レイテンシと1サイクル当たりの要求数の計算例
時間[サイクル] 1 2 3 4 5 6 7 8
要求数(In) 1 1 1 1 1 0 0 0
要求数(Out) 0 0 0 1 1 1 1 1
nlive 1 2 3 3 3 2 1 0
∑nlive 1 3 6 9 12 14 15 15
ntotal 1 2 3 4 5 5 5 5
• スレッショルド機能付き複数発生カウンタ
10.2.1.4 サイクル・アカウンティング
イベント発生率の監視では、イベントの数をカウントするが、検出されたイベントがパフォーマ ンスに影響を与えているかどうかはわからない。よく使用される手法は、複数のイベント発生率 をプロットし、1サイクル当たりの命令数(IPC)の計測値に関連付ける方法である。キャッシュ・
ミス動作のピークと同時にIPCの値が低下している場合は、キャッシュ・ミスがパフォーマンス 上の問題の原因であると推定される。このような推定作業を不要にするために、Itanium 2プロ セッサは、一連のサイクル・アカウンティング・モニタを搭載しており、各種のマイクロアーキ テクチャ上のイベントによって失われたサイクル数の内訳を調べられる。図10-2に示すように、
この機能は、プログラムによって消費されたサイクルの内訳を示すため、アプリケーションのマ イクロアーキテクチャ上の動作を推定できる。ただし、サイクル・アカウンティングは、単なる ストールまたはフラッシュの持続時間のカウントとは異なる。サイクル・アカウンティングは、
マシンの実際のストール/フラッシュ状態に基づいて、重複したパイプラインの遅延の原因を示 す。単なるストールやフラッシュの持続時間カウンタは、このような機能を持っていない。サイ クル・アカウンティングは、ストールとフラッシュを原因とするプログラムのサイクルの内訳を 調べられる。単なる持続時間カウンタは、ストールまたはフラッシュの累積レイテンシを計算す るときに便利である。
Itanium 2プロセッサのサイクル・アカウンティング・モニタを利用すると、シングルサイクル、
マルチサイクルのいずれについても、ストールとフラッシュを引き起こした条件の主要なものを すべて知ることができる。ストール条件とフラッシュ条件が同時に生じた場合は、パイプライン の並び順とは逆の順序で優先順位が付けられる。すなわち、パイプラインの後段側に近いほうの ものがその原因として報告される。バックエンド・ストールとフラッシュの発生原因は6つある が、その優先順位は次のとおりである。
1. 例外/割り込みサイクル:割り込みおよび例外が原因のパイプのフラッシュに費やされるサイ クル数
2. 分岐の予測ミス・サイクル:分岐の予測ミスが原因のパイプのフラッシュに費やされるサイク ル数
3. データ/FPUアクセス・サイクル:メモリ・パイプライン・フル、データTLB ストール、load-useストール、浮動小数点ユニットへのアクセス
4. 実行レイテンシ・サイクル:スコアボード・ストールおよびその他のレジスタ依存性ストール 5. RSE実行サイクル: RSEによるスピル/フィル・ストール
6. フロントエンド・ストール:フロントエンド上で待機しているバックエンドが原因のストール フロントエンド・ストールの発生には7つの原因が考えられるが、そうした原因が詳しくわかる フロントエンド・ストール・カウンタもさらに用意されている。ただし、バックエンド・ストー ル・イベントとフロントエンド・ストール・イベントは、それぞれ別のパイプライン・ステージ でカウントされるため、比較するべきではない。
詳細は、11.6節「ストール・イベント」を参照のこと。
図 10-2. Itanium®プロセッサ・ファミリのサイクル・アカウンティング
001229
30% 25%
100% Execution Time Inherent Program
Execution Latency
Data Access Cycles
Branch Mispredicts
I Fetch
Stalls Other Stalls
20% 15% 10%
プログラム固有の 実行レイテンシ
データ・アクセス・
サイクル 分岐の その他のストール
予測ミス
Iフェチ・
ストール
100％実行時間