科学技術計算分科会「次世代HPCを支える基盤技術」
(5/9)
- 4．技術と必然性
-
メインフレームの技術は過去のものだろうか。メインフレームの CPUをベースに開発したことは、SPARC64 V/VI/VII をどのように特徴づけるだろうか。マイクロプロセサから発展したチップ搭載のシステムが、性能でメインフレームを凌駕した現在、メインフレームの技術を開発した当時に立ち返って概説し、これらの問いを考える。
メインフレームの技術開発を牽引してきたものは、高性能・高信頼性からの要件であった。現在ミッションクリティカルな分野のシステムに、同じ要件が求められている。技術のドライバ（要件）が同じ場合、課題解決に共通のアプローチがとれることを、実例に基づき述べる。ここにみられる必然性は、要件の一致である。
最初に、命令実行処理装置を紹介する。この技術は、SPARC64 V に引き継がれている。ドライバとなる要件は、"演算部への高い命令供給能力"である。要件の背景として、メインフレームは高い 1次キャッシュミス率があり、SPARC64 V の場合は演算処理能力の向上がある。最近 Intelは、命令フェッチの方式を従来のトレースキャッシュから分岐予測の方式に変更した。限られた情報からの推測であるが、ここで紹介するものと同様の方式と見ている。
次に、命令リトライについて述べる。まず、命令リトライを実現させる前提にある、同期一括更新方式を概説する。これは、GS8800Bの新規アイデアであり、この技術によって明確なチェックポイントを形成でき、メインフレームで従来からあった命令リトライを、アウト・オブ・オーダのシステムで実現することができた。命令リトライは、現在の GSのみならず SPARC64 V/VIに受け継がれて、高性能と高信頼を両立する技術の核となっている。そして、GS21と SPARC64 V/VI は、アウト・オブ・オーダ実行機構を備えると同時に命令リトライが出来る、世界で唯一の CPUである。
- 4.1. 命令実行処理装置
-
ブランチヒストリを用いた動的な分岐予測方式を考案したのは、ECLの超大型コンピュータを開発していた 1990年頃だったが、プロジェクトがキャンセルされたため、実現できたのは GS8600からである。
このころ、マイクロプロセッサの分野でも分岐予測が実用化されつつあった。しかし命令フェッチは命令処理パイプラインの先頭の 1ステージにすぎず、先行制御の仕組みを備えていないのが普通であった。したがって、分岐予測は命令処理の頭で方向予測するだけの簡単な機構が一般的であった。このような機構では、命令フェッチでキャッシュミスが発生すると、パイプライン全体が停止していた。 一方、FACOM230-75 に起源を持つ先行制御の命令フェッチは、M-780では富士通の追永勇次の手によって、最大 48バイト情報を格納可能な命令バッファを備え、実行中の命令列と、最大 2系統までの分岐先ターゲットを保持する形に進化していた。メインフレームを用いる基幹業務処理は動作する命令域が広大であり、このため、命令用に 64KB、128KB等の大きなキャッシュを用意しても命令キャッシュは 5%を超えるミス率となるケースが散見した。その状況においては、巨大な命令バッファを備えて命令フェッチを先行させて先取りし、分岐先アドレスが確定した後に分岐先の命令列を即座にフェッチ可能とする作りに必然性があった。巨大な命令バッファを持ったため、命令フェッチに費やす回路規模としては当時としてはとびぬけて大きく、超大型といわれたコンピュータであればこそ実現できたものだった。しかしこれは同時に、マイクロプロセッサの分野で実現しつつあったような分岐予測の機構をそのままでは適用出来ないことを意味した。そして命令キャッシュミス率の悪化など、当てにならない予測による弊害の方が、分岐予測機構を装備することによる効果を上回ることは容易に想像された。その上メインフレームの命令セットアーキテクチャでは、レジスタ相対(*)で分岐先アドレスが指定されるため、ますますマイクロプロセッサで行われつつある機構は適用が困難であった。 GS8600以降で装備した分岐予測機構は、M-780で装備した巨大な命令バッファを備える先行制御の仕組みの上に動的な予測機構を組み込んだ。その前提は、上記の必然を覆す機能の実現であり、すなわち命令フェッチのスループットや命令キャッシュの効率を低下させないこと、予測ミスのペナルティーを充分小さくすることであった。
(*)分岐先アドレスを、命令のオペランドに指定されたレジスタにあるデータと、オペコード内の即値の和で求める。
考案したしくみ[14] を、図2を使って説明し、効果を図3に示す。この方式の特徴は、分岐処理で非連続となった命令シーケンスに対しても、デコーダへ連続して命令を供給できることにある。その実現には、複数命令バッファに、近い将来実行されるであろう命令流を保持しておき、命令バッファからデコーダへの命令供給を、タグ部からの情報で制御する方式をとった。図2では、3つの命令シーケンスの同時保持の仕組みを例示しており、命令アドレス生成回路、命令バッファ、タグに、A,B,C を付し、組として扱われることを示している。現在処理中の命令列が、図中命令アドレス生成回路A に保持されたアドレスの指す場所にあるとする。生成回路A のアドレスでフェッチされた命令列は、命令バッファA に格納される。命令キャッシュアクセスは、生成回路A〜C のいずれか一つを選択して行われる。選択アルゴリズムの説明は、ここでは割愛する。命令フェッチアドレスは、命令キャッシュへの送付と同時に、ブランチヒストリへ送られる。ブランチヒストリへの登録は、分岐命令実行時に、命令アドレスと分岐先アドレスを対にして実施されており、従って、過去に実行された命令で、リプレースされていない場合、ブランチヒストリでヒットし、分岐先のアドレスが得られる。ヒット時に、取り出した分岐先命令アドレスは、選択回路（図2）に送られ、次のサイクルで命令フェッチ要求の対象となる。それと同時に命令アドレス生成回路B にも送られる。図3の上部は、分岐予測を備えない処理のフローを表す。分岐命令(A) の分岐先アドレスが確定した時点で、分岐先命令のフェッチ（図3 'IA'）が開始され、分岐確定以降に分岐先命令のデコードが実施されている。下部の図は、命令フェッチ時にブランチヒストリがヒットし、予測された分岐先命令が、分岐命令のデコードに先行してフェッチされる様子を表す。先行フェッチにより、分岐命令(A)のデコードの次サイクルに分岐先命令のデコードが可能となっている。上述のように、複数の命令バッファに、異なった命令流の命令列が格納されており、デコーダへの命令供給元のバッファ選択は、タグA,B,C で管理する。巨大な命令バッファによって命令フェッチを命令実行とデカップリングし、分岐予測結果に従って、これから実行されるであろう命令シーケンスをたどりながら、命令バッファが一杯になるまで命令を先取りしていく仕組みは、キャッシュミスの弊害を少なくし、高い命令供給能力を持った非常に先進的な作りといえる。
また、命令のフェッチアドレスを比較に用いて、ブランチヒストリのヒット・ミスを厳密に判断する仕組みとしたことで、過去に実行されていない命令で誤ってヒット判定する誤りを抑制した。ターゲットアドレスの正誤判定は、分岐先アドレスが判明した時点で行う。そして、分岐が成立するか否かの予測を誤ったために不要な命令が実行されている場合には、先行制御の仕組みを利用して、実行部での分岐命令およびそこに至る命令列の実行完了を待たずに、直ちに命令フェッチのやり直しを開始する。
 | |
