IntelR ItaniumR プロセッサ ファミリ パフォーマンス

Intel® Itanium®プロセッサ ファミリ パフォーマンス
チューニング ガイド
White paper
目次
はじめに ................................................................................................................................................... 3
アーキテクチャの概要 ................................................................................................................................. 3
性能を向上するためのプロセッサ機能 ....................................................................................................... 3
メモリ階層 ............................................................................................................................................. 6
L1 キャッシュ ...................................................................................................................................... 7
L2 キャッシュ ...................................................................................................................................... 7
L3 キャッシュ ...................................................................................................................................... 8
メモリ サブシステム ............................................................................................................................. 8
TLB（Translation lookaside buffer： 変換索引バッファ） ............................................................................... 9
Intel Itanium 2 プロセッサ用のチューニング .................................................................................................... 9
一般的なチューニング手順....................................................................................................................... 9
Intel Itanium 2 プロセッサ用のコード構成 ..................................................................................................... 10
キャッシュの有効利用 ........................................................................................................................... 10
L1I キャッシュ ................................................................................................................................... 10
L1D キャッシュ.................................................................................................................................. 10
L2 キャッシュ .................................................................................................................................... 10
L3 キャッシュ .................................................................................................................................... 10
効果的なデータ プリフェッチ ................................................................................................................... 11
効果的な命令スケジューリング ............................................................................................................... 12
Intel Itanium プロセッサの PMU (Performance Monitoring Unit)........................................................................ 13
アプリケーション プロファイル.................................................................................................................. 14
性能を向上するための 10 のヒント ...................................................................................................... 14
HP-UX のツール チェーン ........................................................................................................................... 16
コンパイラ............................................................................................................................................ 16
パフォーマンス ツール ........................................................................................................................... 17
Prospect .......................................................................................................................................... 17
Caliper ........................................................................................................................................... 17
パフォーマンス ライブラリ ....................................................................................................................... 17
VML................................................................................................................................................ 17
HP の MLIB ...................................................................................................................................... 18
まとめ..................................................................................................................................................... 19
付録 A： Prospect の使用例........................................................................................................................ 20
付録 B： Prospect と Caliper によるチューニング ............................................................................................ 25
付録 C： 参考情報ガイド ............................................................................................................................ 27
HP-UX 11i のリリース名とリリース ID........................................................................................................ 27
はじめに
この文書の目的は、Intel® Itanium® 2 プロセッサの優れた機能とその活用方法をソフトウェア開発者に説明することです。
Intel Itanium アーキテクチャの共同開発者および Itanium ベース システムの主導的開発者として、HP はこのプロセッサ
とシステム アーキテクチャについて比類のない知識を所有しています。また HP には、Itanium ベース システム用のアプ
リケーションを移植／チューニングした貴重な実績があります。
この文書では、HP-UX 11i を実行する Itanium 2 プロセッサの潜在的性能を実現するための手法とツールについても説
明します。ほとんどのチューニング手法とツールの一部は、Itanium 2 プロセッサ上で実行される別の OS（オペレーティ
ング システム）にも利用できます。
高性能ソフトウェアの開発と最適化を行うには、プロセッサとメモリのアーキテクチャを詳しく理解する必要があります。
これらのテーマについては、簡単に説明します。これらのテーマに関する詳細は、この文書の本文と付録 C のリソース
ガイドに記載されています。
アプリケーションの基本的特性によって、チューニング結果が大きく異なることがあります。性能が 10 倍も向上すること
もあります。少ししか向上しないこともあります。アプリケーションごとにその程度を予測することはできません。
尚、本書が提供するコンテンツは Itanium 2 プロセッサ (Mckinley) をベースとするものです。
アーキテクチャの概要
性能を向上するためのプロセッサ機能
Intel Itanium プロセッサ ファミリの基礎は、HP 研究所で開発された EPIC（Explicitly Parallel Instruction Computing： 明
示的並列命令コンピューティング技術）です。EPIC アーキテクチャは、RISC アーキテクチャの限界を打ち破るプロセッ
サを実現する画期的な技術です。EPIC アーキテクチャによって、コンパイラが現在の OOO (Out of Order) RISC 設計
の限界を超えるパラレル実行を利用できるようになります。
設計者がこれまでにない大きなリオーダー バッファと関連制御論理を実装するにつれて、OOO RISC 設計は著しく複
雑になっています。この問題に対処するために EPIC では、複雑さの処理をコンパイラに組み込み、メモリ競合解消の
ためにより単純なハードウェア サポートを備えるという手法を採用しています。Intel Itanium アーキテクチャでは、高性
能を実現するために次のような多くの新機能が導入されています。
大きなレジスタ ファイル： Intel Itanium アーキテクチャには、128 個の整数レジスタが備わっています。そのうち、32 個
は固定レジスタで、96 個は「スタック」レジスタです。1 回のプロシージャ コールで最大 96 個の「スタック」レジスタを割
り当てることができ、さらに 32 個の共通レジスタにもアクセスできます。各プロシージャには固有のレジスタ フレームが
あり、そのサイズは自由に変更できます。ほとんどのプロシージャ コールには少数の新しいレジスタだけが割り当てら
れるので、レジスタ ファイルの物理的限界を超える前に多くのコールを実行できます。RSE（Register Stack Engine： レ
ジスタ スタック エンジン）という専用ハードウェアは、古いレジスタを素早く自動的にメモリに書き出すので、新しい要求
に使用できる空きをレジスタ スタックに確保できます。また必要に応じて、RSE は書き出した値をメモリからレジスタへと復
元します。一般的なアプリケーションでは、RSE を実行するプロセッサ サイクルのうち数パーセントだけを利用します。
通常の関数呼び出しの実行には数サイクルだけが必要です。
3
汎用
NAT
浮動小数点
プレディ
ケーション
分岐
非回転レジスタ
回転レジスタ
機能ユニット： Intel Itanium 2 プロセッサは、サイクルごとに最大 6 つの命令を実行するように設計されています。11
個の命令発行ポートをサポートするために十分な発行制御機能とデータ パスも備わっています。1 つのバンドルに 3
つの命令がまとめられます。6 個の発行ポートで十分とも考えられますが、発行ポートが 11 個あると、一部を特定機
能専用に使うことができるため、ディスパーサル効率が向上します。ディスパーサルとは、命令発行ポートを通して各
機能ユニットに命令を分配することです。発行ポートは、4 個のメモリ／ALU ポート、2 個の整数／ALU ポート、2 個の浮
動小数点ポート、3 個の分岐ポートに分類されます。アセンブリ コードを記述する場合は、どのポートがどの用途専用
かを知っておくことが重要です。この情報を無視すると、機能停止（パイプラインのストール）が発生する可能性があり
ます。この情報は、Intel Itanium 2 Processor Reference Manual for Software Development and Optimization に記載
されています。Itanium2 は、1 サイクルあたり最大 2 つのバンドルを同時にディスパーサルすることができます。
ソフトウェア パイプライニング： 従来のアーキテクチャでは、ループ実行に関連するレイテンシを隠蔽するためにループ
のアンロールが使われています。Intel Itanium アーキテクチャではソフトウェア パイプライニングを採用しており、コード
の増大を防止しオーバーヘッドを低減しつつ、同じ目的を実現することができます。ソフトウェア パイプライニングという
用語は、1 回のループ繰り返しを最低限のサイクル数で実現するループ スケジューリングを可能にする一連の機能を
表します。ループ スケジューリングは、ループをパイプライン処理するためのプレディケーションとともにレジスタ回転を
利用して実現されます。ループが繰り返されるたびに、回転レジスタ内のデータが次のレジスタに移動します。次の例
を考えてみましょう。
4
DAXPY (Double-precision A times X Plus Y) 内側ループ：
for (i=0;i<4;i++)
y[i]=y[i]+(a*x[i]);
プロセッサが 1 サイクルで 2 つのロード、1 つの FMA (floating point multiply-accumulate)、および 1 つのストアを実行
でき、ロードレイテンシが 2 サイクル、FMA レイテンシが 1 サイクルと仮定します。この場合、パイプライン処理されたル
ープは次のようになります。
ロード
ストア
このループでは 4 サイクルを完了する必要があるため、完全にパイプライン処理された実装方式では、4 セットのレジ
スタが必要になります。パイプラインが充填されると、サイクルごとに 1 回のループ繰り返しが完了します。ロード／スト
アのレイテンシが長くなると、レイテンシを隠すためにより多くのレジスタが必要になります。ここでは示していませんが、
プレディケーションを利用してループの最初の部分と最後の部分を制御できます。このため、これらの段階で別のコー
ドを使う必要がなくなります。
プレディケーションと投機的実行： 従来の RISC および CISC アーキテクチャでは、コード分岐によって性能が大きな制
限を受けています。分岐予測を誤ると、実行パイプラインがフラッシュし、適切な分岐に対する命令とデータがロードさ
れるまで機能が停止します。非常に高い精度で多くの分岐を予測できますが、分岐予測がはずれた場合には、数百サ
イクルの間、プロセッサが機能停止します。プレディケーションと制御投機的実行を採用した Intel Itanium プロセッサで
は、この問題を回避できます。プレディケーションによって、分岐の両側を実行できるようになります。その後で、無効な
側からの結果が廃棄されます。たとえば、これはコンパイラによって次のように表現することができます。
if(ix .eq. iy) then
a = 0
else
b = 0
Cmp.eq p6,p7 = r16,r17;;
(p6) fadd.d f4 = f0,f0
(p7) fadd.d f5 = f0,f0
この３つの命令を、3 つのバンドルに対応付けることもできますし、1 つのバンドルに対応付けることもできます。いずれ
の場合も実行に２サイクルを要します。その理由は、比較命令の最後の文字";;"で「ストップ ビット」が指定されている
からです。同一バンドル内にある・ないに関わらず、ストップビットより後の命令は、それ以前の命令と同じサイクルで
はディスパーサルされません。上記の例では、2 番目と 3 番目の命令の実行に 1 番目の比較命令の結果が必要なた
め、比較命令の後にストップビットが指定されています。比較結果に応じてプレディケート レジスタ p6 と p7 が設定され、
f4 と f5 の結果の妥当性がプレディケート レジスタによって判断されます。無効な結果は無視されます。
制御投機的実行によってロードを分岐の上に上げることができるため、分岐の両側での実行が可能になります。ロード
を検証するチェック命令が分岐の後に挿入されます。
5
Intel Itanium アーキテクチャは、データ投機的実行もサポートしています。このため、Intel Itanium プロセッサは正しくな
いロード／ストア依存関係を避けることができます。つまり、ストアと競合する可能性があるロードをストアの上に上げ
ることができます。ロードを検証するチェック命令が、再びロードの元の場所に配置されます。データ投機的実行によっ
てソフトウェア開発者がポインタ エイリアシングを完全に忘れることができるように思われるかもしれませんが、そうは
いきません。投機的実行のサポートに利用できるリソースの数は限られているため、コンパイラで最適化できる余地は
少なくなります。それでも、性能を左右するコードでアドレス エイリアシングを避けることにより、性能が大幅に向上しま
す。
上記の機能とその他の機能の詳細については、Intel Itanium 2 Processor Reference Manual for Software Development
and Optimization を参照してください。
メモリ階層
現代のシステム アーキテクチャの設計で最も重要な課題は、タイミングよくプロセッサにデータを送ることです。プロセ
ッサ速度とメモリ速度に大きな差がある場合、システム設計者がこの課題を達成することはほぼ不可能です。コンパイ
ラやアプリケーションを作成するソフトウェア設計者は、この差を補う必要があります。プロセッサ設計のこの点を無視
すると、良好な性能が得られないことがあります。最良の性能を実現するには、キャッシュ階層に関する知識が必要で
す。
Intel Itanium 2 プロセッサには、3 レベルのオンチップ キャッシュ階層があります。この階層によって、プロセッサに最も
近いキャッシュから多数の命令を迅速に実行できます。最高の性能を実現するには、効果的なプリフェッチングも必要
です。
6
McKinley 3 レベル キャッシュ構成
L1
ロード タグ
L1
データ キャッシュ
M0 データ
M1 データ
整数
レジスタ
ファイル
L3 タグ
データ
L2 タグ
メモリ ポート
L1 ストア タグ
L3
統合
キャッシュ
メモリへ
L2
統合キャッシュ
浮動小数点
レジスタ
ファイル
L1 キャッシュ
L1 キャッシュは、命令キャッシュ (L1I) とデータ キャッシュ (L1D) に分けられます。両方とも 16 KB の 4-way アソシエイ
トキャッシュであり、ライン サイズは 64 バイト、レイテンシは 1 サイクルです。命令キャッシュには 2 個のポートがあり、
2 サイクルごとに 64 バイトのラインを充填できます。これによって、サイクルごとに 2 バンドルのフェッチ レート（プロセ
ッサの命令発行率）が可能になります。このキャッシュはオンデマンド フェッチ ミスを遮断しますが、プリフェッチ ミスは
遮断しません。置換方針は LRU（Least Recently Used： 最低使用頻度）です。
ソフトウェアによる命令プリフェッチ制御をサポートするために、Intel Itanium 2 プロセッサには L1I キャッシュと L2 キャッ
シュの間に ISB（Instruction Stream Buffer： 命令ストリーム バッファ）が配置されています。ISB はライン充填バッファとし
て機能し、64 バイトのキャッシュ ラインが 8 つ含まれています。ISB は完全なアソシエイトバッファであり、読み取りと充
填の同時実行をサポートします。L2 から返される L1I キャッシュ ラインはすべて ISB を通過します。要求ミスは、命令パ
イプラインに転送されます。ISB と L1I キャッシュは同時にアクセスされ、レイテンシも同じです。両方でヒットが発生する
と、ISB 内の一致するラインが無効になります。
このデータ キャッシュは、整数データのみサポートします。このキャッシュには 4 個のポートがあり、同時に 2 回の読み
取りと 2 回の書き込みがサポートされます。両方のデータ パスは、2×64 ビットです。置換方針は NRU（not recently
used： 最近未使用度）です。プロセッサは、サイクルごとに最大 2 回のダブル ワードのロードを要求できます。これは、
レジスタ ファイルへの L1D 充填レートと正確に一致します。L1D キャッシュでロード ミスが生じると、そのロードは L2 キ
ャッシュに転送されます。L1D キャッシュは、L2 キャッシュに対する未処理充填要求を最大 8 つサポートします。それを
超えるミスは L2 キャッシュに転送されますが、処理時に L1D キャッシュに充填されることはありません。
L1D キャッシュではライトスルー設計が採用されているため、ストア要求はすべて L2 キャッシュに渡されます。L1D キャッ
シュでストアが失敗しても、このキャッシュは影響を受けません。L1D キャッシュでヒットが発生すると、そのデータが L1D
データ配列で更新されます。この設計で発生する可能性がある競合を最低限に抑えるために、各種のキューと制御論
理が備えられています。
L2 キャッシュ
L2 キャッシュは、256 KB の命令／データ統合キャッシュです。また、このキャッシュに対して浮動小数点データのロー
ド／ストアが行われます。L2 は 8-way アソシエイトキャッシュであり、ライン サイズは 128 バイト、バンク数は 16 です。
レイテンシは、整数ロードでの最低 5 サイクルから命令ロードでの最大 11 サイクル（特殊なケースでは 11 サイクルを
超えます）まで、処理によって異なります。
L2 キャッシュは、浮動小数点レジスタ ファイルへの浮動小数点データのストリーミングを完全にサポートするように設計
されています。L2 キャッシュから浮動小数点レジスタ ファイルに、サイクルごとに 4 つのメモリロードを実行できます。こ
7
のため、サイクルごとに 2 回の浮動小数点演算が完全にサポートされます。これは、FMA (Fused Multiply Accumulate)
演算を使った場合の 4 FLOPS/サイクルに相当します。
L3 キャッシュ
L3 キャッシュのサイズは、システムに応じて 1.5∼3 MB です。900 MHz のシステムでは 1.5 MB、1 GHz のシステム
では 3 MB です。L3 キャッシュは統合キャッシュでもあります。3 MB システムは 12-way アソシエイトキャッシュであり、
ライン サイズは 128 バイト、バンク数は 1 です。1.5 MB システムは、6-way アソシエイトキャッシュです。このキャッシ
ュのレイテンシは、整数ミスでの 12 サイクルから命令ミスでの 18 サイクルまで異なります。
レイテンシ
Itanium 2 プロセッサ
L1I/L1D
1 サイクル
L2 (I, FP)
5、6 サイクル
L3 (I, FP)
12、13 サイクル
L2 キャッシュへの読み取りデータ パスと書き込みデータ パスは分離されており、それぞれのパスがサイクルごとに 32
バイトの転送をサポートします。
メモリ サブシステム
HP の Itanium 2 ベース の 2-way/4-way のシステムにはすべて、HP スケーラブル プロセッサ チップセット zx1 が搭載さ
れています。zx1 チップセットは、プロセッサ、メモリ、および I/O 間の高帯域幅接続を低コスト／低レイテンシで可能にす
るモジュール方式の 3 チップ ソリューションです。プロセッサは、McKinley バス（200 MHz で動作する 128 ビット幅のバ
ス）を介してメモリ コントローラに接続されます。これは、実効転送速度 400M/秒（6.4 GB/秒）を可能にするために「二
重ポンプ化」されています（バス クロックの両エッジで転送が開始されます）。メモリはメモリ I/O コントローラに直接接続
するか、zx1 SME（scalable memory expander： スケーラブル メモリ エクスパンダ）チップを介して接続することができま
す。zx1 チップセットは、最大 12 個の DDR 266 DIMM（直接接続モードの場合）または最大 48 個の DIMM（8 個の SME
を使う場合）をサポートします。メモリへの帯域幅は、8.5 GB/秒（直接接続の場合）または 12.8 GB/秒（8 個の SME を
すべて使う場合）です。メモリ使用ロードのレイテンシは直接接続の場合 156 ns ですが、SME を使う場合はこれよりも約
25 ns 長くなります。zx1 は、McKinley バスからのプロセッサを最大 4 個と各種の I/O 構成をサポートできます。次に示
したのは、HP zx1 チップセットに 2 個の CPU を接続した場合のシステムのブロック図です。
8
DIMM
DIMM
DIMM
DIMM
DIMM
DIMM
6.4 GB/s
DIMM
Itanium 2
DIMM
DIMM
Itanium 2
zx1
DIMM
DIMM
DIMM
4.3 GB/s
mio
4.3 GB/s
4.0 GB/s
PCI-X 133（1GB/s）
zx1
ioa
zx1
ioa
Core management: 10/100BT, VGA, RS-232
PCI-X 133（512MB/s）
zx1
ioa
zx1
ioa
Core U160 SCSI, 10/100/1000BT
PCI-X 133 （512MB/s）
zx1
ioa
zx1
ioa
Core 10/100BT, IDE, USB
PCI-X 133 （512MB/s）
zx1
ioa
TLB（Translation lookaside buffer： 変換索引バッファ）
Intel Itanium 2 プロセッサでは、2 つのレベルの TLB 設計が採用されています。第 1 レベルは、L1D/L1I キャッシュを処理
する小型で高速のフルアソシエイト変換キャッシュです。これは 32 エントリ TLB であり、4 KB のページ サイズをサポート
します。第 2 レベルの TLB は、128 エントリのフルアソシエイト変換キャッシュです。これは、4 KB∼4 GB までのあらゆる
ページ サイズをサポートします。TLB ミスを処理するハードウェア ページ ウォーカーがこのキャッシュをサポートします。
Intel Itanium 2 プロセッサ用のチューニング
この節では、Intel Itanium 2 プロセッサ設計の影響を受ける一般的なチューニング問題について説明します。基本的なチ
ューニング手順、計算を多用する浮動小数点アプリケーションに固有のチューニング問題、対話型アプリケーションにつ
いて説明します。
一般的なチューニング手順
1)
最適なコンパイラ フラグでアプリケーションを作成します。これは反復的な作業になりますが、基本事項と適切な開
始点についてはコンパイラに関する節で概説します。
2)
コードのプロファイルを収集し、ホット スポットを特定します。このプロセスを簡単にできる各種ツールが各 OS で利
用できます。また、Intel Itanium 2 プロセッサには、パフォーマンス ボトルネックを特定するための強力なカウンタ群
が備わっています。早めに何度もプロファイルを収集してください。あまり実行されないコードのチューニングに時間
を浪費しないでください。コードの 20%に対してチューニングの 80%を行うという 80/20 ルールを守ってください。
最初の手順として最適なのは、sample_ip (11i v1.6) または fprof (11i v2) 構成ファイルを使って Caliper を実行す
るか、Prospect を実行して、アプリケーションのプロファイルを素早く知ることです（アプリケーションが、少数の関数
に大部分の時間を費やすか、それとも多数の関数にそれぞれ一定の短い時間を費やすか）。
3)
コードの中のホット スポットを特定したら、その原因を判断する必要があります。このために、標準的な構成ファイ
ルを使って Caliper を実行し、プロセッサが何に時間を費やしているかを特定してください。次の項目を調べてくださ
い。
• 過度な機能停止—50%を上回る D キャッシュ アクセス、L2 ミス ヒット率（最大 250 M/秒）など
• 30%を上回るバス帯域幅利用率
• 浮動小数点演算の多用
• 整数演算の多用
9
4)
可能であれば、手動調整パフォーマンス ライブラリを使います。詳細については、「HP-UX のツール チェーン」を参
照してください。
5)
「Intel Itanium 2 プロセッサ用のコード構成」の説明に従って、Intel Itanium 2 プロセッサの機能を活用できるようにコ
ードを構成します。
Intel Itanium 2 プロセッサ用のコード構成
キャッシュの有効利用
3 層キャッシュ構成によって速度とサイズとのバランスが取られ、チップ設計の複雑さが軽減されます。ただし、キャッシ
ュを有効に利用するためには、プロセッサが必要とする時点で命令とデータが最小で最速のキャッシュに存在している
必要があります。これは、命令とデータを適切なキャッシュにプリフェッチすることで実現されます。効果的にプリフェッチ
できないと、アプリケーションの性能がすぐに低下します。これが、RISC プロセッサと大きく異なる点です。すべてのスー
パースカラ OOO RISC プロセッサで、キャッシュ ミスを隠すためだけに大量のチップ リソースとロジックが消費されます。
これを実現するために、指定順序に従わないで命令が実行され、すべての依存関係がわかった時点で命令が指定順序
どおりにリタイヤされます。これは、メモリ周波数に対する CPU 周波数が比較的低い場合によく機能しますが、現在の高
周波数プロセッサでは、このタスクの規模と複雑さが格段に増します。EPIC アーキテクチャでは、ソフトウェアは適切な時
間に適切なキャッシュにデータを確保する責任があります。命令が指定順序どおり実行されるため、キャッシュ ミスを隠
すハードウェア機構は存在しません。
L1I キャッシュ
計算が多用されるアプリケーションにとって、命令を効果的にプリフェッチすることは比較的簡単です。L1I キャッシュに適
合できるほどアルゴリズムの内側ループが小さいことを確認することが大切です。コンパイラによる明示的なプリフェッチ
がなくても、最初の繰り返しの後にアルゴリズム全体がキャッシュに入るからです。
L1D キャッシュ
L1D キャッシュは、浮動小数点データには関与しません。浮動小数点レジスタ ファイルに対するロード／ストアはすべて、
L2 キャッシュから行われます。L1D キャッシュは、1 サイクルで 2 つの整数ロード／ストア要求を処理できる、サイズが小
さい高速キャッシュです。サイズが小さいため、最高の性能を得るためには効果的なキャッシュ管理が重要です。L1D キ
ャッシュを最大限に活用する最良の方法は、順次アクセスされるデータが同じキャッシュ ラインに入るようにデータ構造
をレイアウトすることです。
L2 キャッシュ
L2 キャッシュには、浮動小数点レジスタ ファイルへの浮動小数点データの流れをサポートできる十分な帯域幅がありま
す。つまり、Intel Itanium 2 プロセッサはサイクルごとに 4 つのロード、2 つのストア、2 つの FMA をサポートできます。こ
れは理論上最大の浮動小数点演算レート（4000 MFLOPS/秒）ですが、最も有効なコードは一連のデータに対してルー
プで処理をします。サイクルごとに 2 回の FMA という最大ディスパーサルレートでは、サイクルごとに 32 バイトのデータ、
または 8 サイクルごとに 2 つのキャッシュ ラインが消費されます。これには、新しいデータを取得するためにさらに 2 回
の l フェッチ (lfetches) と、8 サイクルごとに 1 つの分岐命令が必要です。その結果、32 回の浮動小数点演算を実行する
には 9 サイクルが必要になります。データが L2 キャッシュにある場合、最も有効なレートは 3555 MFLOPS/秒です。
L3 キャッシュ
L3 キャッシュは、L2 キャッシュへの 32 バイト／サイクルのデータ転送速度をサポートできます。これは、プロセッサの最
高実行速度を維持できる十分な速度です。ただし、ほとんどのアルゴリズムでは、変更されたラインの削除が選択される
と、L2 キャッシュへの一部のロードによってライトバックが開始されます。daxpy のようにパイプライン処理が多いループ
では、ロードごとにライトバックが開始されます。このため、最高転送速度が 16 バイト／サイクルに低下します。これは、
プロセッサの最高実行速度を維持できる十分な速度ではありません。したがって、データが L2 キャッシュに適合するよう
にブロック化または圧縮された場合に最高の性能を実現できます。刻み幅が小さく、データが頻繁に再使用される場合
のみ、ブロック化によって性能が大幅に向上します。データが再使用されない場合、ブロック化によって性能は向上しま
せん。このようなケースの対処方法については、次の節「効果的なデータ プリフェッチ」で説明します。
データが頻繁に再使用されるアルゴリズムでは、隣接したキャッシュ ラインで順次データ アクセスが行われるようにデー
タ アクセスを設定する必要があります。Fortran の場合、これは列順で配列にアクセスすることを意味し、C 言語の場合、
行順で配列にアクセスすることを意味します。データに順次アクセスしないアプリケーションでは、刻み幅を最小限にする
ようにデータにアクセスする必要があります。
キャッシュ構成を考慮すれば、刻み幅を最小限にすることが重要になります。L2 は、256 KB の 8-way アソシエイトキャッ
シュです。これは、128 バイトのキャッシュ ラインをそれぞれ保持できる 256 のバケツが存在するようにキャッシュが構
10
成されていることを意味します。アドレスは、物理アドレス ビット部を調べることで特定されます。アドレスの一部のみ調
べられるため、アドレス衝突（異なるアドレスが同じキャッシュ ラインに割り当てられる）が発生することがあります。デー
タ アクセス間の刻み幅が 256 のキャッシュ ラインであれば、新しい参照がそれぞれ同じバケツに割り当てられます。こ
れによってキャッシュが 8 つのキャッシュ ラインのサイズとなり、効果的です。
効果的なデータ プリフェッチ
Intel Itanium プロセッサ ファミリ（または任意のアーキテクチャ）上で最大限の性能を得る最良の方法は、重要なルーチ
ンをアセンブリ コードに書き込むことです。この方法を採用すれば、開発者はアルゴリズムに対して最も効率的なコード
を生成することができます。アセンブリ コードの書き込みの詳細については、Itanium Architecture Assembly Language
Reference Guide と Itanium Architecture Assembler User’s Guide を参照してください。
開発者がアセンブラ コードを書き込みたくない場合は、別の方法で性能を向上させることができます。データがほとんど
再使用されないアプリケーションや刻み幅が大きいアプリケーションの場合、効果的なプリフェッチを可能にする方法が
2 つあります。第 1 の方法はコンパイラにプリフェッチのためのコードを生成させることであり、こちらの方が簡単です。こ
れは優れた方法であるように思われますが、プリフェッチ対象をコンパイラが知るには、重複していないメモリ アクセスを
簡単に認識できなければなりません。投機的にデータと実行する命令をプリフェッチするための機構は存在しますが、こ
の機構をサポートするリソースは限られています。データをプリフェッチする回数が多すぎても性能が低下します。ソース
コードでメモリ参照をできるだけ明確に記述することがはるかに良い方法です。また、ほとんどの Intel Itanium プロセッサ
ファミリのコンパイラに備わっているスイッチを利用すれば、開発者は、メモリ エイリアスが含まれないことが保証された
コード ブロックまたはポインタをコンパイラに通知できます。このコーディング スタイルを採用すると、同様にリソースが限
られている従来の RISC プロセッサや CISC プロセッサでの性能も向上します。
第 2 の方法は、ソースに明確なプリフェッチ ヒントを記述することです。この方法は、ソース コード内の少数の場所でキャ
ッシュ ミスの大部分が発生する場合、特に効果的です。また、この方法では残りのコード部分を開発者が無視することも
できます。どれくらい前にキャッシュ ラインをプリフェッチする必要があるかについては、厳格で不変の規則はありません。
このタイミングは、各データ アクセス命令間にある命令の数に依存します。現在の HP の Itanium 2 ベース システムでは、
メイン メモリからの使用のためのロード レイテンシは最大 155 ns です。つまり、データ アクセス間に 50 サイクルに相当
する命令が存在する場合、データを順次アクセスする際に、現在のアクセスに先立って 3∼4 のキャッシュ ラインをプリフ
ェッチする必要があります。たとえば、一般的な OpenGL ライブラリの glNormal3fv コードは次のようになります。
void glNormal3fv( const float * v )
{
extern float *bptr, *bend, *bstart;
// Check for buffer overflow
if ((bend - bptr) < 12){
sendFullBufferToHW();
bptr = bstart;
}
// Copy data from user’s memory to device’s buffer
*bptr++ = *v++;
*bptr++ = *v++;
*bptr++ = *v++;
}
このように、アプリケーションでライブラリ関数が呼び出されると、データ ポインタが新しいキャッシュ ラインを参照するた
びに、メモリからのデータを待機してプロセッサが機能停止に陥り、多くの CPU サイクルが浪費されます。ただし、ライブ
ラリ内でプリフェッチを実行すると、データ移動の効率性を大幅に向上できます。
void glNormal3fv( const float __restrict *v )
{
extern float * __restrict bptr, *bend, *bstart;
// request a cache line to be loaded (4th one from where
// we are =((128bytes/cacheline)*4 cachelines)/sizeof float)
__Asm_lfetch(_LFTYPE_NONE,_LFHINT_NONE, v+128);
// Check for buffer overflow
if ((bend - bptr) < 12)
{
sendFullBufferToHW();
bptr = bstart;
}
*bptr++ = *v++;
11
*bptr++ = *v++;
*bptr++ = *v++;
}
データがキャッシュ内に存在する場合、プリフェッチを実行しても意味はありません。この方法の不利な点は、データの局
所性が低い場合、不要なメモリがフェッチされることです。これによって、実際のデータに利用できた可能性のある帯域
幅とキャッシュが消費されます。あまりに多くのデータや未使用データをプリフェッチすると、プリフェッチしなかった場合と
同じくらい性能が影響を受けることがあります。このことを理解しておくことはきわめて重要です。過度なプリフェッチによ
ってメモリ システムが酷使され、不要な機能停止が発生します。また、「必要な」キャッシュ ラインがキャッシュからフラッ
シュされ、機能停止サイクルが増加することさえあります。
コードを最初から開発する場合や既存のコードを大幅に書き直す場合は、データ構造を整理して、一緒にアクセスされる
データを同じキャッシュ ラインにまとめることが重要です。このようにすれば、コンパイラが効果的なプリフェッチを簡単に
実行できるようになります。さらに、同じキャッシュ ラインに入らないように整数変数と浮動小数点変数を分離することも
大切です。整数ロード／ストアは L1 キャッシュから実行され、浮動小数点ロード／ストアは L2 キャッシュから実行される
ことに注意してください。浮動小数点ストアが、L1 と L2 の両方に常駐するキャッシュ ラインに対して実行される場合、L1
内のキャッシュ ラインは破棄されます。次回、このキャッシュ ライン内の整数データへの参照が起こると、キャッシュ ライ
ンが再ロードされ、不要な機能停止が発生します。
効果的な命令スケジューリング
キャッシュを有効利用するコードを構成し、効果的なプリフェッチを可能にして性能を高める方法の他にも、Intel Itanium
プロセッサ ファミリはいくつかの機能をサポートしています。性能を向上する最も簡単な方法は、コンパイラを Intel
Itanium 2 プロセッサ用にスケジューリングすることです。ソース コードを Itanium 2 ベース システムでネイティブにコンパ
イルする場合、この方法はすべてのコンパイラ（gcc を除く）にデフォルトで適用されます。Itanium 2 プロセッサにアップグ
レードされる以前のシステム上でコードを作成する場合、以前のマシン用にコードが最適化されるという結果になってし
まうことがあります。この場合、Itanium 2 ベース システムでの性能が妨げられます。Itanium 2 プロセッサのコード スケ
ジューリングを選択する正しい方法を決めるには、該当するコンパイラのガイドを参照してください。 gcc コンパイラは、
Itanium 2 プロセッサ スケジューリングのオプションをサポートしていません。 gcc コンパイラは常に、単一発行
(single-issue) マシン用に命令をスケジューリングします（Itanium ベース システムと Itanium 2 ベース システムの両方とも、
クロックごとに 2 つの命令バンドルを発行する「二重発行 (two-issue) 」マシンです）。
コードの主要アルゴリズムがループとして表される場合、Intel Itanium プロセッサ ファミリのソフトウェア パイプライニング
または剰余ループ スケジューリングによって性能を大幅に向上することができます。剰余ループ スケジューリングによっ
て、プロセッサはアルゴリズムからさらに並列性を引き出すことができます。この機能は、アセンブリ コードがアルゴリズ
ム用に記述されていない場合、コンパイラによって有効にする必要があります。この機能を活用できるコードの場所をコ
ンパイラに通知するコンパイラ ヒントまたは指令はありません。この機能はレジスタ回転を利用して実現されるため、多
数のレジスタまたは分岐を必要とする長い計算列を持つループはパイプライン処理されません。
アーキテクチャの機能を有効にするだけでなく、アーキテクチャで利用可能な並列性をコンパイラで活用できるようにコー
ドを構成する必要があります。つまり、コードの移動を可能にするために十分な命令を使用できなければなりません。こ
のための方法は 2 つあります。第 1 の方法は、処理の多くの部分を重要な関数に実行させるようにソース コードを構成
することです。第 2 の方法は、多数の短い関数（C++では一般的）から構成されるアプリケーションに適した方法です。こ
の方法では、インライン化を慎重に利用する必要があります。コンパイラは、関数をインライン化して、1 つのオブジェクト
ファイル内の関数間と複数のオブジェクト ファイル間で最適化できます。
これらの機能は慎重に利用する必要があります。あまりに多くの関数をインライン化すると、生成されるコードが大幅に
増えます。これが原因で、命令キャッシュ ミスが増加することがあります。その結果、インライン化で向上した並列性によ
って得られた利点が台無しになる可能性があります。同様に、プロシージャ間の最適化またはプログラム全体の最適化
を有効にすると、コードが大きい場合は特に性能が阻害されます。これによってコンパイル時間が長くなります。
12
Intel Itanium プロセッサの PMU (Performance Monitoring Unit)
Itanium 2 プロセッサには、300 を超えるイベントのモニタに利用できる 48 ビットのパフォーマンス カウンタが 4 個搭載さ
れています。PMU には、パフォーマンス障害を特定できる、イベント アドレス レジスタなどの高度なモニタ機能が備わっ
ています。
多数のイベントをモニタできるので、作業の開始点を知ることが大切です。最良の開始点は、プロセッサによるコード実
行の効率性を知ることです。基本サイクル アカウンティングを調べると、この効率性を知ることができます。サイクル アカ
ウンティングでは、プロセッサが消費する時間を高水準で表示できます。サイクルは、おおよそ次のように分類されます。
•
機能停止しない実行 — 有効な処理をプロセッサが実行中
•
データ アクセス — メモリ階層からのデータ取得を待機するために費やされるサイクル
•
命令アクセス — メモリ階層からの命令取得を待機するために費やされるサイクル
•
分岐予測ミス— 予測に失敗した分岐からの回復に費やされるサイクル
•
RSE — プロシージャ コール時のレジスタのメモリへの書き出しとメモリからの読み込みに費やされるサイクル
•
スコアボード — レジスタ／機能ユニットを待機するために費やされるサイクル
基本サイクル アカウンティングを利用すれば、次に調べるパフォーマンス障害場所を特定できます。正しくチューニング
されたアプリケーションの一般的な範囲は、次の表のとおりです。
費やされるサイクル
%
機能停止しない実行
+50%
データ アクセス
<40%
命令アクセス
<5%
分岐
<5%
RSE
<5%
スコアボード
<5%
機能停止しない実行が 50%を上回っている場合でも、パフォーマンス チューニングの余地が十分にあります。その理由
は、サイクル アカウンティングを調べるだけでは、実行されている有効な命令の数を認識できないからです。認識できる
のは、命令が実行されているかどうかだけです。サイクルごとに 6 つの命令を実行できるマシンでは、大部分の時間が
命令の実行に費やされている場合でも、性能が広範囲にわたる可能性があります。PMU には、有効な命令の数と NOP
命令（何もしない命令）の数、ディスパーサルが中断された回数、別の種類のパイプライン競合が発生した回数を通知す
るカウンタが備わっています。total_cpu 構成で Caliper を実行すれば、NOP 命令と有効な命令に関する次の情報が
生成されます。
PMU Events:
INST_DISPERSD, NOPS_RETIRED,CPU_CYCLES
CPI:
CPU_CYCLES/INST_DISPERSED
Useful CPI:
CPU_CYCLES/(INST_DISPERED – NOPS_RETIRED)
また、アプリケーションと作業負荷の実際の性能を計算に入れる「パスの長さ」という概念もあります。パスの長さは、タ
スクまたはベンチマークの完了に必要な命令の総数です。一般に、CISC マシンのパスの長さは RISC マシンよりも短く、
RISC マシンのパスの長さは EPIC マシンよりも短くなります。パスの長さが増すことは良くないと思われますが、これによ
って、全体的な性能を現実に高める別の機能が有効になります。CISC と RISC の競争ではプロセッサ周波数が大幅に増
加するという形で性能が向上しました。EPIC では、サイクルごとに発行される命令の数が多くなるという形で性能が向上
します。PMU カウンタを読み取るパフォーマンス ツールのいずれかを使えば、アプリケーションでの特定作業負荷のパ
スの長さを簡単に測定できます。
13
当然ですが、パスの長さとプロセッサの効率性が両立しないことがあります。パスの長さを最適化または短縮すると、機
能停止しない実行に費やされる時間の割合が下がる可能性が高くなります。ただし、必要な命令が少なくなるため、最
終的には性能が向上します。
Caliper は、PMU にアクセスするためのツールです。このツールについては、後で説明します。また、Intel は、PMU ベー
スのチューニング手法に関する文書 Intel Itanium 2 Processor Reference Manual for Software Development and
Optimization なども提供しています。
アプリケーション プロファイル
アプリケーションと作業負荷でプロセッサがどのように利用されるかを理解した後、コードのどこに問題があるかを知る必
要があります。パフォーマンス障害の 80%がコードの 20%にあるという 80/20 ルールが、ほとんどのチューニングに当
てはまります。Intel Itanium 2 プロセッサの PMU とツール（Prospect や Caliper など）を組み合わせると、パフォーマンス
障害場所とその原因に関する大量の情報を得ることができます。
性能を向上するための 10 のヒント
1)
コンパイラ セクションの「実施例」コンパイラ オプションを使う。
2)
非正規化トラップを避ける。
非正規化トラップとはどのようなものでしょうか。非正規化浮動小数点の数は、0 に近い値です。非正規化浮動小
数点の数はあまりに小さいため、使用されるデータ タイプの精度では表現できません。
特定する方法は、次のとおりです。
• Prospect を使う。
• “TraP”合計時間が 1%を超える。
• カーネルの実行時間の最長が fwpsm_proc_stacked であるが、EFI_fpswa でもある。
• Caliper total_cpu –sampling-counter=FP_FALSE_SIRSTALL,FP_TRUE_SIRSTALL
• wdb トリック設定$ar40-=2 と SIGFPE 処理で場所を特定する。
修復する方法は、次のとおりです。
• +FPD または-ffast-math (gcc) が有効な場合がある。
• 以前に初期化されていないデータを初期化すれば有効な場合がある。
• 浮動小数点型を拡張すれば（つまり精度を上げれば）有効な場合がある。
• +Ofenvaccess が有効な場合があるが、トラップしないコードの速度が遅くなることがある。
3)
誤った SIR 機能停止を避ける。
SIR 機能停止とはどのような事態なのでしょうか。Itanium 2 プロセッサでは、正確な例外をサポートするために SIR
(Safe Instruction Recognition) と呼ばれる手法が採用されています。SIR 論理が表明されている場合、トラップが必
要であるかどうかを判断する間、パイプラインが機能停止します。トラップが実行されない場合、機能停止は不要で
した。
特定する方法は、次のとおりです。
• Caliper total_cpu –sampling-counter=FP_FALSE_SIRSTALL, FP_TRUE_SIRSTALL
• Caliper sample_ip –sampling-counter=FP_FALSE_SIRSTALL –context-lines=0,3
解決する方法は、次のとおりです。
• +FPD が有効。
• 浮動小数点型を拡張すれば（つまり精度を上げれば）、有効。
4)
大きいメモリページサイズを使う。
特定する方法は、次のとおりです。
• TLB ミスが多いかどうかを調べる。メモリのページサイズを大きく取れば、TLB ミスの多発を防ぐことができる。
• ページサイズとカウントを procvm、vps_stats、または glance でチェックする。
解決する方法は、次のとおりです。
• chatr +pd<1∼16>M または ld +pd<1∼16>M
• chatr +mergeseg が有効。
14
5)
不正な ALAT 比較を避ける。
ALAT とは何でしょうか。ALAT は、Advanced Load Address Table の略語です。ALAT は、投機的ロードまたは高度
なロードを追跡します。ALAT 比較の回数が多すぎると高度なロードが失敗し、性能が大幅に低下します。
特定する方法は、次のとおりです。
• Prospect または Caliper の sample_ip (11.22)/fprof (11.23) を読み、ALAT 関連命令の時間を調べる。
•
Prospect 出力をフィルタ処理し、回復命令の時間を調べる。次に示したのは、Prospect 出力をフィルタ処理して
回復コード バンドルの開始を強調表示するスクリプトです。
Awk `
/chk.a/{
t=substr($10, index($0,”,”)+1);
e*match(t,”[ ;]”;
if(e)t=substr(t,1,e-1);
split(t,parts,”+”);
offsets[parts[2]]=sprintf “%6d %s”,FNR,$0;
}
/^ *[0-9]+% /{
for (I in offsets)
delete offsets[I]
}
/ \+0x[0-9a-f]* :/{
offset=substr($0,index($0,”+”)+1);
offset=substr(offset,1,index(offset,” “)-1);
if (offset in offsets) {
print offsets[offset];
printf “%6d %s\n”,FNR,$0;
}
}’
解決する方法は、次のとおりです。
• +Onoparmsoverlap
• +Optrs_ansi
• +Onoptrs_to_globals
たとえば次のように__restrict キーワードを使って、重複がないことをコンパイラに保証する。
Void *Mymemcpy(void * __restrict s1, const void * __restrict s2, int c, size_t
n);
重複がないかどうか明示的にテストした後で__restrict バージョンを呼び出す必要があることがあります。
読み取りデータと書き込みデータがほとんどの時間、実際に重複する場合は、投機的実行が使われないので、
このようなコードの方が、低い最適化で速く実行されることがあります。
6)
float と int を同じキャッシュ ラインで使わないようにする。
浮動小数点数をキャッシュ ラインにストアすると、そのラインが L1 キャッシュから排除されます。浮動小数点と非浮
動小数点の型が混在する構造体に注意してください。
特定する方法は、次のとおりです。
• ソース コードを調べる。
• Caliper dcache_miss –context-lines=0,3
• レイテンシが高い整数ロードを調べる。
解決する方法は、次のとおりです。
• 型ごとに構造体フィールドをソートする。
7)
アクティブなデータを同じキャッシュ ラインにまとめる。
構造体内では特に明瞭です。順序ローカル変数宣言で発生することもあります。
特定する方法は、次のとおりです。
• Caliper dcache_miss –context-lines=0,3
• レイテンシが異常に高い整数ロードを調べる。
• ソース コードを調べる。
15
解決する方法は、次のとおりです。
• ホット ルーチンでのアクティビティごとに構造体フィールドをソートする。
8)
明示的なプリフェッチを追加する。
特定する方法は、次のとおりです。
• Caliper dcache_miss –context-lines=0,3
• レイテンシが実際に高い浮動小数点ロードまたは整数ロードを調べる。
• ソース コードを調べる。
解決する方法は、次のとおりです。
•
9)
HP-UX
#pragma HP_OPT_DATA ptrVar or
#pragma PREFETCH array[index] or
#include <machine.h>
__Asm_lfetch(_LFTYPE_NONE,_LFHINT_NONE,p);
リンク リストの追跡を取り除く。
リンク リストの追跡によって必ずレイテンシを伴う機能停止が発生します。この追跡は、通常の“p=p->next”式に
類似する場合や、“i=a[i]”のような配列インデックス検索に隠れる場合があります。
特定する方法は、次のとおりです。
• ソース コードを調べる。
解決する方法は、次のとおりです。
• データ構造を変えるか、アルゴリズムを修正する。
• 刻み幅検出でプリフェッチできる場合がある。
10) OpenGL の場合は特に+tls=static を考慮する。
現状では、デフォルトの+tls=dynamic によって、OpenGL 呼び出しのたびに余分に関数が呼び出されます。近い将
来発表されるコンパイラでは、改善される予定です。
HP-UX のツール チェーン
HP の Itanium 2 ベース システムは、次の 3 種類のオペレーティング環境をサポートしています。HP-UX、Linux (Red Hat
Advanced Server)、64-bit Microsoft Windows 2003 です。Intel Itanium プロセッサ ファミリ向けの HP-UX 11i は 5 年
以上かけて開発されており、3 種類の中で最も強力な OS です。HP-UX 11i は 32 ビットと 64 ビットの両方の開発環境を
サポートしており、アプリケーションの開発とチューニングのための強力なツール チェーンを備えています。HP-UX は、エ
ミュレーション モードで既存の PA コンパイル済みバイナリをサポートします。エミュレーション モードでのバイナリ実行の
性能は、ネイティブ コードよりも低くなります。性能低下の程度は、実行されるコードの種類によって大きく異なります。計
算を多用する浮動小数点コードのような、Itanium プロセッサの機能を最大限活用できるコードでは大きな性能低下が生
じますが、グラフィックスのようにシステム ライブラリを多用するコードでは性能低下はわずかです。
®
®
コンパイラ
Intel Itanium プロセッサ ファミリ上の HP-UX では、次の 4 種類のコンパイラを使うことができます。組み込みの ANSI C コ
ンパイラ、高性能 C/C++コンパイラ (aCC)、gcc コンパイラを移植したもの、Fortran 90 コンパイラ (f90) です。ANSI C
コンパイラ、aCC、および Fortran では、同じコンパイラ バックエンドと低水準オプティマイザが使われています。ただし、
ANSI C コンパイラでは最適化のサポートが限られています。これらのコンパイラを効果的に利用する上で参考になる文
書があります。これらの文書は、コンパイラをインストールしたシステムのインストール ディレクトリで利用できます。また、
オプティマイザとその機能に関する詳しい説明がDSPP パートナ エッジ Web サイトで公表されています。HP-UX ページの
technical documentation セクションで探してください。ホワイト ペーパーのタイトルは、 Optimizing Itanium-based
applications です。
aCC コンパイラオプションの最良の例
+O3 +Dsitanium2 +Ofltacc=relaxed +FPD +Oinitcheck –Wl,+pd1M
16
パフォーマンス ツール
HP-UX 上のアプリケーション性能の分析に役立つツールが用意されています。HP Caliper と Prospect です。
Prospect
Prospect は、アプリケーションのプロファイル データを収集するために HP が開発したオープンソース ツールです。このツ
ールの役割は、アプリケーションで時間が費やされる場所に関するデータを提供することです。アプリケーションのシンボ
ルが削除されていない場合、各関数で費やされる合計時間ごとにソートされたプロセスのリスト（および、各プロセス内の
関数リスト）を提供します。このツールは、プログラム カウンタ (PC) サンプリング フラット プロファイラです。ユーザー イン
タフェースはシンプルであり、結果をすぐに理解することができます。出力は、サンプリング期間に実行されたすべてのプ
ロセスの関数、アセンブリ、およびカーネルの各プロファイルから構成できます。出力サンプルと簡単な説明が付録 A と
付録 B に記載されています。http://prospect.sourceforge.net/からソースおよび選択された実行可能ファイルをダウン
ロードできます。
Caliper
Caliper は、コンパイル環境を変更することなく様々なアプリケーションの分析に利用できる構成可能な汎用ツールです。
このツールでは、動的コード測定と Intel Itanium プロセッサ PMU を組み合わせて分析用のデータが収集されます。行儀
の良い（well-behaved）コードの場合、Caliper はターゲット アプリケーションの動作を変更しません。
HP-UX 上で実行される Itanium アーキテクチャ用にコンパイルされたコードであれば、ほとんどすべてに対して Caliper を
実行できます。このようなコードには、C/C++と Fortran アプリケーション、あらゆる水準の最適化、アーカイブまたは共
有バインディング、シングルスレッドとマルチスレッド、追加プロセスを生成するアプリケーションまたはシェル スクリプト
が含まれます。少数の顕著な例外としては、Aries トランスレータ上で実行される PA バイナリ、動的にコードを生成するア
プリケーション、HP-UX 上で gcc を使ってコンパイルされたアプリケーションのサポートがあります。
Caliper の機能は、次のとおりです。
•
事前設定された 13 種類の性能測定（それぞれ、構成ファイルによってカスタマイズ可能）
•
すべてのレポートをテキスト フォーマットで利用可能。ほとんどのレポートを HTML で簡単に表示可能
•
性能データがソースに行番号で関連付け
•
測定時に特定モジュールを簡単に包含／除外可能
•
スレッドごとのレポートと集約スレッド レポート
•
ホット スポットを示すためにソートされ、関数ごとに報告されるサンプル データ
Caliper を実行するには、コマンド行で次のように指定します。
Caliper config_file [caliper_options] program [program_args]
config_file が Caliper に測定対象を指示します。オプションを使って、データ収集とレポートに関する追加情報を指
定できます。Caliper の完全な説明については、/opt/caliper/doc/html/index.html を参照してください。
付録 B の例を参照してください。
パフォーマンス ライブラリ
Itanium 2 ベース システム上の Linux について、次の 2 種類のパフォーマンス ライブラリが使えます。VML（Vector Math
Library： ベクトル数学ライブラリ）と数学ライブラリMLIBです。
VML
VML は、ベクトル型の引数に対して演算を行う 58 個の基本数学関数のライブラリです。これらの関数は、単精度と倍精
度の両方で使えます。この関数にアクセスするには、関数名の前に”v”を付加した（たとえば、tan の場合 vtan）標準 C
math.h 関数を呼び出します。これらの数学ルーチンはアセンブリで記述され、命令は Intel Itanium 2 プロセッサ専用に
（Itanium プロセッサではなく）スケジューリングされます。このライブラリは、ISO/IEC 9899 コーナー ケース仕様に完全
に準拠しています。また、このライブラリの精度は非常に高く（ターゲット ULP IEEE 倍精度 < 0.502 、 IEEE 単精度
< 5001）、正と負の刻み幅で動作できます。このライブラリは、例外を生じることなく正しく機能するように設計されてい
ます。
17
Pentium 4 ベクトル数学ライブラリに対する速度
HP のベクトル数学ライブラリ
高いほど良い
HP VML の性能は平均で、Pentium 4 Intel 数学ライブラリ カーネルの 1.7 倍（ほぼ 2 倍）であり（2.6 GHz Pentium 4 と
1 GHz Itanium 2 との比較）、高い正確度と倍精度を備えています。
HP の MLIB
MLIB には、次の 4 つのコンポーネントがあります。VECLIB、LAPACK、ScaLAPACK、SuperLU_DIST です。これらのコンポ
ーネントは、Intel Itanium 2 プロセッサ上で使うために最適化されています。HP MLIB にはアルゴリズム上の改良点が多
数組み込まれており、実行性能を最大限にするためにいくつかの調整パラメータが調整されています。 VECLIB では、
BLAS (Basic Linear Algebra Subprograms) レベル 1、2、および 3 の効率の高い実装方式と、新たに定義された BLAS
Standard のサブセットが使われています。LAPACK は、パブリック ドメイン LAPACK バージョン 3.0 に完全に準拠してい
ます。ScaLAPACK は、パブリック ドメイン ScaLAPACK バージョン 1.7 に完全に準拠しています。SuperLU_DIST は、パブ
リック ドメイン SuperLU_DIST バージョン 1.0 に完全準拠しています。MLIB の主要な計算カーネルは、Intel Itanium プロ
セッサの並列アーキテクチャを最大限活用するように最適化されています。次のグラフは、HP-UX を実行する Itanium 2
ベース システム上で daxpy の性能に与える MLIB の影響を示しています。L2 キャッシュに収まるようにデータをブロック
化できる場合、MLIB によって性能が向上します。
18
Itanium 2 ベース システム上の DAXPY 性能
HP-UX MLIB
sec
f90+03
まとめ
Intel Itanium アーキテクチャは、高性能商用／技術用コンピューティングのサポートに必要なあらゆる機能を備えていま
す。Itanium アーキテクチャは、3 種類の業界標準 OS だけでなく、高性能アプリケーションの開発とチューニングに必要
なツールに対するサポートを向上しています。Intel Itanium プロセッサ ファミリは、64 ビット プロセッサの分野で業界をリ
ードし続けます。優れた浮動小数点性能を必要とするコードや、アルゴリズムに高度な並列性を含むコードでは、Itanium
2 ベース システム上で性能が著しく向上します。工学／科学アプリケーションの多くがこのカテゴリに入ります。一般に、
1 GHz Itanium 2 ベース システムの処理速度は 750 MHz PA-8700 システムの 1.5 倍です。浮動小数点性能は、最大
3 倍になります。
19
付録 A： Prospect の使用例
この付録では、Prospect を使ってコード内のパフォーマンス障害場所を特定する例を示します。Prospect は各種オプショ
ンで実行できますが、最も有効な呼び出し方法は次のとおりです。
Prospect –V3 –e –f <出力ファイル> <アプリケーション> <オプション>
または
Prospect –V4 –e –f <出力ファイル> <アプリケーション> <オプション>
–V3 オプションを指定した場合はアプリケーションとその子プロセスに関するデータが報告され、–V4 オプションを指定し
た場合はアプリケーションの実行中にアクティブであるすべてのプロセスに関するデータが報告されます。–e オプション
を指定すると、サンプル ヒット数に達したシンボルについてアセンブリ命令が報告されます。–e オプションを追加すれば、
サンプル ヒットを受けるすべてのシンボルの逆アセンブリを強制することができます。
この節では、オープンソース ベンチマーク pi_css5 のプロファイルからの Prospect 出力を示します。これは、多数の小数
位までの円周率計算を伴う計算のほとんどで行われる多倍精度乗算を加速するために高速フーリエ変換を使ったアプ
リケーションです。このアプリケーションは、最新の C コンパイラと次のオプションで、HP-UX 11i v1.6 上でコンパイルされ
ています。
+Ofast +Ofltacc=relaxed +FPD
Prospect 出力には、次の 3 つの主要セクションがあります。
セクション 0： アクティブなプロセスで使われる SPU（System Processing Unit： システム プロセシング ユニット）の要約情
報。これがマルチプロセッサ システムである場合、このセクションには両方のプロセッサの合計データが示されます。ア
プリケーションがシングル スレッドである場合、ユーザー時間は約 50%になり、待機時間は長くなります。
セクション 1.0： このプロセスの実行時間+ブロック時間=経過クロック数 (Execution+Blocked=Elapsed Clocks)をソートし
た情報。これは、収集期間中にクロック サイクルを使ったプロセスの種類に関する統計情報です。この情報を利用して、
重大なシステム オーバーヘッドの原因を特定できます。また、下位セクションには、システム コールで費やされた時間、
優先的に費やされた時間、ブロックされた時間が示されます。
セクション 2.0： 100 MHz システム クロックでのプロセス インターセクション。これは、アプリケーション内のホット スポッ
トを特定するための様々な内容を含むセクションです。このセクションには、最も頻繁に実行された関数に費やされた時
間の割合、上位の関数で費やされた累積時間、各関数でのヒット数、各サンプル ポイントで費やされた秒数、サンプル
ポイントのアドレス、関数名、命令、テキスト スペース、ソース ファイル名が示されます。マルチスレッド プロセスの場合、
このセクションにはスレッドごとのデータが含まれます。
セクション 3.0： 仮想メモリ、RAM 使用量、非同期 I/O アクティビティ。次に示したのは、Prospect 出力の例です。
20
-----------------------------------------------------------------------------------------Section 0: Summary of the SPU Used by Active Processes
-----------------------------------------------------------------------------------------KTC Clocks Results - (All Processes and SPUs)
KTC clock_SPU
0Seconds % TotaluSec/Entry
Entrys
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
KTC_sum
251.908202 99.987%
Total
IdlE
138.768599 55.080%
46117.8
3009
UseR
112.328529 44.585%
1601.0
70161
PreempT
0.313273
0.124%
58.3
5372
Sys
0.299461
0.119%
7.2
41763
IntUseR
0.238726
0.095%
14.8
16140
IntIdlE
0.137888
0.055%
8.4
16493
VfaulT
0.048891
0.019%
231.7
211
CsW
0.047277
0.019%
5.4
8829
TraP
0.021057
0.008%
8.8
2384
UpfaulT
0.012632
0.005%
15.1
834
IntSys
0.005142
0.002%
11.1
465
KTC Processor Time not Charged to Processes:
IdlE
138.768599 55.080%
46117.8
3009
IntIdlE
0.137888
0.055%
8.4
16493
CsW
0.017736
0.007%
Total
- Skip remainder, SPU of 0.0010 is below '-m 0.0010' Sec
KTC clock_SPU
1Seconds % TotaluSec/Entry
Entrys
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
KTC_sum
251.941246 100.000%
Total
UseR
135.761731 53.886%
1078.5
125879
IdlE
115.388605 45.800%
55289.2
2087
Sys
0.293186
0.116%
11.4
25794
IntUseR
0.210844
0.084%
11.8
17875
VfaulT
0.143847
0.057%
366.0
393
IntIdlE
0.056168
0.022%
4.8
11586
CsW
0.051000
0.020%
6.1
8379
TraP
0.024461
0.010%
9.5
2583
UpfaulT
0.010969
0.004%
15.8
694
- Skip remainder, SPU of 0.0004 is below '-m 0.0010' Sec
これは、デュアルプロセッサ システム上のシングルスレッド アプリケーション実行の要約情報を示しています。一方のプ
ロセッサが使われていないため、待機時間はサイクルの 50%までです。
Summary of 34 Processes Analyzed - Sorted by SPU Usage Secs
Process Name
pi_css5
prospect
dtterm
Xf86
psmctd
vxfsd
ia64_corehw
swagentd
vhand
schedcpu
statdaemon
mib2agt
netfmt
sendmail
dtwm
Pid
USER
TOTAL StartTim
(03180)N 247.619 248.444
(03179)W
0.192
0.222
(02881)N
0.109
0.179
(02118)N
0.056
0.162
(02185)N
0.024
0.075
(00066)WM -0.000
0.068
(02466)N
0.003
0.067
(01843)N
0.041
0.042
(00002)W -0.000
0.038
(00029)WM
0.000
0.019
(00003)W
0.000
0.019
(01158)N
0.008
0.016
(00533)N
0.004
0.012
(01083)N
0.000
0.011
(02880)N
0.008
0.011
0.000
0.702
0.014
0.014
1.092
0.662
9.332
16.032
4.892
0.642
0.892
23.302
0.592
16.472
5.802
Elapsed VMblock PagesIn
248.509
250.501
246.161
249.265
250.133
252.017
226.249
212.311
242.000
251.992
250.349
209.992
250.700
180.023
240.344
21
サンプル期間中に実行されるプロセスごとにソートすると、pi_css5 が事実上すべてのサイクルを使っていることがわかり
ます。
---------------------------------------------------------------------------Section 1.0: Sorted Execution+Blocked=Elapsed Clocks for this Process, EPB
---------------------------------------------------------------------------Clock
Type
Seconds % Elapsed uSec/Count
Counts
ELAPSED
EXECUTION
Execution
Execution
Execution
Execution
Blocked
BLOCKED
Execution
Execution
- Skip remainder,
TOTAL
248.509238 100.000%
Total
TOTAL
248.444003
99.974%
Total
UseR
247.618636
99.642%
5747.3
IntUseR
0.447657
0.180%
14.8
VfaulT
0.188609
0.076%
464.6
Sys
0.107301
0.043%
40.3
PreempT
0.065663
0.026%
2736.0
TOTAL
0.065235
0.026%
1359.1
TraP
0.045404
0.018%
9.2
CsW
0.035632
0.014%
7.2
SPU of 0.0007 is below '-m 0.0010' Sec
43084
30163
406
2663
24
48
4918
4930
---------------------------------------------------------------------------Section 1.1: Time Process Executed during System Calls
---------------------------------------------------------------------------TOTAL
Sys
0.107301 100.000%
40.3
2663
- Skip remainder, SPU of 0.0000 is below '-m 0.0010' Sec
---------------------------------------------------------------------------Section 1.2: Time Process Preempted in System Calls
---------------------------------------------------------------------------TOTAL
PreempT
0.065663 100.000%
2736.0
24
times
PreempT
0.057073
86.918%
2853.7
20
write
PreempT
0.004689
7.141%
2344.4
2
siginhibit
PreempT
0.003901
5.941%
1950.6
2
---------------------------------------------------------------------------Section 1.3: Time Process Blocked
---------------------------------------------------------------------------Preempt
PreempT
0.065663 100.656%
2736.0
24
TOTAL
BlockeD
0.065235 100.000%
1359.1
48
- Skip remainder, SPU of 0.0000 is below '-m 0.0010' Sec
22
-------------------------------------------------------------------------------
Section 2.0: Process Intersections with 100Hz System Clock, UK
------------------------------------------------------------------------------USER portion of profile:
24723 hits = 247.23 seconds. KTC time was 247.619 seconds
pcnt accum% Hits
Secs
Address
20%
20% 4845
48.45
0x0401ceb0
/home/tdf/pi_css5_src/pi_css5
1
0.01
+0x0000 :
:
:
Routine name
_Z7cftmdl1iPd
Instruction
TEXT
FUNC
Filename
GLOBAL
alloc
mov
extr
r48=ar.pfs,0,50,0,16 MMI
r18=r12
r70=r32,3,29
stfd
[r79]=f41,8
:
:
stfd
fmpy.d.s0
[r77]=f35,8
f35=f15,f38
+0x0a50 :
chk.a.clr
f19,_Z7cftmdl1iPd+0x17f0
:
:
+0x0a60 :
:
:
chk.a.clr
fmpy.d.s0
f18,_Z7cftmdl1iPd+0x1870
f41=f14,f45;;
stfd
chk.a.clr
fmpy.d.s0
[r77]=f50,8
MMF
f17,_Z7cftmdl1iPd+0x18e0
f34=f15,f32
…
29
MMF
0.29
+0x0a40 :
MMF
26
0.26
+0x0a70 :
:
:
+0x0a80 :
:
:
chk.a.clr
nop.m 0x0
fmpy.d.s0
f20,_Z7cftmdl1iPd+0x1960 MMF
chk.a.clr
chk.a.clr
fsub.d.s0
f7,_Z7cftmdl1iPd+0x19d0 MMF
f21,_Z7cftmdl1iPd+0x1a50
f46=f28,f44
f50=f14,f33;;
754
7.54
24
0.24
+0x0a90 :
:
:
ldfd.a
ldfd.a
fsub.d.s0
f18=[r78],8
f16=[r26],-8
f40=f43,f37;;
MMF
25
0.25
+0x0aa0 :
:
:
ldfd.a
ldfd.a
fadd.d.s0
f19=[r78],8
f20=[r76],8
f51=f48,f47
MMF
セクション 2 は、関数とその関数内のアドレスの実際のサンプル ヒット数を示しています。また、サンプル アドレスについ
てアセンブリ命令も示しています。ただし、ヒットを引き起こしている命令またはバンドルを示すことはできません。上記の
リストでは、最上位関数に多くのヒットがあります。これは、チューニングの可能性があるという意味です。しかし、リスト
の下に進めばわかるように、多くのバンドルではヒット数がそれほど高くないにもかかわらず、1 つのバンドルでヒット数
の約 15%が占められています。このバンドルでは、以前に行われたアドバンスドロードに対してチェック命令を実行して
います。このチェック命令が失敗した場合、そのチェック命令で指定されたシンボルに分岐します。
23
------------------------------------------------------------------------------Section 3.0: Virtual Memory, Ram Usage, and Asynchronous I/O Activity
------------------------------------------------------------------------------Process(09925) has 45 Address Spaces -- Sorted by Virtual Address
Preg
Type
Virtual Min Max
page Size Size
Min
RSS
Max
RSS
Max
Shr
NULLPG
00000
1
1
1
TEXT
04000 491 491
4
/home/tdf/povray31/source/unix/
1
283
95
2
DATA
40000
22 544
1
/home/tdf/povray31/source/unix/
432
1
Profl Uniq File associated with region
Secs Inst
181.15
x-povray
x-povray
LIBBSS
LIBBSS
LIBBSS
LIBBSS
LIBDAT
797ab
797ae
797b0
797b2
797b4
3
2
2
2
1
3
2
2
2
1
1
1
1
1
1
1
2
2
2
1
1
1
1
1
1
LIBDAT
LIBDAT
797b5
797b6
1
1
1
1
1
1
1
1
1
1
/opt/graphics/OpenGL/lib/
hpux32/libogltls.so.2
/usr/lib/hpux32/libuca.so.1
/usr/lib/hpux32/libdl.so.1
24
付録 B： Prospect と Caliper によるチューニング
付録 A の Prospect 出力を見れば明らかなように、このアプリケーションにはチューニングの余地があります。問題は、そ
の余地がどの程度かということです。それを判断するために、まず、CPU の機能停止時間を調べます。機能停止時間は、
PMU を読み取るツールで収集されたデータを利用して簡単に計算できます。この例では、Caliper を使います。Caliper
にはこれを測定する構成ファイルがないため、構成ファイルをコピーして、BACK_END_BUBBLE_ALL と CPU_CYCLES を
カウントするように変更する必要があります。このために最も簡単に変更できるのは、標準的な“total_cpu”構成ファイル
です。構成ファイルの作成、変更、および使用方法については、Caliper ユーザー マニュアルを参照してください。これら
のイベントを測定すると、次のような結果が得られます。
BACK_END_BUBBLE_ALL =170702979670
CPU_CYCLES = 264510801093
Stall fraction = BACK_END_BUBBLE_ALL/CPU_CYCLES = 64.5%
この結果では、長い時間何も行われないように思われます。Intel Itanium プロセッサ上の機能停止すべてについて、分
岐予測ミス、キャッシュ ミス、レジスタ間依存関係、RSE などのより高いレベルの機構に遡って追跡することができます。
また、少数の基本的関係を調べれば、追跡範囲をさらに絞り込むことができます。まず、Itanium プロセッサ上の機能停
止の最も大きい原因であるデータ キャッシュ ミスを調べる必要があります。データ キャッシュ ミスは、効果的でないプリ
フェッチングによって生じます。これを簡単に調べるには、L1D_READ_MISSES_ALL、L2_MISSES、L3_MISSES（および、
場合によっては L3_WRITES_L2_WB_ALL）を測定してライトバックに関する情報を得る必要があります（ライトバックとは、
より高いレベルのキャッシュまたはメモリを更新して、“DIRTY”とマークされた現在のレベルでの一部のエントリを解放す
る処理です）。このコードでは、次のデータが得られます。
L1D_READ_MISS_ALL = 13060930 = 42K/秒
L2_MISSES = 1655391789 = 5.4M/秒
L3_MISSES = 1574255645 = 5.1M/秒
L3_WRITES_L2_WB_ALL = 1277786877 = 4.2M/秒
これらの値はすべて、機能ユニットにデータを提供するプロセッサの能力に納まりますが、 L3_MISSES ~= L2_MISSES
~= L3_WRITES_L2_WB_ALL であることに注意する必要があります。これは、メモリにライトバックしなければならないダ
ーティ ミスが L2 に数多く存在するという意味です。
したがって、キャッシュ ミス率が高いことが問題なのではありません。また、これはバスの帯域幅が飽和していないことも
意味します。次に調べる項目は、レイテンシが高い命令です。 “sample_ip” (11.22) または“fprof” (11.23) 構成ファイ
ルを使えば、Caliper で簡単に調べることができます。これで、次のような Prospect に似た出力（抜粋）が得られます。
CPU Metrics Summed for Entire Run
------------------------------------------Counter
Priv. Mask
Count
------------------------------------------INST_DISPERSED
8 (USER) 410704974250
NOPS_RETIRED
8 (USER) 173519932252
CPU_CYCLES
8 (USER) 263949955303
------------------------------------------CPI:
0.6427 = CPU_CYCLES / INST_DISPERSED
Useful CPI:
1.1128 = CPU_CYCLES / (INST_DISPERSED - NOPS_RETIRED)
Percent Nops:
42.25 = 100 * (NOPS_RETIRED / INST_DISPERSED)
-------------------------------------------
最初の部分は、興味深い CPU 測定値を示しています。Intel Itanium 2 プロセッサでの最大値が 1/6 (0.1667) であるこ
とを考えれば、0.6427 という生の CPI（命令ごとのサイクル数）はかなり良い数値といえます。有効な CPI は、NOP 命令
数が多いため相当低くなります。実行される有効な命令が他にない場合、NOP 命令がバンドルに追加されます。これは、
依存関係に大きな問題があることを意味します。ポインタ追跡がこの動作を示しています。
25
リストのさらに下には、Prospect よりも詳しく関数ごとのヒット数を示すセクションがあります。
Function Details for pi_css5
------------------------------------------------% Total
Line|
IP
IP
Slot| >Statement|
Samples
Samples Col,Offset Instruction
------------------------------------------------18.76
[mp_mul_d2i(int,int,int,double*,int*), 0x400e4c0, pi_fftcs.c]
99050
~1471 Function Totals
-----------------------------------------[pi_fftcs.c]
1
~1511 >
for (j = ndata; j > 1; j--)
1 ~5,0x06b0:0
setf.sig
f11=r9 ;;
:1
nop.m
0
:2
nop.i
0
633
~1513 >
x = d1_radix2 * (scale * din[j - shift]
+ carry + 0.5);
633 ~3,0x0720:0
ldfd
f9=[r10],-8
:1
lfetch
[r20],12
:2
sxt4
r9=r9
52396
~1514 *>
carry = carry2;
608 ~3,0x0730:0
lfetch.nt1 [r8],-16 ;;
:1
setf.sig
f11=r9
:2
cmp.lt
p6,p0=r9,r0
1235 ~3,0x0740:0
ldfd.a
f6=[r10],-8 ;;
:1
nop.m
0
:2
nop.i
0
~ ~ ~ ~ ~ ~ ~ ~
3793 ~3,0x0760:0
nop.m
0
:1
nop.m
0
:2
fma.d
f11=f11,f1,f0 ;;
2476 ~3,0x0770:0
nop.m
0
:1
nop.m
0
:2
fma.d
f9=f12,f9,f11 ;;
2467 ~3,0x0780:0
nop.m
0
:1
nop.m
0
:2
fma.d
f9=f9,f1,f14 ;;
2543 ~3,0x0790:0
nop.m
0
:1
nop.m
0
:2
fma.d
f9=f13,f9,f0 ;;
2562 ~3,0x07a0:0
nop.m
0
:1
nop.m
0
:2
fcvt.fx.trunk f11=f9 ;;
6899
~1516 >
x = radix * (x - carry2);
5660 ~3,0x07b0:0
getf.sig
r9=f11
:1
nop.i
0 ;;
:2
adds
r9=-1,r9 ;;
1239 ~3,0x07c0:0
nop.m
0
:1
sxt4 r14=r9 ;;
:2
cmp.lt
p6,p0=r14,r0
ここでは、ソース行ごとにヒット数が示され、次に命令バンドルごとに分類されています。高度に最適化されたコードでは、
ソース行番号はおおよその番号です。この例では、ソース行番号は 1 つおきです。行 1514 (carry = carry2) は後続の
命令バンドルと一致しませんが、行 1513 は一致します。また、この例ではパフォーマンス問題の原因がはっきりとわか
ります。各バンドルには有効な命令が 1 つしかなく、各バンドルごとにストップ ビットがあります（バンドル内の 3 番目の命
令に続く「;;」で表される）。ストップ ビットは、そのサイクルで命令ディスパーサルを停止するように指示します。これは、
ディスパーサル段階でサイクルごとに 2 つのバンドルの一方のみ発行されるという意味です。また、このセクションでは
連続した浮動小数点レジスタ依存関係があることもわかります。浮動小数点演算はそれぞれ直前の演算に依存してい
ます。これによって、パイプラインのバックエンドが機能停止します。このコードをチューニングするには、さらに並列性を
高めるようにアルゴリズムを変更する必要があります。
26
付録 C： 参考情報ガイド
HP のシステム＆VLSI テクノロジ部門の社外向け Intel Itanium アーキテクチャ ホーム ページ：
www.cpus.hp.com/technical_references/ia64.shtml#McKinley
CERN の Sverre Jarp による IA-64architecture: A Detailed Tutorial： http://nicewww.cern.ch/~sverre/IA64_1.pdf
Intel Itanium チュートリアル： www.intel.com/design/itanium/tutorials.htm
Intel Itanium プロセッサ ファミリ ホーム ページ： http://developer.intel.com/design/itanium/family
（日本語ページ： http://www.intel.co.jp/jp/developer/design/itanium/family/index.htm）
HP 開発者とソリューション パートナ プログラム Intel Itanium アーキテクチャ ホーム ページ：
http://h21007.www2.hp.com/dspp/topic/topic_PETechnologyDetailPage_IDX/1%2c2603%2c10402%2c00.ht
ml
HP-UX 11i のリリース名とリリース ID
HP-UX 11i で、HP は、エンドツーエンド インターネットに欠かせないコンピューティングの需要に応える、可用性が高く安
全で管理可能なオペレーティング システムを実現しました。HP-UX 11i は、エンタープライズ環境、ミッションクリティカル
な環境、および技術コンピューティング環境をサポートします。HP-UX 11i は、PA-RISC システムと Itanium ベース システ
ムの両方で利用可能です。
それぞれの HP-UX 11i リリースにはリリース名とリリース識別子が付けられています。uname (1) コマンドを –r オプショ
ンで実行すれば、リリース識別子が返されます。次の表は、HP-UX 11i の入手可能なリリースを示しています。
HP-UX 11i の各リリース
リリース名
リリース ID
サポートされているプロセッサ アーキテクチャ
HP-UX 11i v1
B.11.11
PA-RISC
HP-UX 11i v1.6
B.11.22
Intel Itanium
HP-UX 11i v2
B.11.23
Intel Itanium
お問い合わせはカスタマー インフォメーションセンターへ
03-6416-6660
月∼金9:00∼19:00 土10:00∼18:00 （日、祝祭日、年末年始および5/1を除く）
HP-UX製品に関する情報は
http://www.hp.com/jp/hpux
Intel、インテル、Intel Inside ロゴ、Itaniumは、米国におけるIntelCorporationまたは
その子会社の商標または登録商標です。
Microsoft、WindowsおよびWindows NTは、米国におけるMicrosoft Corporationの登録商標です。
記載されている会社名および商品名は、各社の商標または登録商標です。
記載事項は2003年9月現在のものです。
本書に記載された内容は、予告なく変更されることがあります。
本書中の技術的あるいは校正上の誤り、省略に対して、
いかなる責任も負いかねますのでご了承ください。
本書は、『Intel® Itanium® Processor Family performance tuning guide (5981-7114EN, 05/2003) 』（英語）をもとに
日本語で提供するものです。
© Copyright 2003 Hewlett-Packard Development Company,L.P.
日本ヒューレット・パッカード株式会社
〒140-8641 東京都品川区東品川2-2-24 天王洲セントラルタワー
PDFHS03-009-01