Previous ToC Next

36. GRAPE と汎用スパコン (2006/11/8)

ここまで GRAPE の歴史を振り返ってみました。 計算機を作るとはどういうことか、を多少とも感じてもらえたら幸いです。 まあ、 GRAPE はあんまり計算機ではありませんが、そうはいっても 回路設計から箱の設計までをやってますから計算機の設計の全部をある程度見 てきているわけです。

GRAPE-6 までの専用プロセッサとしての GRAPE では、設計の思想は単純で、 重力多体計算で、しかもアルゴリズムも決めた上でそれを与えられた予算と使 える人的資源の範囲で最も高速にできる方法を考える、ということになります。 GRAPE では1台毎にそういう、ある種の最適化問題を解くようなことをしてき ました。

これは、普通の計算機の設計方法とは実は全然違います。というのは、普通の 計算機では殆どの場合に後方互換性というものが問題になるからです。後方互 換性とは、要するにその会社の前の世代の計算機用のプログラムがそのまま走 る、ということです。そのかなり極端な例はインテルの x86 プロセッサ系列 で、現在の最新のプロセッサでも命令セットの基本は20年近く前の80386 のそ れであり、しかも 80386 の命令セット自体、 8ビットプロセッサの 8080をほ ぼ命令互換のまま 16 ビットにした 8086 の命令セットをさらに32ビットに拡 張したものになっているわけです。もっとも、現在の x86 プロセッサでは、 命令セットで定義された命令がそのまま実行されるわけではなくて変換されて から実行されるので、変換された後の命令セットや実行アーキテクチャは半導 体プロセスの特性や設計能力に合わせたものが使えます。そのように命令セッ トと実アーキテクチャを切り離してしまったことによって、中途半端に後方互 換性にしばられることになる RISC プロセッサよりも速く性能向上することに 成功したわけです。

まあ、そうはいっても勘弁して欲しいような命令セットというのもあり、その 代表が浮動小数点演算の x87 命令セットでした。これはスタック型の実行マ シンというものを想定していて、レジスタが明示的に指定されないで演算命令 はスタックからオペランドをとりだして実行される、というものでした。8087 プロセッサではレジスタ操作よりも演算自体に時間がかかったのでこれで問題 なかったわけですが、クロックサイクル毎に演算器にデータが投入できるよう になるとこれでは全く話になりません。それでも工夫することで性能を出すこ ともできなくはなかったようですが、 2001年にインテルは SSE2 命令セット を導入し、 x87 命令セットよりは少し性能を出しやすい命令セットにします。

このように後方互換性にしばられるのは x86 プロセッサだけではなく、 Cray のベクトルプロセッサでも同様でした。実は Cray 本人は Cray-1 の後それと 互換性のない Cray-2 を作ったのですが、これの開発があまりに遅れたため、 互換性のある XMP, YMP の系列が製品としては生き残ってしまいます。その結 果、最後まで互換性を保つしかなくなったようです。

GRAPE の場合、毎回アーキテクチャは大きく変更しましたが、ユーザープログ ラムは元々殆どが汎用ホスト計算機の上で走っていて、 GRAPE のほうは関数 呼び出しです。このため、その気になればライブラリ API を同じにすること で、コンパイルしなおすだけでアプリケーションプログラムがそのまま走るよ うにはできます。バイナリがそのまま走るようにするのも、ライブラリを実行 時にリンクするようにしておけば原理的には可能です。まあ、原理的には可能 というだけで実際にはそういうものは提供していないのですが、 OS からなに から走る必要がある汎用プロセッサではなく、 GRAPE を使っているアプリケー ションだけの話なのであまり互換性が大問題にはならないわけです。

つまり、GRAPE では後方互換性を無視したわけではなく、互換性が必要な部分 の殆どは汎用プロセッサにまかせたので互換性を気にする必要がそもそも少な くなっている、ということです。