| 図 2．分岐予測機構 | |
|---|---|
 | |
| 図 3．分岐予測の効果 | |
|---|---|
-
この方式をはじめて適用した際には、ブランチヒストリの容量はわずか 256エントリだったが期待通りの効果であり、キャッシュのミス率をいくらか低下させるというおまけ付きだった。
その後、世代ごとにブランチヒストリの容量を増加した。また、サブルーチンからの戻りアドレスが呼びだし元によって異なることに対処するために、リターンアドレススタックを追加した。
SPARC64 V/VI でも、基本的な仕組みは考案当時のものから変わっていない。しかし、ブランチヒストリは 16 Kエントリであって 1次キャッシュの大きさに匹敵し、命令バッファ容量は 192バイト（命令フェッチ巾：32バイト×6）である。そして、リターンアドレススタックのほかに、複雑な挙動を示す高頻度ルーチンの予測精度の向上のために Write-cycle-driven Global History Table（WGHT）といった補助機構も追加している。 SPARC64 V/VI に限らず最近のマイクロプロセッサでは、命令フェッチがかなり大きな回路となっている。これは実行部の高速化と並列度の向上により、命令フェッチが性能に与える影響が相対的に大きくなったため、必然的に機能が強化されたためである。結果的に、M-780で命令フェッチにつぎ込んだ物量は今では珍しくはなくなっている。こうした中で振り返ると、GS8600で装備した命令フェッチの方式は、ある程度物量を豊富に使える前提では、効率の良い方式であったことが判る。
- 4.2. 命令リトライ
-
GS8800Bは初めての、動的スケジューリングに基づくアウト・オブ・オーダ制御のスーパースカラ方式のシステムである。M-780以来続いてきたロックステップパイプライン方式の変更を伴うこの開発は、富士通の清水和之が Amdahl社で行われていた Chaosプロジェクトを私に紹介してくれたことがきっかけとなって始まった。Chaosプロジェクトにはロバート・トマスロー、ボブ・マイヤー、マーク・ニールセンらがメンバーとして加わっていた。
Chaosは究極のアウト・オブ・オーダのマシンを目指すものだったが、当初のアイデアは全くのペーパーマシンであり、1サイクルの論理段数が 30段を超えるようなものであった。さらに、CISC型の複雑な命令の処理に必要なマルチフロー展開やマイクロプログラム制御、そして RASについては、ほとんど検討されていなかった。さらに、従来のメインフレームで実現していた全ての機能を、レベルを低下させずにサポートできるのか、何が本質的な問題であるかも不明であった。
本当に「ものになる」のかをはっきりとさせるために、ほどなくマーク・ニールセンが富士通（川崎）の職場に合流し、浅川岳夫、本車田強、森田國樹らと一緒に勉強会を行い、検討を重ねた。Amdahlの Chaosのメンバーと、週を置かずにテレビ会議を実施する中で、問題が明確になり、解決の糸口が見えてきて、次第に具体的な回路イメージが浮かび上がった。このような準備を経て、基本検討開始からおよそ 2年で設計を完了した。GS8800Bは、Chaosでもたらされた概念を基盤に、過去から継承してきた技術と、多くの新規アイデアを加えたものとなった。 メインフレームでは、高信頼性の要件は絶対であり、性能向上と引き換えに高信頼を失うことはあってはならなかった。それを踏まえた高性能の追及は設計者として挑戦しがいのある壁であり、その克服を通して確かな手ごたえを味わった貴重な経験である。この技術は 1998年に特許出願した[15]。
- 4.2.1. 同期一括更新方式
-
演算など、命令で陽に指定された処理を制御する Reservation Station for Execution（RSE）などとは別に、コミット・スタック・エントリ（CSE : Commit Stack Entry）と呼ばれるバッファが存在する。CSEは、命令ごと（マルチフロー展開では 1フローごと）に 1エントリが割り当てられ、実行中の命令の進捗状況の監視に用いる。CSEのエントリは、プログラムのオーダに従いイン・オーダで実施される命令コミット時に、無効化される。このコミット処理で、レジスタ（GPR、FPRなど）の更新、ストアバッファにデータを格納した後の突き放された状態のストア処理に対するメモリ反映指示（ストア・イン方式のためキャッシュに書き込む）、プログラムカウンタの更新指示が、一括して出される。これを同期一括更新と呼んでいる。
アウト・オブ・オーダで実行した結果はすべて、コミットまでソフトウェアから見えない作業用レジスタ（GUB、FUB）に格納され、ソフトウェアから見えるプログラマブルな資源には反映されない。CSEの更新指示はイン・オーダで行われるために、いつ実行を中断しても、その時点でプログラムカウンタが指す位置で、プログラマブルな資源の一貫性が保証できる。一方、作業レジスタや演算器の入出力などに残っているものは全て破棄することが出来る。これは、コミットのたびにチェックポイントを形成していることになっており、M-780などのパイプライン制御のＷ（Write）サイクルの機能を実現している。
この機構は、分岐の予測ミスずれのリカバリや、割り込み発生時にプログラマブルな資源の一貫性を保つことに使用される。しかし、最たる特徴は、従来からの命令リトライを可能にすることにある。
- 4.2.2. 命令リトライの機能
-
命令フェッチ、命令実行に関するあらゆる部分のどこかで、エラーが検出された場合、割り込み同様に CPUのプロセススイッチを起動して命令実行を中断する。前述の CSEが形成したチェックポイントで停止することになる。そこで命令フェッチや実行に関する資源をフラッシュし、あらためてプログラムカウンタの位置から再開すれば、データインテグリティを損なうことなく命令リトライを行うことが出来る。GS8800Bでは、CSEのエントリ数は 16で、同時にコミットできる命令は最大 3命令だった。SPARC64 V/VI では CSEは 64エントリで、同時に最大 4命令までコミットできる。この様に数の拡張はしているが、同期一括更新方式や命令リトライ機構自身は全く変わっていない。
FACOM230-75を振り返ると、CPU部の IC数はおよそ 24,000個である。当時のコンピュータは、1日に 10回を超えるダウンも発生した中で、命令リトライはなくてはならない機能で、それゆえ、よく磨かれた機能でもあった。時をへて、命令リトライをフィールドで観測することは稀になったが、その状況は近年になって変わりつつある。高度な半導体の微細化技術でゲート酸化膜は原子数個のレベルとなり、トランジスタはゆらぎともいえる特性変動を示すようになっており、今後は、RAM部分に限らずロジック部でも、ソフトエラーの影響が無視できなくなる。また、回路規模が拡大すると、ソフトエラーに遭遇する確率は確実に上がる。 この背景の元、性能向上用途の回路規模拡大を、エラー発生頻度とのトレードオフで判断する時代がくる。その中にあり、前述の命令リトライ機能は、トレードオフ回避の効果を発揮する。それは、プログラマブルなリソースの回路規模は命令セットアーキテクチャによってほぼ決まるためである。プログラマブルなリソースを使って命令リトライを掛けるため、ここの回路規模が変化せず、結果として信頼性が変化しないことが、命令リトライの成功率を一定に保つ。性能向上目的で回路が拡大しても、随所にエラーチェッカを設けて実行途上のエラーを漏らさず捕まえて命令リトライを実施すれば、エラーに遭遇した場合にも、ソフトウェアへの影響は皆無となる。
現在コンピュータは、社会のインフラとして定着しており、コンピュータの引き起こすデータ化けやダウンは、社会に非常に大きなダメージを与える。これが、コンピュータの信頼性が改めて注目される所以であり、その重要性は増していく。社会基盤に位置づけられるサーバは、信頼性への要求に十分答えるものでなければならない。今ふたたび、命令リトライ機能は、欠くことのできない機能となりつつある。
- 4.2.3. 他社のとりくみ
-
SPARC64 V/VI と富士通のメインフレームの CPU以外に、演算器のエラー検出と命令リトライが可能なプロセッサとして、IBMメインフレームの Zシリーズがあげられる。
IBMの場合、Power4、Power5では、SPARC64 V/VI や GS21同様にアオトオブオーダの実効機構を備えているが、Zシリーズでは古典的な単一命令発行のロックステップパイプライン制御となっている。これは、メインフレームの使われ方から演算性能に対する要求が高くないこともあるが、信頼性を求めるために、そうせざるを得なかったという面もある。
IBMの Zシリーズでは、演算部分にパリティプレディクションなどの入力データのパリティを保存する機構を設けないかわりに、演算部分を 2重化している。そして演算結果をレジスタに書き込む前に 2つの演算結果の照合チェックを行い、不一致の場合には、これを破棄して命令リトライを行っている。この方法は、2重化ではどちらの結果が正しいのかが分からない短所を、結果を破棄することによって補い、データインテグリティを保証することが出来るとともに、ソフトエラーからの回復を実現している。しかし一旦、照合チェックでエラーを見逃すと、その痕跡(*)は残らず、照合回路そのものが ALUに匹敵する回路となるためエラーの危険にさらされており、万全とはいえない。
(*)SPARC64 V/VI の EXECレジスタのパリティをチェックする方式では、チェッカに故障があっても、伝播されたパリティは、またいずれかのチェッカによってデータインテグリティを保証される。例えば、演算途中でエラーが発生した場合に、演算結果のチェッカが壊れてエラーの検出が出来なくても、そのパリティがアーキテクチャレジスタに書き戻されて保存され、次にこのレジスタを使用したときに、今度は演算入力のパリティチェッカによってエラーが検出される。
加えて、演算器を 2重に使用し、照合のためにパイプラインの 1ステージを費やし一致チェックを行うことから、同じ仕事に対する消費電力としては、非常に不利である。さらにロックステップパイプラインでは、演算器の実行効率はどうしても低くなるから、高い演算性能を求める場合には、より多くのハードウェアが必要となる。従って、高い演算性能が必要なプロセッサでは、この方法は好ましくなく、消費電力の観点でも上述と合わせて不利となる。