Comments
Description
Transcript
SPARC T4プロセッサのスループット最適化：ケース・スタディ
Oracleテクニカル・ホワイト・ペーパー 2012年4月 SPARC T4プロセッサのスループット最適化： ケース・スタディ SPARC T4プロセッサのスループット最適化：ケース・スタディ 概要 ..................................................................................................................................... 1 パフォーマンス結果のサマリー ......................................................................................... 4 プログラムCSP1とCSP2のパフォーマンス特性 ............................................................... 4 UltraSPARC T2+のパイプライン・アーキテクチャ ..................................................... 5 UltraSPARC T2+プロセッサでのプログラムCSP1に対する命令スケジューリングの分 析 ................................................................................................................................... 6 UltraSPARC T2+プロセッサでのプログラムCSP2に対する命令スケジューリング分析 ....................................................................................................................................... 9 UltraSPARC T2+のパフォーマンス結果 ........................................................................... 10 テスト・フレームワーク ............................................................................................. 10 CSP1プログラムに対するUltraSPARC T2+のパフォーマンス結果 ............................ 11 CSP2プログラムに対するUltraSPARC T2+のパフォーマンス結果 ........................... 12 SPARC T4のパフォーマンス結果 .................................................................................... 13 SPARC T4コア・アーキテクチャの概要 .................................................................... 13 テスト・フレームワーク ............................................................................................. 15 SPARC T4プロセッサでのCSP1プログラムに対するサイクル数の見積りとパフォーマ ンス結果 ...................................................................................................................... 15 SPARC T4プロセッサでのCSP2プログラムに対するサイクル数の見積りとパフォーマ ンス結果 ...................................................................................................................... 17 謝辞 ................................................................................................................................... 18 参考資料............................................................................................................................ 19 著者について .................................................................................................................... 19 0 SPARC T4プロセッサのスループット最適化：ケース・スタディ 概要 このホワイト・ペーパーでは、オラクルのUltraSPARC T2+プロセッサとSPARC T4プロセッサに実 装されたレイテンシ隠蔽 (latency hiding) についての実証を行います。 レイテンシとは、要求が送信されてからその結果が提供される瞬間までの時間遅延を指します。こ のような遅延はコンピュータ・システム内の多数のコンポーネントで見受けられ、パフォーマンス に多大な影響を及ぼす可能性があります。 本書では、プロセッサ・サイクルで表されることの多い命令レベルのレイテンシに焦点を合わせて 説明します。多くの命令には決まったレイテンシが含まれますが、実行時の条件やデータ型の形式 によってレイテンシが異なる命令もあります。 その一例に、メモリからデータをフェッチするロード命令があります。データが一次レベルのデー タ・キャッシュにある場合、アクセス時間はわずか数プロセッサ・サイクルになります。しかし、 メイン・メモリなどのシステム内の離れた個所からデータをフェッチする場合、数百サイクルもか かる場合があります。 レイテンシに関する問題は、プロセッサの実行パイプラインにいわゆるギャップやバブルが作り出 される点です。この場合、命令の完了をプロセッサが待機する間、たとえば、ロード命令によって データがフェッチされるまでの間、サイクルが無駄に消費されます。これによってアプリケーショ ン・パフォーマンスが低下するだけでなく、一定の時間あたりに完了できるジョブ数が少なくなる ことでシステム・スループットが低下します。 幸い、多くの場合で、レイテンシを短縮するためのハードウェア機能とソフトウェア最適化手法が 提供されています。キャッシュがその良い例です。頻繁に使用されるデータをキャッシュ内に維持 することで、アクセス時間は短縮されます。 1 SPARC T4プロセッサのスループット最適化：ケース・スタディ キャッシュの使用に加えて、 プリフェッチ と呼ばれるメカニズムを通じてメモリ・システムのパ フォーマンスはさらに向上します。プリフェッチを使用すると、使用が予想される時点より先にプ ロセッサがデータをフェッチし、キャッシュなどの高速ストレージに配置します。このアクション は通常、プロセッサ内の別のアクションとオーバーラップします。比較的離れた場所にデータがあ り、アクセスにコストがかかる場合に、プリフェッチはもっとも効果的です。 プリフェッチによってロード命令によるコスト（の一部）が隠されると、レイテンシが短縮されま す。正味のメリットは、ロード命令がデータをフェッチする際のレイテンシが短縮されることです。 この機能は最近のプロセッサの多くに実装されており、一般に レイテンシ隠蔽と呼ばれる機能の一 例になります。 しかし、これらの機能や手法による影響が限定的であるか、または、そもそもうまく適用できない 場合はどうなるでしょうか。 たとえば、アプリケーションのメモリ・アクセス・パターンが不規則である場合はどうでしょうか。 データ・アクセス・パターンが存在しないため、キャッシュによるメリットは限定され、プリフェッ チでパターンを検出することもできません。また、コンパイラを最適化してこの状況を修正するこ ともできません。このため、ロード命令に長い時間がかかり、データの到着を待つ間にプロセッサ は多数のサイクルを消費する結果となります。 もしくは、一定ではあっても長い待機時間を持つ命令（除算など）が使用されており、完了までに 多大なサイクル数を消費する場合はどうでしょうか。これらは、うまく適用できない2つの例となり ます。パフォーマンスとスループットの低下を受け入れる以外に方法はありません。 あるいは、何らかの解決策が存在するのでしょうか。 これらのギャップを使用して、別のアプリケーションまたは同じアプリケーションの別スレッドの 命令を実行してはどうでしょう。こうすることで、プロセッサ・サイクルの浪費がなくなり、全体 的なシステム使用率が向上します。 2 SPARC T4プロセッサのスループット最適化：ケース・スタディ これこそが、オラクルのSPARC Tシリーズ・プロセッサが当初から実行してきたレイテンシ隠蔽で す。 ここからは、アプリケーション・レベルでの仕組みについて、また、ハードウェアが（アプリケー ションやユーザーに気付かれることなく）使用可能なプロセッサ・サイクルを自動的に最大活用し、 合計システム・スループットを向上する方法について説明します。 3 SPARC T4プロセッサのスループット最適化：ケース・スタディ パフォーマンス結果のサマリー このホワイト・ペーパーのため、一連のパフォーマンス・テストが実施されました。テストでは、C で記述された2つの整数プログラムが使用されました。 これらのテストの目的は、UltraSPARC T2+プロセッサとSPARC T4プロセッサに実装されたレイテン シ隠蔽機能を実証することです。 最初のプログラムはCSP1であり、毎回最小限の処理を行う小さなループが含まれています。 UltraSPARC T2+プロセッサでは、命令スケジュールの大半が、分岐命令で必要になる6～7のプロセッ サ・サイクルによって占められています。このため、パイプライン内にアイドル・サイクルが発生 します。 大幅な設計上の改善がいくつか実施されているため、SPARC T4プロセッサの命令スケジュールでは このようなギャップが発生しません。この改善によって、SPARC T4プロセッサ上でCSP1を実行した 場合のシングルスレッド・パフォーマンスは、UltraSPARC T2+プロセッサ上の8.5倍になりました。 2番目のプログラムはCSP2であり、そのパフォーマンスは整数減算命令のコストによって左右されま す。整数減算命令は両方のプロセッサで1サイクルを占めます。プログラムにデータ依存性があるた め、各スレッドで1サイクルあたりに実行できる整数減算は1つのみになります。つまり、アプリケー ションは、SPARC T4プロセッサの二重命令実行機能を活用できません。したがって、SPARC T4プ ロセッサでのパフォーマンス向上はクロック速度の増加のみに比例したものになります。 両方のプログラムに対して、単一プログラムの実行パフォーマンスが評価されただけでなく、同じ プログラムのコピーを同時に複数実行した場合のスループット・パフォーマンスが計測されました。 テストは、コピーの数を増やすことでワークロードを増加しながら実施されました。 スループット結果は一見、必ずしも予想と一致しませんが、コンパイラによって生成されたアセン ブリ・コードとプロセッサ・アーキテクチャを考慮に入れると、すべての測定結果は予想どおりで あることが分かります。 最大16個の同時コピーに対して、UltraSPARC T2+プロセッサ内の16のパイプラインが各コピーを実 行するために使用されました。これを超えると命令スケジュールのギャップが徐々に解消されてい き、システム使用率の向上がもたらされます。結果的に、全体的なプロセッサ使用率が向上し、コ ピー数の増加に比例まではしないものの、合計ワークロード時間も増加します。64個のコピーを実 行するとすべてのギャップが解消され、これ以降は負荷の倍増に伴って実行時間が線形に増加しま す。 SPARC T4プロセッサではスケジュール内にギャップは発生しておらず、CSP1のコピーを1個から8 個まで実行した場合の実行時間は同じになります。これは、プロセッサ内のパイプライン間で負荷 が分散されているためです。これ以降では、ワークロードの合計実行時間は同時実行されるコピー の数に比例して増加します。 両方のプロセッサにおいて、CSP2プログラムの実行スケジュールではギャップがほとんど発生しま せん。データ依存性があるため、各スレッドで1クロック・サイクルあたりに出力される結果は1つ だけになります。両方のケースにおいて、最大16個までのコピーに対する同時実行で使用される1コ ピーあたりのプロセッサ・サイクル数は同じです。しかし、SPARC T4プロセッサのクロック速度は 格段に高速であるため、合計時間はこのプロセッサを使用した方がずっと短くなります。さらに負 荷を高くすると、実行時間は実行されたコピー数に応じて線形に増加します。 プログラムCSP1とCSP2のパフォーマンス特性 SPARC Tシリーズのすべてのプロセッサに共通する重要なアーキテクチャ上の特徴の1つに、マルチ 4 SPARC T4プロセッサのスループット最適化：ケース・スタディ サイクル1命令のレイテンシを極めて効率的に隠蔽する機能があります。この際、通常はアイドル状 態にある命令スロットが、同じアプリケーション内の別のプロセス（またはスレッド）の命令で使 用されます。 これは動的な処理であり、アプリケーションやオペレーティング・システムに対して透過的に実行 されます。たとえば、要求されたデータ項目がコアのL2データ・キャッシュにない場合、離れたメ モリ階層からデータを取得する必要があります。この場合、より伝統的な設計では、データの到着 を待機する間、プロセッサがアイドル状態になります。SPARC Tシリーズのプロセッサでは、その 他のプロセスやスレッドがこのアイドル・サイクルを使用できます。 実現されるパフォーマンス向上レベルは、実行されるアプリケーションの命令特性によって異なり ますが、すべてのパイプラインを常にビジーにできるアプリケーションはほとんどないため、大半 のワークロードに対して、プロセッサの合計スループットは向上します。 CSP1とCSP2という2つのCプログラムは、SPARC Tシリーズのプロセッサが持つこの命令レイテンシ 隠蔽機能を実証するものです。両方のプログラムはwhileループ構造内で同じタイプの整数減算を実 行していますが、異なる方法で実装されています。 テストの結果から、実装が異なることで、明らかに異なるパフォーマンス特性が引き出されている ことが分かります。 UltraSPARC T2+のパイプライン・アーキテクチャ 両プログラムに対する命令スケジューリングの分析とパフォーマンス結果を提示する前に、 UltraSPARC T2+プロセッサのパイプライン・アーキテクチャ［1］［2］について簡単に要約します。 UltraSPARC T2+プロセッサには8つのコアが搭載されています。各コアに2つの整数実行パイプライ ンが実装されており、それぞれのパイプラインが4つのスレッドをサポートしています。また、追加 で2つのパイプラインが実装されており、1つは浮動小数点/グラフィック命令向けであり、もう1つは メモリ操作のロード/ストア向けパイプラインです。ただし、これらのパイプラインはコア内の8つの スレッド間で共有されています。本書では、調査の目的上、整数パイプラインに焦点を合わせてい ます。 図1に、UltraSPARC T2+プロセッサの部分的なブロック図を示します。 1 クロック周波数が1GHzのプロセッサでは、1サイクルに1ナノ秒（10-9秒）かかります。 5 SPARC T4プロセッサのスループット最適化：ケース・スタディ 図1 UltraSPARC T2+の命令処理とパイプライン構造 命令フェッチ・ユニットがスレッドを選択し、命令キャッシュにフィードします。このキャッシュ には2つの命令バッファ（IB）セットが接続されています。それぞれのセットが4つの異なるスレッ ドをサポートしているため、合計で8つのスレッドがサポートされます。 2つの選択(セレクト)ユニットが、それぞれのセット（スレッド・グループと呼ばれる）から1つのス レッドを選択します。レディ状態にあるスレッドのみを対象として、Least Recently Fetched（LRF） アルゴリズムに基づいて選択されます。 次に、該当するIBの命令がデコードされます。これは、スレッド・グループごとに1つのスレッドに 対して実行されます。次に、2つの命令が実行ユニット0（EX 0）と実行ユニット1（EX 1）に送信さ れ、処理が続行されます。 この設計では、合計16の整数パイプライン（それぞれ2つの整数パイプラインを実装した8つのコア） によって64のスレッド実行に対するハードウェア・サポートが提供されています。 UltraSPARC T2+はイン・オーダー・アーキテクチャに従っている点に注意してください。つまり、 命令は、プログラムに指定された順序でフェッチ、デコード、発行、および実行されます。オペラ ンドが使用可能になった時点（おそらくは待機した後）で、命令は実行されます。命令が完了する と、結果がレジスタに書き込まれます。 これらのパイプラインは、1サイクルごとに1つの命令を実行します（単一発行）。言い換えると、 各パイプラインでのサイクルあたりの実行命令数（IPC）の最大値は1になります。 UltraSPARC T2+プロセッサでのプログラムCSP1に対する命令スケジューリングの分析 CSP1プログラムのソース・コードにおける主要部分は、次のループで構成されています。 6 SPARC T4プロセッサのスループット最適化：ケース・スタディ このプログラムは、Oracle Solaris Studio Cコンパイラ［3］で有効化されている最適化をまったく使 用せずにコンパイルされましたが、一般には、最適化の使用が推奨されています。コンパイラでコー ドを最適化しない場合、大幅なパフォーマンス低下を招く可能性が高いためです。 ここでは、単純なループを使用した場合の動作を強調するために、このコードが使用されています。 コンパイラで使用できる最新の最適化を適用した場合でも、コンパイラはループを実行せずに静的 に結果を決定するため、ループ全体が除外されます。 上記のCSP1内のループは、次の連続した4つの命令に解釈されます。 .L21: sub cmp bg nop %i4,1,%i4 %i4,0 .L21 UltraSPARC T2+プロセッサでは、整数減算（sub）命令と比較（cmp）命令でそれぞれ1サイクルが消 費されます。分岐（bg）命令には6～7サイクルが使用されます。サイクル数が1つの数値にならない 理由は、コアの命令処理部分の状態によって、コストが7サイクルになる場合があるためです。 bg命令後の遅延スロットを埋めるため、何もしない（nop）命令が分岐の後に使用されます。分岐遅 延スロットはSPARC命令セット・アーキテクチャによって必要とされるものであり、このケースで は先行の命令に関係なく常に実行されます。nop命令はループ全体の一部とみなされますが、分岐コ ストのサイクルが余分に追加されることはありません。その他のスレッド（またはプロセス）から の命令がある場合、パイプラインは分岐の直後にこれらを実行します。 UltraSPARC T2+プロセッサが持つこれらの命令特性の結果として、CSP1プログラム内のループを1 回通過するごとに8～9サイクルがスケジュールによって使用されます。 UltraSPARC T2+のパイプラインが発行できる命令はクロック・サイクルごとに1つであるため、上記 ループはおおよそ図2に示すとおりに実行されます。この図では、分岐命令が7サイクルを使用する としています。 図2 1つのCSP1プログラムに対するUltraSPARC T2+の単一パイプラインの使用図 7 SPARC T4プロセッサのスループット最適化：ケース・スタディ "サイクル"という名前を付けた1行目は、経過時間をプロセッサ・サイクル数で表しています。2行目 （"命令"）には実行された命令が記載されています。最後の行（"使用"）はパイプライン全体での使 用状況を示しています。薄緑色はスロットが使用可能であることを意味し、濃いオレンジ色は該当 サイクルでは命令が発行されていないことを意味します。 この図から分かるとおり、このパイプラインでは9サイクルのうち5サイクル（56%）が使用されてい ません。 前述のとおり、SPARC Tシリーズ・プロセッサには、複数のプロセッサまたはスレッドを極めて効 率的に同時実行できるという重要な特徴があります。プロセスの命令特性や実行特性によってアイ ドル状態になったサイクルは、その他のプロセスによって使用されます。こうすることでパイプラ イン使用率が最大化されます。 たとえば、同じパイプライン上でCSP1の2個のコピーを実行したとすると、実行スケジュールは図3 のようになるでしょう。この図は、Least Recently Fetched（LRF）スレッド・スケジュールを適用し たものです。 図3 2つのCSP1プログラムに対するUltraSPARC T2+の単一パイプラインの使用図 2個のコピー（または同じ並列アプリケーション内のスレッド）を同時に実行すると、パイプライン をより効率的に利用できるようになります。2個のコピーの実行にかかる時間は11サイクル（22%増） になりましたが、アイドル時間は27%に減少しました。言い換えると、11サイクルの各時間枠のうち、 別のコピー（または別のアプリケーション）が利用できるスロットがまだ3つ残っています。 ここで注意すべきは、この処理がアプリケーションに対して透過的に行われ、アクティブ・スレッ ド間での切替えによる悪影響はないという点です。すべてはハードウェアで処理され、ユーザー・ アクションは必要ありません。 さらに密度の高いスケジュールを生成することもできます。cmp %i4,0命令は合成命令であり、subcc （条件コードの減算と変更）命令にマッピングされます。ここでは、subcc %i4,0,%g0命令を意味しま す。 sub命令とcmp命令を組み合わせることができ、必要なsubcc命令は1つだけであるため、結果のスケ ジュールは次のようになります。 .L21: subcc bg nop %i4,1,%i4 .L21 8 SPARC T4プロセッサのスループット最適化：ケース・スタディ これによって、UltraSPARC T2+プロセッサのサイクルを1つ節約できます。ただし、最適化が有効化 されていないため、この高密度なスケジュールがコンパイラによって生成されることはありません。 UltraSPARC T2+プロセッサでのプログラムCSP2に対する命令スケジューリング分析 2番目のプログラムCSP2もCSP1と同じ計算を実行しますが、パフォーマンス特性が異なります。こ のプログラムはループ・アンローリングを使用して複数処理を実行することで、分岐命令のコスト を軽減しています。 ここで、ループは16 x 32 = 512の深さまで展開されています。該当するコード部分を次に示します。 いくつかの同じ行の表示は省略されています。 このCコードに対する一連の命令は次のようになります（いくつかの同じ命令の表示は省略されてい ます）。 図4に、1つのCSP2に対する命令実行スケジュールを示します。ここでは、コンパイラは%i4（CSP1 で使用）の代わりに%i5を使用しています。この選択によるパフォーマンスへの影響はありません。 9 SPARC T4プロセッサのスループット最適化：ケース・スタディ 上記の命令では、減算命令に対して512サイクルが使用され、比較および分岐命令に対して7～8のサ イクルが追加で使用されます。したがって、CSP2の展開ループにおける理論上の最大パフォーマン スは、1回の整数減算あたりで520/512 = 1.015サイクルになります。それぞれの減算命令は直前の計 算結果に依存するため、ループを書き直さない限り、どのようなパイプラインを使用してもこれ以 上高速に実行することはできません。 図4 1つのCSP2プログラムに対するUltraSPARC T2+の単一パイプラインの使用図 図4から、CSP2プログラムでは、ほとんどすべてのパイプライン・スロットが自動的に使用されてい ることが分かります。アイドル状態にあるスロットがほとんどないため、その他のコピーがアイド ル・スロットを使用する余地はあまり残されていません。たとえば、2番目のコピーで、最初のコピー が残したわずか5つのアイドル・サイクルを使用することもできますが、2つのコピーの合計時間が 1,040サイクルから1,030サイクルに短縮されるだけであり、これはわずか1%の節約にすぎません。 UltraSPARC T2+のパフォーマンス結果 この項では、UltraSPARC T2+プロセッサに対するテスト・フレームワークとパフォーマンス結果に ついて説明します。 テスト・フレームワーク ここでは、クロック周波数1,580MHzのプロセッサを備えたUltraSPARC T2+システム上で測定された パフォーマンス結果を示します。 テスト時間を増加してタイミングの精度を上げるため、繰返しメカニズムが使用されています。CSP1 とCSP2に対して使用されたタイミング・フレームワークは、次のとおりです。 カーネルのみの合計時間を測定した後で、"--i"文の実行時間がプロセッサ・サイクルに変換されました。 スループット・テストでは、1、2、4、8、16、24、32、48、56、64、128、および256個のプログラ ム・コピーが同時に実行されました。 10 SPARC T4プロセッサのスループット最適化：ケース・スタディ テストで使用されたUltraSPARC T2+システムには4つのプロセッサが搭載されていましたが、プロ セッサ・セットを使用することで、1つのプロセッサのみが使用されるようにしました。4つのプロ セッサすべてを使用した場合も、同様の結果が得られます。 CSP1プログラムに対するUltraSPARC T2+のパフォーマンス結果 図5は、CSP1プログラムのコピーを同時実行した際、UltraSPARC T2+システムで測定された"--i"文の 実行時間をグラフにしたものです。この時間はプロセッサ・サイクルで表されており、ループによ るオーバーヘッド・コスト（比較命令と分岐命令のコストなど）を含んでいます。つまり、これら は"i"の値が1つ減少する間のサイクル数を示しています。 図5 同時実行されたCSP1のコピー数に応じたUltraSPARC T2+の単一プロセッサ上でのプロセッサ・サイクル数。注：両軸は対数目盛りであり、縦 軸の初期値は8。 それぞれのテストに対する個別の結果が提供されています。つまり、単一コピーの場合は1つのタイ ミング結果が、2つのコピーの場合は2つの結果が、4つのコピーでは4つの結果が提供されています。 UltraSPARC T2+プロセッサには16の整数パイプラインが実装されているため、16個までのコピーに 対するパフォーマンスが同じ（9クロック・サイクル）であることは驚くには当たりません。Oracle Solarisのスケジューラは、各コアに対して均等にコピーを分散します。基本的に、16のパイプライン それぞれが図2に示したように使用されます。 負荷を増やして24個の同時コピーを実行すると、負荷の不均衡が生じます。この場合、8つのパイプ ラインは1つのコピーを実行しますが、残り8つのパイプラインは2つのコピーを実行する必要があり ます。このため、2つの異なる値が表示されています。図3で説明したとおり、1つのパイプラインを 共有する2つのコピーは、終了までに11サイクルを使用します。 11 SPARC T4プロセッサのスループット最適化：ケース・スタディ 32個のコピーに対するワークロードでは、すべてのパイプラインがバランスの取れた同じ方法で使 用されるため、各コピーの実行にかかる時間は再び等しくなります。サイクル数は12に増えていま すが、これは、プロセスがハードウェア・スレッドにバインドされていないために発生したオペレー ティング・システムのコンテキストスイッチによるものと考えられます。 図3で示したとおり、活用できるアイドル・サイクルはまだ残されており、48個のコピーを同時実行 する場合が明らかにこれに該当します。負荷は50%増えますが（32個から48個のコピーへ）、各コピー の実行時間は増加しません。これは、命令レイテンシ隠蔽が機能しているためです。 56個のコピーまで負荷が増えると、一部のコピーに他よりも長い時間がかかっていることが分かり ます。これは、再度、負荷の不均衡が発生しているためです。ここで、8つのパイプラインはそれぞ れ3つのコピーを実行しますが、残り8つのパイプラインは4つのコピーを実行する必要があります。 64個のコピーになると再び負荷が均等に分散され、パイプラインに残された使用可能なギャップが なくなるため、サイクル数は16に増えます。 これ自体が、SPARC Tシリーズのアーキテクチャの強みを実証しています。コピー数が64個の高負 荷では、合計実行時間が16/9 = 1.78倍にしか増加していません。 グラフから分かるとおり、64個以上に負荷が増えるとパフォーマンスは線形に増加します。負荷を 倍増して128個の同時コピーを実行するとサイクル数は32に増え、さらに倍増して256ジョブにする と、サイクル数は64になります。 グラフ内には指標が不明確に見える個所がいくつかあります。これは、同じテスト（128個の同時コ ピーなど）に対するサイクル数がわずかに異なる場合があり、すべての値がグラフに記載されてい るためです。UltraSPARC T2+プロセッサ上では、パイプラインの状態によって分岐命令が6～7サイ クルかかることを思い出してください。 さらに、負荷が増えるに従ってパイプラインが（過度に）オーバーサブスクライブされるため、オ ペレーティング・システムのコンテキストスイッチが発生します。このため、時には同じテストの 結果として複数のサイクル数が生じるのも当然です。ただし、すべてのケースにおいてその違いは 10%未満にとどまります。 CSP2プログラムに対するUltraSPARC T2+のパフォーマンス結果 図6は、CSP2プログラムのコピーを同時実行した際、UltraSPARC T2+プロセッサ上で測定された"--i" 文の実行時間をグラフとして表したものです。実行時間はプロセッサ・サイクルで表されており、 この数字にはループ・オーバーヘッドが含まれています。CSP1プログラムと同様に、各テストに対 するすべてのタイミング結果がグラフに記載されています。 測定されたパフォーマンスは、予想どおりの単純明快なものです。コピー数が16になるまでは各コ ピーが1つのパイプラインを独占できるため、予想どおり、アンロールされたループ内で変数"i"の値 が1つ減るごとに1サイクルが消費されるという結果が実際に得られました。 スケジュール内には事実上、アイドル・サイクルが存在しないため、16の倍数のコピーに対してパ フォーマンスは線形に増加します。たとえば、32個のコピーには2倍の時間がかかり、48個のコピー には3倍の時間がかかります。 12 SPARC T4プロセッサのスループット最適化：ケース・スタディ 図6 同時実行されたCSP2のコピー数に応じたUltraSPARC T2+の単一プロセッサ上でのプロセッサ・サイクル数。注：両軸は対数目盛り。 CSP1の場合と同様に、コピー数が16の倍数でない場合は負荷の不均衡が発生します。その結果とし て、一部のパイプラインで実行されるコピー数が異なるため、すべてのタイミングが同じ結果には なりません。 実際のところ、16個以上のコピーに対して実行時間が線形に増加しているという事実は注目に値し ます。通常、プロセッサに過度の負荷がかかるとパフォーマンスは低下し始めますが、ここではそ のような結果は認められません。コピー数が倍増するたびに、実行時間も倍増しています。パイプ ラインごとに16個のCSP2を実行するという高いワークロードにもかかわらず、コピー数が256に達す るまでこの結果は続いています。 SPARC T4のパフォーマンス結果 この項では、はじめにSPARC T4コア・アーキテクチャの概要について、続いてテスト・フレームワー クについて説明します。その後、SPARC T4プロセッサのパフォーマンス結果を示し、考察を提供し ます。 SPARC T4コア・アーキテクチャの概要 SPARC T4のコア・アーキテクチャ［4］は新しく設計されており、UltraSPARC T2+のコア・アーキ テクチャとは大きく異なります。おもな改良点には、SPARC T4パイプラインは1サイクルで最大2つ の命令を実行可能（2ウェイスーパースカラー）であること、命令はアウト・オブ・オーダーで実行 されることの2点があります。つまり、レイテンシの長い命令によって、依存関係のない後続命令が ブロックされることがなくなります。 1個のUltraSPARC T4プロセッサには8つのコアが搭載されています。それぞれのSPARC T4コアで8ス レッドがサポートされており、2つの整数パイプライン、1つのロード/ストア・パイプライン、およ び1つの浮動小数点/グラフィックおよび暗号化命令向けパイプラインが実装されています 13 SPARC T4プロセッサのスループット最適化：ケース・スタディ 図7に、SPARC T4アーキテクチャの（部分的な）ブロック図を示します。 図7 SPARC T4の命令処理とパイプライン構造の部分ブロック図 特に注目すべきは、命令フェッチ・ユニットによって命令バッファ（IB）が管理される点です。各 スレッドに専用のIBがあり、フェッチ・ユニットはスレッドを選ぶと、命令キャッシュから取り出 した最大4つの命令をそのスレッドのIBに格納します。 各サイクルで、スレッド選択ユニットによってデコード向けにスレッドがスケジューリングされま す。8つの候補の中から1つのスレッドが選ばれますが、この際、レディ状態にあるスレッドのみが 対象になります。スレッド選択は、改良されたLeast Recently Used（LRU）アルゴリズムに基づいて 行われます。選択されたスレッドから最大2つの命令が取り出され、デコード・ユニットに渡されま す。 次に、この命令はプロセッサのアウト・オブ・オーダー（OOO）部分に入ります。ここで、命令の 送り先レジスタの名前が変更され、送り先と送り元の依存関係が解決されます。これをサポートす るため、128エントリの順序変更バッファが実装されています。 統一選択ユニットによって、40エントリの選択キューから最大2つの命令がスケジューリングされま す。ここから命令は実行フェーズに入り、実行ユニットEX0およびEX1のいずれか、または両方に送 信されます。 命令は順番に関係なく実行されますが、順序どおりに終了します。つまり、先行の命令すべてが結 果をレジスタ・ファイルに書き込むまで、命令は完了しません。 要約すると、SPARC T4コアにはアウト・オブ・オーダーの2ウェイスーパースカラー・アーキテク チャが備わっています。つまり、（1つのパイプラインで）同時に2つの命令を実行できるだけでな く、順序変更の時間枠内では、レイテンシの長い先行命令によって依存関係のない命令がブロック されることはありません。これによってパイプラインの停止が軽減され、幅広いアプリケーション でパフォーマンスが向上します。 また、実行時にソフトウェアの依存性が自動的に解決されます。たとえば、十分に小さいループ構 造でありループ伝播依存性ではない場合、自動的に複数の反復処理が同時実行されます。 残念ながら、CSP1とCSP2には連続的な依存性があります。特にCSP2では、これによってアウト・オ ブ・オーダー実行による利点が制限されます。より高度なプログラムの多くでアウト・オブ・オー ダー実行は十分に活用されていますが、CSP1とCSP2は、アウト・オブ・オーダー実行ではなくスレッ ド間の並列度を強調するように設計されています。 14 SPARC T4プロセッサのスループット最適化：ケース・スタディ テスト・フレームワーク 2つのプログラムは4プロセッサのSPARC T4システム上で実行されましたが、プロセッサ・セットの 使用を通じて、単一プロセッサ上でのみプログラムが実行されるように制限されました。プロセッ サのクロック周波数は2,998MHzでした。 CSP1とCSP2の両方に対して、UltraSPARC T2+プロセッサとまったく同じ命令シーケンスがコンパイ ラによって生成されました。これは、最適化が指定されていないためです。UltraSPARC T2+に対す るテストと同じように、最新の最適化レベルを使用しても、コンパイラはループを実行せずに結果 を静的に決定します。 SPARC T4プロセッサでのCSP1プログラムに対するサイクル数の見積りとパフォーマン ス結果 結果を見る前に、UltraSPARC T2+プロセッサのテストで示したものと同様のサイクル数ダイアグラ ムを使用して、予想されるパフォーマンスを見積もってみましょう。 CSP1プログラムでは、減算命令と比較命令の間に加えて、比較命令から分岐命令に対して依存性が ありますが、ループの反復処理間では減算命令間にのみ依存性があるため、プロセッサは実行時に 反復処理をオーバーラップすることができます。これを図8に示します。 図8では、sub(0)などの添字表記によって、命令が含まれるループの反復番号が示されています。 UltraSPARC T2+の図とは対照的に2つの実行パイプラインが表示されているのは、SPARC T4プロ セッサが1サイクルで2つの命令を実行できるためです。 図8 1つのCSP1プログラムに対するSPARC T4の単一パイプラインの使用図 図8に示したとおり、2つの反復処理を完了するためには4サイクルが必要になります。つまり、1回 のループ反復では2サイクルのみが使用されます。これに加えて、UltraSPARC T2+と比べてはるかに 高速なSPARC T4プロセッサのクロック速度によって、さらなる高速化が実現されています。両方の 機能を組み合わせることで得られるパフォーマンス向上は、少なくとも、(8/2)*(2998/1580) = 7.6倍に なります。この計算は、UltraSPARC T2+プロセッサの分岐命令に6サイクルかかることを前提として いるため、7サイクルの場合は8.5倍のパフォーマンス向上になります。 ここで、安定状態のスケジュールにはギャップが含まれていない点に注意してください。したがっ て、複数コピーに対するコアあたりの実行時間は、各コアで線形に増加すると考えられます。 15 SPARC T4プロセッサのスループット最適化：ケース・スタディ また、最適化を有効化した場合、より効率的なcwbg（fused compare-branch 命令、別名CBcond）命令 を使用したコードが生成される可能性があります。これは、SPARC T4プロセッサに新しく導入され た命令であり、遅延型ではありません。この命令では、以前は必要だったnop命令が不要になり、cmp 命令とbg命令の両方の機能が実行されます。これにより、次のように非常にコンパクトなシーケン スが生成されます。 .L21: sub cwbg %i4,1,%i4 %i4,0,.L21 図9に、同時実行されたコピー数に応じた、SPARC T4プロセッサでのCSP1プログラムのパフォーマ ンスを示します。ここでも、ループ・オーバーヘッドがコストに含まれています。 図9 同時実行されたCSP1のコピー数に応じたSPARC T4の単一プロセッサ上でのプロセッサ・サイクル数。注：両軸は対数目盛り。 SPARC T4プロセッサでのCSP1のパフォーマンス結果は、理論上の見積りを裏付けるものでした。最 大8個のコピーまでの間、"i"変数を1減らすごとに2サイクルが必要になります。負荷が高くなるとコ アごとに複数のコピーが実行されますが、利用できるギャップはないため、コピー数が256に達する までの間、実行時間は線形に増加します。 16 SPARC T4プロセッサのスループット最適化：ケース・スタディ UltraSPARC T2+の結果と同様に少し不明確な部分がありますが、今回は128個または256個のコピー を同時実行した場合に限定されています。両方のケースで、サイクル数の違いは最大で2でした。負 荷が非常に高いことでオペレーティング・システムのコンテキストスイッチが発生し、これらのわ ずかな差異が生じたものと考えられます。 SPARC T4プロセッサでのCSP2プログラムに対するサイクル数の見積りとパフォーマン ス結果 CSP2プログラムに対する分析は、UltraSPARC T2+プロセッサに対して実施されたものとまったく同 じです。図10に、パイプライン使用図を示します。 CSP2のループ本体では"i"が512回減らされるため、この図ではわずかに異なる表記が使用されていま す。減算命令には、該当する添字が付与されています。前回と同様、括弧内の数字はループの反復 番号を表します。たとえばsub3(0)は、最初の反復における3番目の減算命令を指します。 図10 1つのCSP2プログラムに対するSPARC T4の単一パイプラインの使用スケジュール。添字はループ内での減算命令の番号を示す。 変数"i"を減らすたびに1サイクルが使用されます。しかし、このプログラム内に当てはまるデータ依 存性のため、1サイクルあたりに実行できるのは1つの整数加算のみになります。 このため実行が制限されて、IPCの値は1になりますが、ほとんどの場合、このプログラムは、SPARC T4プロセッサ上でのIPC値が2であるCSP1よりも高速で実行されます。これは、CSP1では分岐命令と 比較命令で構成された追加処理が実行されるためです。これらの処理は実行の必要がありますが、 計算結果に直接影響するものではありません。これらは、いわゆるループ・オーバーヘッドの一部 です。CSP2では、合計のループ・オーバーヘッドが大幅に削減されています。 いったんすべてのパイプラインが2つのコピーを実行した後では、実行時間はワークロードに応じて 線形に増加すると考えられます。 実際、この結果が確認されました。図11は、CSP2プログラムに対するSPARC T4のパフォーマンスを 同時コピー数に応じてグラフ化したものです。コピー数が16に達するまでの間、更新には1サイクル かかっています。 さらに負荷を高くすると、コストはコピー数に比例して増加します。その結果、256個のコピーを同 時実行すると、1から16個のコピーを実行する場合の16倍の時間がかかりました。 17 SPARC T4プロセッサのスループット最適化：ケース・スタディ 図11 同時実行されたCSP2のコピー数に応じたSPARC T4の単一プロセッサ上でのサイクル数。注：両軸は対数目盛り。 このグラフには注目に値する点があります。24個と56個のコピーを実行した際のサイクル数は整数 値ではなく、それぞれ1.5と3.5になっています。なぜそのような結果になるのでしょうか。これらの テストは、負荷が16の倍数にならないケースであることを思い出してください。UltraSPARC T2+プ ロセッサでは、実行された作業量に応じて2つの異なるサイクル数が得られました。 しかし、SPARC T4プロセッサのアーキテクチャは大幅に異なります。前述のとおり、CSP2のIPC値 は1であり、1サイクルあたり2つの命令を発行できるため、CSP2のコピーを2個実行するとパイプラ インがもっとも有効に使用されます。ただし、24個の同時コピーという負荷がかかると、それぞれ のコアで3つのコピーが実行されます。つまり、コピー1個の更新には平均で3/2 = 1.5サイクル必要に なります。 56個のコピーを同時実行すると、各コアで7個のコピーが実行されます。同様の理由から、1回の更 新あたりのコストは7/2 = 3.5サイクルになります。 ここでもごくわずかに不明確な値が見受けられますが、128個と256個のコピーに対してのみであり、 その差異はわずか1サイクルです。 謝辞 このテストのきっかけになったのは、顧客であるGDF Suez（フランス）のSolaris One-ITエンジニア リング・チームから受け取った2つのマイクロベンチマーク・プログラムです。プログラムの提供と このホワイト・ペーパーへの貢献およびサポートに対して、ここにチーム・メンバーへの感謝の意 を表します。 18 SPARC T4プロセッサのスループット最適化：ケース・スタディ 参考資料 [1] “OpenSPARC T2 Core Microarchitecture Specification”、2007年12月： http://www.opensparc.net/pubs/t2/docs//OpenSPARCT2_Core_Micro_Arch.pdf [2] OpenSPARC Internals—OpenSPARC T1/T2 Chip Multithreaded Throughput Computing、David L. Weaver（編集者）、2008年10月： http://www.opensparc.net/publications/books/opensparc-internals.html [3] Oracle Solaris Studioホームページ： http://www.oracle.com/us/products/servers-storage/solaris/studio/overview [4] 『オラクルの SPARC T4-1、 SPARC T4-2、 SPARC T4-4、 SPARC T4-1B サーバーのアー キテクチャー』、2011年10月： http://www.oracle.com/technetwork/jp/server-storage/sun-sparc-enterprise/documentation/o11-090-s parc-t4-arch-1565634-ja.pdf 著者について Ruud van der Pasは1998年9月にオラクル（当時のSun）に入社しました。Ruudは数学と物理学の学位 を取得しており、オラクルのSPARC組織に属するArchitecture and PerformanceグループのSenior Staff Engineerとして勤務しています。専門分野はアプリケーション・パフォーマンスであり、シングルス レッド・アプリケーションと（共有メモリ）パラレル・プログラムの両方を手がけています。Ruud のブログはhttp://blogs.oracle.com/ruudから参照できます。 オラクルのPrincipal EngineerであるJared Smolensは、将来的なSPARCプロセッサ・コアのパフォーマ ンスとパワー・モデリングの先導役としてカリフォルニア州サンタクララで勤務しています。2007 年にカーネギーメロン大学でコンピュータ・エンジニアリングの博士号を取得したJaredは、ソフト・ エラー検出に関する著書をいくつか発表しています。 19 SPARC T4プロセッサのスループット最適化： ケース・スタディ 2012年4月、バージョン1.0 著者：Ruud van der Pas、Jared Smolens Oracle Corporation World Headquarters 500 Oracle Parkway Redwood Shores, CA 94065 U.S.A. 海外からのお問い合わせ窓口： 電話：+1.650.506.7000 ファクシミリ：+1.650.506.7200 www.oracle.com Copyright © 2012, Oracle and/or its affiliates.All rights reserved.本文書は情報提供のみを目的として提供されており、ここに記載さ れる内容は予告なく変更されることがあります。本文書は一切間違いがないことを保証するものではなく、さらに、口述による明 示または法律による黙示を問わず、特定の目的に対する商品性もしくは適合性についての黙示的な保証を含み、いかなる他の保証 や条件も提供するものではありません。オラクル社は本文書に関するいかなる法的責任も明確に否認し、本文書によって直接的ま たは間接的に確立される契約義務はないものとします。本文書はオラクル社の書面による許可を前もって得ることなく、いかなる 目的のためにも、電子または印刷を含むいかなる形式や手段によっても再作成または送信することはできません。 OracleおよびJavaはOracleおよびその子会社、関連会社の登録商標です。その他の名称はそれぞれの会社の商標です。 IntelおよびIntel XeonはIntel Corporationの商標または登録商標です。すべてのSPARC商標はライセンスに基づいて使用される SPARC International, Inc.の商標または登録商標です。AMD、Opteron、AMDロゴおよびAMD Opteronロゴは、Advanced Micro Devicesの商標または登録商標です。UNIXはX/Open Company, Ltd.によってライセンス提供された登録商標です。0611