GRAPE のやり方のメリットは、開発コストが、ハードウェアもソフトウェアも 極限まで切り詰められることです。欠点は汎用プロセッサや接続バスの性能が システム全体の性能のボトルネックになりえることです。このようなやり方が 良いかどうかは、汎用プロセッサや接続バスの性能がどの程度のものであり、 目的に十分かどうか、ということに依存するわけです。

現在の時点では、汎用プロセッサの速度自体はボトルネックになることはまず ありません。その理由は簡単で、 シングルスレッド性能で x86 プロセッサよ り速いプロセッサは現在存在しないに等しいからです。もちろん、これが30年 前なら状況は違ったわけで、汎用プロセッサというものは大変高価で、安く買 えるミニコンは高いスパコンに比べると価格当りの性能が低いものでした。こ のため、ミニコンの部分の性能がボトルネックになってしまうと、スパコンの 価格性能比を超えられなくなる可能性があったわけです。現在は、価格当りの 性能で x86 やその他のマイクロプロセッサを超えるのはそれ自体容易ではあ りません。従って、専用プロセッサ等を考える時に、専用プロセッサが効率的 ではないところは汎用マイクロプロセッサにやらせるのがもっとも価格性能比 が良い方法になります。

さて、問題は接続バスの性能がボトルネックにならないかどうかです。これは プロセッサ性能よりももう少しややこしい話になります。というのは、 こちらはなかなか上がらないからです。 PC 用のバスだと、 ISA バス、PCIは それぞれ 10 年以上使われました。 PCI バスの速度は ISA のせいぜい 15 倍 です。この20年間に汎用プロセッサの速度はほぼ 1 万倍になったことを考え るとこの 15倍というのはいかにも小さいです。 PCI-Express にしても、現在 容易に利用できる 4 レーン程度のものだと PCI バスに比べておよそ 10 倍で あり、 20年前の ISA バスに比べて数百倍でしかありません。

もっとも、これは接続バスだけの問題ではなく、メインメモリそのものの問題 です。つまり、マイクロプロセッサのメモリインターフェースや主記憶の速度 がそもそも数 GB/s しかなくて、接続バスの速度はそれに近いものになってい るのです。従って、汎用マイクロプロセッサを使う限り、接続バスに汎用のも のを使うので十分なわけです。

GRAPE の場合、アプリケーションの特性として、粒子間相互作用を計算する、 ということがあるので演算速度のわりに必要なメモリバンド幅は小さくなりま す。このため、汎用マイクロプロセッサに汎用バスを通して専用プロセッサを つなげる、というアプローチが理想的に機能しました。 これは、アプリケー ションが川合先生の分類では「遠隔型」になるものだから、といっても間違い ではないでしょう。

川合先生の分類ではあと近接型、不規則型とあるわけですが、計算が大規模に なっていくと不規則型は遠隔型か近接型のどちらかに近付いていきます。従っ て、重要なのは近接型です。近接型については少し議論しましたが、単純な 例を考えるとベクトル計算機のような、演算速度に対してメモリバンド幅が高 いものだと性能がでる、ということになります。

だからそういうハードウェアを作ってしまえばよろしい、というのはもちろん 一つの考え方です。地球シミュレータや、 QCDOC のような QCD 計算のための システムは実際に基本的にはそのような思想で設計されているわけです。 QCDOC は比較的安価で、地球シミュレータは高価ですが、その違いの殆どは QCDOC ではメモリバンド幅を1チップにメモリを集積することによって実現し た、というところからきています。 QCDOC は 1 Gflops の演算速度に対して 8GB/s ものメモリ転送速度を持ち、地球シミュレータが 8Gflops に対して 32GB/s でしかないのに比べて比率では高いのです。これが IBM が商品化した BG/L ではそこまではありませんが、地球シミュレータと同等であるというの は間違いありません。

オンチップメモリを使うことの欠点は、メモリ容量が小さいことです。QCDOC の場合はチップ当り 4MB しかありません。。もちろん、これは 180nm という古 いプロセスを使っているからで、例えば 90nm ならその4倍の 16MB、つまり 128Mbits になるわけですが、ビット当りの価格では汎用 DRAM に比べて100倍 ほどになるので、メモリが大量に必要な場合には全部オンチップでというのは 非現実的です。 QCD 計算では大した量はいらないのでこれですませたわけで す。オンチップメモリを使うことにすると、結局その速度で性能がきまるので プロセッサをどうするかはあまり問題ではなくなります。 QCDOC では IBM が 設計をもっていた PowerPC 440 の浮動小数点演算部分を少し強化して使って いるわけです。これは、コンパイラ等に出来合いのものが使えるというメリッ トがあります。もちろん、Power でなくて ARM や MIPS でもかまいません。

本当に大量のメモリに対して高いバンド幅でアクセスしたいなら、それを優先 したシステム設計をするべきと考えられます。例えば、 2006年現在なら GDDR4 規格の DRAM は1チップで 10GB/s 程度のバンド幅ですから、8個つけれ ば 100GB/s 程度と NEC SX-8R 以上のバンド幅になります。これは実際に最新 のビデオカードがやっていることで、3万円程度のカードで 64GB/s 程度のバ ンド幅をすでに実現しています。 GDDR 規格の DRAM は通常の DDR2 とかに比 べて高価なことは確かですが、オンチップ DRAM に比べると桁違いに安価で す。

結局、プログラム可能な計算機を作る時に考えるべき最も重要なことは、演算 器とメモリの間をどうやってつなぐか、ということです。並列計算機だと沢山 の計算ノードの間をどうつなぐかという問題がさらに発生しますが、ここでは それは考えないことにします。というのは、ここでは、普通に PCを買ってく るよりも価格性能比が良い計算機を作ることを目標にしますが、そのためには まず並列化以前に1チップの性能で普通の PC より良くなければ話にならない からです。

もっとも、実際に現在売られているスーパーコンピューターと称するもので、 価格性能比で普通の PC より良いものは殆どありません。例えば BG/L の価格 は1Tflops あたり2000万円程度のようで、これは 50万円で 25Gflops ですか ら、最新の PC ならもう2-3倍はいける、という数字です。これが Cray とか NEC のベクトル機だと、将来目標が 1Tflops 1 億円ですから全く話になりま せん。しかし、このように価格性能比が低い、ということが、ベクトル機をニッ チマーケットのものにしているだけでなく、大規模数値計算による科学研究の 進歩自体を阻害している、ということはもうちょっとちゃんと理解されるべき でしょう。

つまり、 1 億円で PC を買えば 10Tflops はそんなに難しいことではないの に、その10倍以上の値段の計算機を使っている、ということは、同じ時間にそ れだけ小さな計算しかできていない、ということです。それなら、計算機ハー ドウェアにかけるお金は 1/10 にして、それだけのお金で雇える人を PC クラ スタで性能がでるアルゴリズムの開発や実装に使うほうがおそらくは効率的で す。まあ、1/10 までしなくも、半分にすれば莫大なお金をソフトウェア開発 に使えることになります。

少し話がそれたかもしれません。とにかく、ただ PC を買ってくれば済むなら 買ってくればいいわけですから、それより何か良いところがあるものを作るの でなければ意味はありません。 GRAPE-DR では、メモリバンド幅はそこそこに しておいて、演算能力だけを極限まで上げる、というアプローチをとっていま す。このやり方は、少なくともそれで性能がでるアプリケーションに対しては 極めて上手くいく、というのは、 GRAPE ではすでに実証されています。

上の、考えるべきこと、という観点から整理してみます。 GRAPE-DR では、非 常に沢山の演算器それぞれに少しだけメモリをつけました。これは、例えば粒 子間相互作用や密行列の乗算といった、データ量に対して計算量が多い処理だ けをするのには最適な構成です。このやり方ではとにかく極限まで演算器の比 率を上げるので、これよりも高い価格性能比を実現するのは原理的に困難です。 もっとも、GRAPE-DR の実物では設計の最適化にかける人手がないとかそういっ た理由で動作クロックは低いので、他のアプローチでも対抗する余地がありそ うに見えています。

では、メモリバンド幅が必要なアプリケーションに対してはどうすればいいの でしょうか？本当に必要ならばバンド幅をつけるしかありません。この時には、 なるべく安くバンド幅を稼いで性能を出すにはどうするか、という問題になり ます。例えば、現在だと GDDR4 メモリで、メモリチップが2000円くらいだと して1万円で 50GB/s 程度のバンド幅が得られます。これに対して、普通の DDR2 DRAM モジュールだと1万円で 6.4GB/s なので 10 倍程度良くなります。 また、システムにすると安い PC でも 30万円で dual channel 12.8GB/s とす れば1万円当り 0.4 GB/s なので、1万円で 50GB/s に近いバンド幅を実現でき るなら2桁近く上げる余地があるわけです。

問題は、ではメモリの値段がメインになるようなシステムを実現できるか、と いうことです。まあ、グラフィックカードは既に述べたように出来ているので、 量産効果が期待できるシステムならそれほど難しいことではない、ということ になります。

チップとしてはどんなものになるでしょうか？例えば GDDR4 メモリ4個で50GB/s 程度の速度を想定してみます。演算速度はこれに対応させるとせいぜい 50Gflops、真っ当なベクトルプロセッサなら6Gflops です。ここでは、 25Gflops を想定してみます。これには、例えばクロック 400MHz で 32組の演 算器があればいいですから、 GRAPE-DR の大体 1/16 で4mm角程度で演算器と レジスタファイルが構成できます。メモリインターフェースは沢山ピンがいる のでパッケージのピン数としては電源も入れると 700ピン程度で結構大きいで すが、ダイサイズはそれほど大きくならない、まあ 90nm かあるいはもっと古 い世代の 130nm とかでも7-8mm角でできるでしょう。この場合、量産コストで チップ当り1万円を切るのは不可能ではないと思います。

まあ、実際にこれから設計するなら 65nm を使って2-3年後にできるものに競 争力があるか、という話になるのですが、メモリインターフェースをどうする かとか予測が難しいので現在130nm で作ってどうか、という見積りにしてみま す。この場合、結局チップコストがプロセッサ1万、メモリチップが4個でこれ も1万、合わせて2万です。消費電力は殆どメモリインターフェースで、20W 程 度になってしまうでしょう。 これを4組のせて PCI-X インターフェースをつ けたボードは量産コスト15万円というところでしょう。売値は25万から50万の 間です。

メモリバンド幅は 200GB/s 程度なので、最も高いケースの 50 万円でも PC に比べてまだ 10 倍程度良く、演算速度も 100Gflops 程度あり、メモリも 1 GB 程度は載ります。

このシステムはそんなに悪くないように見えなくもないですが、では売りもの になるか、というと結構微妙です。というのは、

  1. 値段当りのメモリバンド幅に特化したので、演算性能はそんなに高くない
  2. 既存の例えばベクトルプロセッサ向きのプログラムがそのまま走るわけではない

という問題があるからです。1のほうは、もうちょっと演算器を増やしてしま えば良く、それは結局コストにたいして影響しないので最大200-400Gflops ま で演算速度をあげてしまえばいいのですが、プログラムのほうは問題です。 GRAPE では、結局演算量の一番大きいところはプログラム全体のほんの1部で あるということを信じて、そこで互換性がなくなってもプログラムのほとんど を占める他の部分は互換性があるから我慢してね、というふうにしています。

では、メモリバンド幅がいる計算の典型である流体コードではどうか？という と、本当はそんなに事情は変わりません。計算コードは結構膨大なサイズにな りますが、その全てに演算時間が同じように分布するわけではもちろんないか らです。結局、計算量の大半は単純な差分計算であったりします。特に並列化 するとか、適応格子にするとかになると、計算コードのほとんどの行はそういっ た、数値計算とは無関係な処理をするわけで、それらには大した時間はかかり ません。

しかし、流体コードの面倒なところは、だからといって GRAPE でやっているように 計算コードのほとんどはそのままホスト計算機で動かして、計算が重いところ は専用機で、というわけにはいかないことです。その理由は、格子点データ当 りの計算量は粒子コードのようには大きくないので、ホスト計算機のメインメ モリと専用機のメモリの間をステップ毎にデータ転送していたらそれだけでも う性能がでないからです。このため、あまり極端に面倒なことをしないで性能 をだそうと思うと、格子点データをボード側に載せたままで、ホスト計算機の プログラムからそこそこ高速にアクセスできればいいような気がしてきます。

実は、落ち着いて考えるとこれは何か変な話です。というのは、例えば PCI-Express 16 レーンを使うと双方向で 4GB/s の転送バンド幅があるわけで すが、これは現在の PC の主記憶の理論ピーク性能と大して変わらないからで す。実際に問題がないかというとそうでもなく、それは特にランダム読み出し が非常に遅くなるからです。 PCI-Express で特に転送幅が大きいものはグラ フィックカードが主な用途なので、 CPU 側からの書き込みは結構な速度がで るように出来ていますが読み出しはあまり必要がないので非常に遅いのが普通 です。このため、単純に PCI-Express ボード上のメモリを主記憶にマッピン グして CPU がアクセスするので性能を出す、というのはちょっと難しい話に なります。もっとも、この辺はソフトウェア分散共有メモリのシステムで使っ ているようなページ単位でキャッシュする仕掛けで済むかもしれません。 もうひとつの方法は、チップ側に CPU をのせてしまうことでしょう。大して 速いものでなくていいわけですから、演算速度も大していりません。

ここまで書いてようやく気が付きましたが、これは、要するに IBM Roadrunner そのものですね。CELL が、非常に演算性能は高いけどどうやって プログラムを書くつもりなのか想像がつかない 8 コアのプロセッサと、まあ 普通な PowerPC アーキテクチャのマイクロプロセッサを統合したチップで、 でもこれだけだとなんかまともに使える気がしないのでOpteron もつけてみま した、というものだからです。RoadRunner 自体プログラミングモデルをどう するつもりかとかは不明です。が、流体計算とかでまともな性能を出すために はにはデータは CELL につながったメモリに置く必要があるからです。 この 構成だと、例えばネットワークの制御とか OS を走らせることとかには Opeteron が使えるのでその辺の開発の手間が省けるのが利点です。

そういう観点で見ると、CELL の問題はメモリバンド幅が PC 並でしかないこ とと、そのためにメモリバンド幅を同じにした時の価格や発熱があまり PC と 変わらないことです。まあ、これはつまり、 PS2 の時と同じで、数年チップ が速くならないということもあって x86 系に追いつかれる、というだけです。 もちろん、細かく見ると、浮動小数点演算性能、メモリバンド幅ともに中途半 端で、HPC に使うならもうちょっと上げるべきであった、ということになりま す。ゲームにそんな性能が本当に必要かどうかは疑問ですが。

ここでの結論を整理すると、結局のところ

を組み合わせ、

を実現するようなチップを例えば 130nm プロセスで作るのは必ずしも不可能 ではなく、その辺があると GRAPE-DR ではカバー出来ていないアプリケーショ ンも結構速く走る、ということになります。

AMD は ATI を買収して CPU、 GPU を統合するので、 GPU 側をもうちょっと HPC で使いやすいものにすれば上が実現されます。なので、この方針で何か作 るならそれと競争して勝てるかどうか、という話になるでしょう。

AMD の場合の鍵は、結局統合した GPU の側が普通にプログラムできるような ものかどうかになると思います。

メモリバンド幅を増やすのはどうしてもプロセス技術、チップ製造技術、パッ ケージ技術といったものに投資する必要があって、チップの中身だけではすま ないので、そういう技術が全部既にあってそれを組み合わせればすむ、という のでない限りお金がかかります。

大学とか国の研究所とかでお金も人手もないところで AMD とかにまともに対 抗しようというのは国家プロジェクトになって湯水のようにお金がふってくる とかいう話でなければ現実的ではありません。

まあ、これは結局のところ私が流体計算の専門家ではないから良くわからない、 というだけの話で、誰かがちゃんと考えればいいのかもしれません。
Previous ToC Next