伊藤は早速デジタル回路の勉強や、平方根回路の設計等を始めました。
私のほうは、これを作るのは伊藤が、と杉本が決めたので、では私はどうしよ
うか、、、という感じで、「トランジスタ技術」とかを買ってデジタル回路の
基礎を勉強したりしてました。 そうこうするうちに、伊藤が、初めから近田
が提案したような大規模な回路を作るのは大変なので、パイプラインの構造と
しては同じなんだけれど計算精度(データのビット幅)を減らしたものを作るの
はどうか?といってきました。伊藤によると、ビット幅を 8 ビットにすれば、
2入力の任意の演算を 512kbit の ROM (読み出し専用メモリ)でできるので、
回路が非常に簡単になるというのです。
杉本はではそれでやろう、といったように思います。私はというと、もちろん
最初に作るものはそれでいいけれど、それでなんかシミュレーションできたら
そのほうが嬉しいな、、、といった感じのことを考えていました。
8ビット精度でシミュレーションなんて全然無理ではないか?というわけです
が、実はそうでもないのです。例えばツリーコードを使う場合、重力加速度の
誤差は 1% とか、もっと大きいこともあります。そんな精度でいいか?という
と、 1% の誤差といってもステップ毎にランダムに変わるので、求まった軌道
の精度はもっと高いということがあり、球状星団の計算のような何千周期、何
万周期と計算するような問題には使えないのですが、例えば銀河の合体過程を
シミュレーションするような、短い計算ではこれで十分なのです。
もっとも、 8ビットというのは、浮動小数点表現の全部を合わせて 8 ビット
なので、例えば指数を 5 ビット、符号を 1 ビットとする仮数は 2 ビットに
なって誤差は 25% ということになります。これは上のツリーコードの 1% よ
りずっと大きいのですが、ここでもうひとつ大事ことは、1つの粒子への力は
他の沢山の粒子からの力の合計であるということです。 粒子数は例えば 1万
個程度です。この時に一つの粒子からの力の誤差がランダムだとすると、 1
万個合計した時に力の大きさは大雑把にいって 1万倍になりますが、誤差は
平均すると 100倍にしかならず、精度は2桁あがることになります。一般に、
このような誤差がランダムなものを積算すると、誤差は積算した項数の平方根
でしか増えないのです。
つまり、途中の計算がいい加減でも、積算のところだけ高い精度でやると結構
良い精度がでることになります。後は、最初の2tの粒子の座標の引き算にも精
度がいります。これは、原点から遠く離れた2粒子の座標を引き算した後で有
効数字がのこっている必要があるからです。もっとも、これは固定小数点にし
てしまえば LSI 1つで済み、 16 ビットもあれば十分でした。入力の座標を16
ビットにすると、積算の前の答は 32ビット、積算器は桁あがりがあるのでも
うちょっと必要になります。
途中の計算をいい加減にやっても本当に大丈夫か?というのは、理論的にはそ
うであってもやってみないと信じられません。これは、普通の計算機でシミュ
レーションしてみれば確認できます。早速、そういうプログラムを書いて実験
してみたところ、確かに途中の精度を 4 ビットとかまで落としても計算精度
に大きな問題は起きないことがわかりました。
それなら、というわけで伊藤に、最初と最後だけ固定小数点でビット長を長く
できない?というような話をしたら、できそう、という答でした。それで、座
標 16 ビット、積算 48 ビットという GRAPE-1 の回路構成が基本的に決まり
ました。
ホストインターフェースには、 RS-232C や SCSI 等も検討したのですが、安
くでき、設計も割合簡単な上にそこそこの速度がでるはずのもの、ということ
で GPIB (IEEE-488) を採用しました。これは、学部の学生実験で使っていて
PC-9801 用のボードが実験室から借りてこれた、というのも理由でした。これ
は、大体 10KB/s の速度が出れば、粒子数が大きい時にはまあまあの性能がで
るという見積りだったからです。 RS-232C では不足でした。 SCSI は理論ピー
ク 5MB/s で十分なのですが、難しそうだったので使いませんでした。また、
当時研究室に1台だけあった Sony NEWS ワークステーションにも GPIB インター
フェースカードがあったので、ちゃんと動いたらそっちにつけることできる、
というのが利点でした。 もちろん、 SCSI インターフェースも NEWS にはあ
るのですが、これはハードディスクや光ディスクドライブをつないでいたので、
それらとは別に GRAPE をつけて動かせるかどうか、 OS の中身をいじる必要
がないか、とか良くわからなかったということもあります。
GPIB は TI の 9914 というインターフェース IC があり、伊藤はまずそれを
のせた簡単な基板を作って石の動作を確認したあと本番のボード設計に入りま
した。GRAPE の名前はそのころに杉本が提案したものでした。最初は名前がな
くて近田パイプとか呼んでましたが、もっと格好いい名前がないといけない、
というので皆が色々考えたのですがあまり良い案がなくてしばらくしたある日
に GRAvity PipE で GRAPE でどうか?と杉本がいって、それは良いと
なったものです。
GRAPE-1 について、そういうわけで実際の設計や配線、デバッグは全部伊藤が
やっていて、私がしたことは当時助手で着任した戎崎と相談しながら使う部品
を検討した(主に、注文してから速く届くとかそういう観点で)こととか、伊藤
が当時川合研究室の助手だった朴のところに設計した回路を見せて意見を貰う
のについていったとか、それくらいです。 夏の間にいつのまにか回路ができ
ていて、8月の終わりころに、回路ができて動いたから ROM テーブルの中身を
作ってくれと伊藤にいわれて慌てて作って渡したら、なんだかあっというまに
重力計算ができるようになっていました。
ホスト計算機は最初 PC-9801 (多分 VM2という、CPU は V30 のモデル)であり、
最初のプログラムはN88-BASIC で書いていました。ハードウェアのデバッグ、
テストにはこれで十分なのですが、数千粒子とかでシミュレーションするには
速度が足りません。なので、まずは MS-C を使って動かすことにします。
NEC が売っていた純正の GPIB インターフェースボードを使っていたので、こ
れは ROM に GPIB インターフェースライブラリが入っていて、ソフトウェア
割り込みで使うことができました。これはそこそこ高速で、ある程度のシミュ
レーションができたはずです。
しかし、実際に研究に使うような計算をしようと思うと、 MS-DOS が動いてい
るだけの PC-98 ではなかなか大変です。初期条件を作ったり結果を解析した
りするプログラムは NEWS 上の UNIX で動いているからです。 UNIX の機械の
間では NFS でファイル共有ができていましたが、 UNIX と MS-DOS の間では
まだそんな気の効いたものはありませんでした。
そこで、 NEWS につなぐことにしました。ライブラリを使ってプログラムを書
いてみると、、、 PC-98 を使っていた時の 1/10 くらいのスピードしかでま
せん。これは一体どういうことか、と調べてみると、話は単純でメーカーの提
供してくれた GPIB のライブラリが遅い、ということがわかりました。
何故遅いか、ということですが、 GRAPE-1 では、ホストからの転送は6バイト
単位で動いていました。コマンドやアドレスにあたるものが4バイト、データ
が2 バイトです。で、ハードウェアはこの 6 バイト毎に GPIB のハンドシェ
イクをするようになっています。このため、ホストのプログラムは 6 バイト
毎に転送するライブラリルーチンを呼ぶようになっていました。
ところが、NEWS のほうのライブラリはそんな短い転送長では全く性能がでな
いものでした。大雑把にいって、1度ライブラリを呼ぶとデータ長に無関係に
1 ミリ秒くらいかかるので、 6バイト単位でライブラリを呼ぶと 6KB/s くら
いしか出ないわけです。
これでは使いものにならないので色々姑息な方法を考えました。今ならハード
ウェアといってもこういったインターフェース回路は FPGA で組むので、 6
バイト単位ではなくもっとまとめて受け取れるようにそっちをプログラムする
のですが、 GRAPE-1 では 6 バイト受け取ってハンドシェイクする、という回
路を 74系の標準 IC (CMOS のHC シリーズでしたが)のカウンタ IC とかシフ
トレジスタ IC とかを配線して作っていたので、そんな器用なことをさせるの
はボードから作り直す必要がありました。
色々考えたのですが、結局2つの非常に違うアプローチをしました。一つは、
NEWS のライブラリルーチン自体を書き直すことです。最初使っていた
NEWS-821 は CPU に 68020 が2個ついたモデルで、ユーザプログラムや OS カー
ネルは一方の CPU で走るのですが周辺装置の制御はもう一方が行うというも
のでした。当時やそれ以前のメインフレームでは CPU の他に I/O プロセッサ
があるのが当たり前で、そういう構成になっていたわけです。
そんなのだと、ライブラリをいじるには I/O プロセッサのほうのプログラム
をいじる必要があって、そんな資料はメーカーから簡単にはでてこないしでて
きてもやりたくないわけですが、ちょうどそのころソニーは新しく 68030 を
使った廉価版の NEWS を発売しました。これは I/O プロセッサとかそういっ
た邪魔ものはなくなっています。
教養学部宇宙地球科学教室の少ない予算から廉価版の NEWS を買ってもらって、
早速 GPIB ボードをさして GRAPE-1 につないでみました。すると、なんと今
までの I/O プロセッサつきの NEWS よりさらに遅くなっていて全く話になり
ません。今度は、データ長に無関係に 1KB/s くらいしか出ないのです。
これは、I/O プロセッサがなくなったので、 1 バイト読むのにハードウェア
割り込みを使って OS カーネルに制御を渡し、 終わるとスケジューラに戻す、
ということをしているかららしい、ということはすぐにわかったのですが、
ではどうしよう?というのが問題です。
幸い、この NEWS はソニーの純正商品ではなく、ハードウェアはソニーなので
すが、普通の UNIX を載せたモデルは東京エレクトロンが独自に販売していた
もので、そちらにお願いすると OS 周りの資料が色々でてきました。結局、そ
の資料を頼りにデバイスドライバを書いてなんとかすることになりました。
といっても、デバイスドライバなんてものを書くのは初めてなので右も左もわ
かりません。参考書1冊と、サンプルドライバのソースコードだけが頼りです。
とはいえNEWS の GPIB ボードは、GRAPE-1 で使ったのと同じ TI の 9914 チッ
プが載ったボードだったので、石に何をすればいいのかは良くわかっていまし
た。問題は、そもそもデバイスドライバとはどういう仕掛けで書くものか、と
かそういうことです。
その辺が良くわからなかったので、なるべく安直な方法でやることにしました。
具体的には、 9914 の制御レジスタをユーザプロセスのアドレス空間の中にそ
のままマッピングし、ユーザープロセスから OS を介さないでそのままハード
ウェアをアクセスすることにしました。これは、セキュリティとかシステムの
安定性、つまり、ユーザプロセスが変なことをした時にシステムが落ちないか
どうか、といった観点からは問題があるわけですが、 GRAPE-1 の性能を出す
ことが目的で、ハードウェアにアクセスするのはライブラリだけですからそれ
がちゃんとしてればいい、ということにします。
さらに、データがくるのを割り込みで処理するのではなく、単純にレジスタを
ポーリング、つまり、データがくるのを CPU がループで待つ、というふうに
しました。これは、マルチタスク OS ではやってはいけないことになっている
のですが、別に GRAPE-1 のプログラムだけが速く走ればいいのでそんなこと
は気にしません。
これらは劇的な効果があり、大変素晴らしい性能がでるようになりました。
計算速度ですが、当時我々は2つの粒子間の重力相互作用の計算を全部で 30演算と
数えていて、最初はクロック 4MHz だったので 120 Mflops 相当といっていま
した。しかし、1996 年頃から Los Alamos のグループが重力相互作用の計算
を全部で 38 演算と数えるようになったので、我々もそれに合わせて性能を計
算するようにしました。この稿ではそれを使うことにすると、 152 Mflops と
いうことになります。年度末くらいには 8MHz でも動いて、 304 Mflops とな
りました。
速度の計算にこのような曖昧さがあるのは、平方根演算や割算をどう数えれば
いいかはっきりしないからです。普通計算速度を Mflops とか Gflops で書く
時には、掛け算と足し算、引き算の数を数えます。しかし、割算は大抵の計算
機で掛け算より時間がかかるので、これも1演算として数えると割算が必要な
計算では計算機の性能が見かけ上非常に低くなってしまいます。これは、平方
根や、その他数学関数でも同じです。
Cray のベクトル機では割算の時間は掛け算の 7 倍くらいだったので、その
程度で換算する、ということが昔は良く行われましたが、最近の計算機はもう
少しかかるものが多いのでもう少し大きい目の数字を、Los Alamos の人達は
したようです。
ちなみに、 300Mflops という速度は当時の東大大型計算機センターの日立
S-820 のちょうど 1/10で、ハードウェアコストはだいたい 1万倍くらい違う
ので結構お買い得だったことがわかるかと思います。もちろん、ハードウェア
コストに伊藤やその他関係者の人件費を適当に仮定して入れると(実際には大
学院生は給料貰うどころか授業料を払ってますから、人件費はマイナスですが
それを入れると計算機の値段自体がマイナスになってしまいます)差は100倍く
らいまで減るのですが、そういう計算をするならベクトル計算機を使うにも人
件費がかかるので人件費の差を計算する必要があります。そうすると 1000倍
くらいというのが妥当な数字でしょう。
GRAPE-1 は銀河の衝突のシミュレーションなどに使い、90年4月に助手に着任
した奥村さんや、同じ時期に卒業研究で研究室にきた船渡さんがシミュレーショ
ンに使いました。また、銀河の合体や銀河群の進化などのアニメーションを作っ
て、ノート PC で見せる、といったこともやりました。
GRAPE-1 は伊藤君が中心で設計・製作したのですが、それと時期を同じくして
もっと計算精度が高くて、球状星団の進化の計算もできるようなものを作ろう、
と杉本が言い出し、国立天文台から 250万円ほどの研究費をもらってきました。
こちらは戎崎が中心になってやる、ということで、 GRAPE-2 という名前で開
発を始めました。計算精度を上げることと、球状星団のような系のための計算
アルゴリズムである独立時間刻み法というものを使うことが目的です。
計算精度を上げるのは、基本的には GRAPE-1 で使った ROM の代わりに普通の
浮動小数点演算ができる LSI を使う、ということになります。 CM のところ
で書いたように、当時はちょうどそういうものが利用可能になった数年後で、
アナログ・デバイセズ、ワイテック、TI、LSIロジック等の数社からそのよう
な LSI がでていました。多くは32ビットで価格は2-5万円、64ビットのものは
だいぶ高かったです。
なので、全部64 ビットでやるのは諦めて、 GRAPE-1 で演算毎に精度を変えた
のと同様に最初の座標の引き算と最後の積算は倍精度、それ以外は単精度でや
ることにしました。汎用計算機では最近になって SSE をもった x86 プロセッ
サ、CELL や GPU のような単精度が速いシステムがでてきたので、部分的に単
精度で実質的に倍精度を実現するアルゴリズム、というのを研究しようという
雰囲気がでてきていますが、 GRAPE では 1990 年にこれをやっていたわけで
す。
ちなみに、SSE 等では演算毎に指定する、というレベルで単精度と倍精度を混
ぜて性能を出すのは困難で、それは精度変更自体が命令で、サイクルを消費す
るからです。 GRAPE のような専用パイプラインでは、精度変更は基本的には
配線だけの話なので、演算毎に好きなように変えることができます。
GRAPE-1 に比べると、計算精度が高く、実際に球状星団の計算に使えます。と
いっても速度は大したことはないので、粒子数はあまり大きくできません。そ
れで性能を出すには通信が速い必要があります。ということで、GPIB ではな
く VME バスというものを使いました。これは基本的には 68000 のプロセッサ
バスをベースに汎用バス規格を作ったもので、当時の産業用コンピュータの他、
ワークステーションでも採用例が多かったものです。特に、また同じ研究室の
NEWS ですが、これは VME バスのカードを挿すことができる拡張ボックスがあ
りました。
GRAPE-2 は VME バスに対するスレーブとして、またバースト転送にも対応し
ない単純な回路でやることにしました。と、自分でしたみたいに書いてますが、
この辺は実は伊藤がまたやっています。GRAPE-1 に少し遅れて戎崎が中
心ということで初めたのですが、 GRAPE-1 が結構すぐに出来て伊藤が時間
ができたのでじゃあそっちも、ということになったものです。といっても、伊
藤にもなかなか難物だったようで、回路設計、製作が終わってからもかなり
苦労してデバッグとかしていました。特に、なかなかノイズでの誤動作が消え
ない、ということがありました。今から考えてみると、消費電力の大きなLSI
のためのボードとしては電源周りの配慮が不足であったと思います。
最終的には、電源電圧を下げて動作速度を落としてノイズを抑える、という方
法で解決したようです。
アーキテクチャの話に戻ると、 GRAPE-1 では空間座標の3成分を計算するため
に 3 個の同じ回路を用意して並列動作させて性能を稼いでいるのですが、
GRAPE-2 ではそれはあまりに製作が大変だということで 1 つの石で x, y, z
の3成分を順番に処理することで回路規模をほぼ 1/3 にしました。で、クロッ
クは 4MHz で、速度は GRAPE-1 の 1/3 の 50Mflops、ハードウェア費用は
GRAPE-1 の 10倍ですが、これは人件費に比べて小さいとすると汎用スーパー
コンピューターに比べて価格性能比が数百倍よいというのはあまり変わらない
わけです。GRAPE-2 は色々なシミュレーションに使われました。
GRAPE-1 を始めた 1989年春に私は博士課程3年だったのですが、この年に無事
に学位をいただいて、さらに幸運なことに同じ東大教養学部の情報図形科学教
室というところで職を得ることができました。この時に同時に現在は東工大の
教授になっている井田と、国立天文台の助教授になっている奥村がそれぞれ基
礎科学科第二と宇宙地球科学教室の助手として採用され、 GRAPE にもかかわっ
てくれることになりました。井田は早速惑星形成過程の N 体シミュレーショ
ンを始め、 GRAPE-2 を使っていくつもの重要な成果を上げました。また、91
年に卒業研究に来た小久保をこの分野では世界をリードする研究者に育ててい
ます。井田は 92年には助教授となって東工大に移りました。奥村は銀河の合
体のシミュレーションと観測との比較等で成果を出すと同時に次の GRAPE-3
の開発にかかわります。
GRAPE-2 の成果の一つは、中心にブラックホールがある銀河同士の合体で楕円
銀河に見られる中心の明るさがフラットな領域の存在を説明できる可能性があ
る、ということを初めてしめしたことです。 GRAPE-1 での計算で、銀河同士
の合体で楕円銀河の色々な性質を良く説明できる、ということは確認できたの
ですが、一つどうしても上手くいかなかったことがありました。それは、
コア半径があわない、というものです。
楕円銀河は一般に中心ほど星の密度が上がり、明るくなるのですが、中心の狭
い領域ではそれほど密度が上がらなくなる傾向があります。小さい楕円銀河で
は、望遠鏡の分解能の限界までみても明るくなっているものが殆どなのですが、
銀河団の中心にあるような大きな楕円銀河では必ずしもそうではなく、あると
ころから密度が上がらなくなるのです。
この密度がほぼ一定になる領域のことを核(コア)といいます。大きな楕円銀河
については、銀河自体の大きさとコアの大きさにほぼ比例関係があることがわ
かっていました。ところが、銀河同士の合体をさせると、出来た銀河のコアは
最初の銀河のコアから大きくなりません。銀河全体のサイズは大きくなるので、
これは観測で見つかっている比例関係がシミュレーションでは再現できない、
ということになります。これまでもそういうことを示唆する結果はあったので
すが、 GRAPE-1 で今までやられていなかったような大規模で精度が高い計算
をしても結果は同じでした。つまり、何かが正しくなかったのです。
戎崎、奥村と牧野の3人で色々議論しましたが、あんまり展望は開けませんで
した。観測の分解能の問題とかを考えても、大きな銀河でコアが大きくなると
いうのは分解能のせいだけではなさそうでした。
ある日、戎崎が、「中心ブラックホールがあったら影響しない?」といいまし
た。私は言下にそんなのは質量もたいしたことないし効くはずがない、と返事
をしたような気がするのですが、戎崎は、そうじゃなくて、質量は結構大きい、
楕円銀河だと星の質量の合計の 0.1 パーセント以上とかあるのも珍しくない、
と教えてくれました。そうすると、話は全然変わります。球状星団では連星が
できる、という話を前のほうで書きましたが、そういう連星では連星の重力エ
ネルギーは他の普通の星の 100倍近くまでもあがることがあります。合体する
2つの銀河が両方ともブラックホールをもっていると、それらは重いために
「力学的摩擦」という効果が働いてできた銀河の中心に沈み、連星をつくりま
す。もしもブラックホールの質量が星の質量の合計の 0.1 パーセントもある
なら、その重力エネルギーは銀河全体の重力エネルギーの 10パーセント近く
まで増えることができるのです。これは、コアどころか銀河全体の構造に影響
するほどの膨大なエネルギーです。
それなら、ということで、できたばかりの GRAPE-2 で合体過程の計算をしま
した。GRAPE-1 の時には計算プログラムは全く新しく書いたのですが、
GRAPE-2 ではより複雑なプログラムを使うので、ゼロから書くのではなく
元々スーパーコンピューターで使っていた、ケンブリッジのアーセスが書いた
プログラムを重力相互作用計算のところだけ GRAPE-2 を使うようにしたもの
を使います。この、部分的にだけプログラムを修正する、という方法は、
GRAPE を使う時の基本的なアプローチになります。
結果は。見事にブラックホールなしの合体だとコアが大きくならないけれど、
ブラックホールありだと大きくなる、となりました。この計算結果は Nature
に論文として発表することができ、 GRAPE-1 の論文自体が Nature に載った
のにつづいて 2 本目の Nature 論文、ということになりました。
この研究にはずっと続きがあり、巨大ブラックホール連星の進化とその親銀河
の構造への影響、というテーマは観測的にも理論的にも大きな分野に成長しま
した。もちろん、これは私達だけの貢献ではないし、私達が最大の貢献者とい
うわけですらないのですが、親銀河の構造への影響、という観点を持ちこんだ
のは私達、といっても主に戎崎ですが、の貢献だと思います。
GRAPE-1 と GRAPE-2 で、実際にこういう計算機を作ってちゃんと研究に使っ
て成果を出すことができる、ということは十分にわかったのですが、それがで
きるとなると次はもっと速いものを、ということになります。当時は LSI を
試作するのは 1-2千万円でできたのですが、さすがにこれは教室の予算や、天
文台からもらってこれる開発費では足りません。また、それ以前にそもそも
LSI を設計するっていうのはどういうことでどうやってやるのかも誰も知らな
いわけです。
お金がどれくらい、というのを見積もるにも、どんなものを作るか決めないと
メーカーと相談にもなりません。ということで、伊藤が GRAPE-2 をやってい
た89年末、私は博士論文を提出して時間ができたので LSI を作るとしたらこ
んなもの?という回路図、といってもそんなに詳細ではないブロック図レベル
のものを書いていました。これを、半導体開発もやっていた東京エレクトロン
に持ち込んで、費用とかの見積もりをしたのです。それででてきた数字が、
GRAPE-1 の精度を少しあげたくらいのものだとまあ開発費が1500万円位という
感じでした。プリント基板等にもお金がかかるので、 2000万くらいいること
になります。この頃に、本郷で並列計算機の開発をしていた田中先生の研究室
にお邪魔して、 LSI 開発の様子を教えてもらったりもしました。
杉本は科研費を申請していましたが、これは当たって 700万円位の枠で出して
いてとても足りません。そこで、最初は色々違うことを考えました。
一つは、GRAPE-1 の回路をそのまま、あるいは少し改良した上で、10枚くらい
作って、並列処理で性能を上げる、というものです。材料費は安いので不可能
ではありません。が、性能はなかなか上がらないのがつらいところです。
もう一つは、 FPGA、あるいは当時は LCA (Logic Cell Array) といっていた、
中の論理回路を変更可能な LSI を使ってパイプラインを実現することです。
当時使えた FPGA は代表的なのが Xilinx の XC3000シリーズというもので、
公称 9000 ゲートというものでしたが実際には到底そんなものではなく、数個
使って GRAPE-1 相当が入るかどうか、という程度であまりメリットはなくて
断念しました。当時、東大物理の大学院生だった泰地が FPGA を使って統計物
理のシミュレーション用の専用計算機を作っていたので、その話も聞いたりし
たはずです。
実際に LSI を作ると、チップ1つに GRAPE-1 や、あるいは GRAPE-2 相当の回
路を入れることが計算上はできます。で、ボードだと我々の技術では 10MHz
で動かすのも大変だったのですが、チップにしてしまえばもっとクロックを上
げるのはそれほど難しいことはありません。これは、単に長い配線とかがなく
なるの、高速で出力しないといけないチップはメモリくらいになってノイズも
でにくくなるからです。しかし、もっとも大事なことは、ボード上に沢山チッ
プを載せて並列化できることです。
GRAPE がすることは重力計算だけです。重力計算では、単純なアルゴリズムで
は全部の粒子が他の全部の粒子からの力を受けます。従って、これをハードウェ
アで計算することを考えると、沢山の粒子への力を沢山のパイプラインで並列
に計算する時に、力を及ぼすほうの粒子は同じものでかまいません。つまり、
メモリユニット1つに沢山のパイプラインチップをぶらさげる形で並列計算機
が構成できるわけです。
このやり方だと、普通の並列計算機や、あるいは GRAPE-1 のボードを複数作
る、というやり方に比べて、極限まで回路全体に対する演算パイプラインの割
合を高くすることができます。この頃の普通の並列計算機だと、ボード1枚に
CPU が1つ載って、他にメモリや周辺チップ等が数十個載っています。で、ク
ロック毎に 1-2 演算するわけです。これに対して、カスタム LSI を使った
GRAPE だと、数十演算するチップを数十個ボードにのせて、 1000 演算程度さ
せることができます。つまり、ボード当りの性能が、クロックが同じなら 500
倍程度違うわけです。クロックが数倍違ったとしても 100倍以上は性能差がで
ます。
システム全体の価格を考えると、 LSI チップの量産費用は普通はそんなに大
きくなりません。普通の大きさのボードを作ると、量産コストが普通なら 100
万円程度になるのに対して、チップの量産コストは当時ならせいぜい 1-2万円
だったからです。このため、数十個 LSI を載せてもコストは倍にもならない
のです。しかし、性能は汎用計算機に比べると 1000倍近く、専用パイプライ
ンを汎用チップで作るのに比べても数十倍になるので、チップ開発の初期コス
トさえなんとか工面できれば素晴らしく高性能なシステムを実現できます。
というようなわけで、89年末から絵を描いていたわけですが、90年度に使えそ
うな研究費では普通にメーカーに LSI 試作を頼むには十分ではありませんで
した。杉本は 90年には特別推進研究というもしもあたったら総額3億円という
予算申請をします。これは、専用 LSI を作って数千個並べて、テラフロップ
スを超える計算速度を実現する、という計画です。が、そんなのをいきなりや
るのも大変なので、もしも 90 年度の予算で LSI の開発をやってみることが
できれば非常にありがたかったのです。
このあたりは杉本の本が詳しいのでここでは繰り返しませんが、杉本や戎崎が
色々努力した結果、富士ゼロックスの研究所と共同で LSI を開発する、とい
う話が 90年の 9 月くらいにまとまりました。この研究所は SCS (シリコン・
コンパイラ・システムズ) という会社の LSI 自動設計ツールのユーザーで、
そのソフトウェアを使って開発するということになりました。
そうすると、結局 LSI 設計の細かい作業はゼロックスのほうでやってくれる
ので、こちらは詳細な動作記述、特に演算部分の仕様とシミュレータを作るの
が主な仕事になります。 これは 10月にやって仕様とシミュレータをゼロック
スのほうに回しました。
これは、最初であるということもあってあまりチップサイズを大きくしたくな
かったのと、設計も簡単にしたかったので GRAPE-2 相当ではなく GRAPE-1 相
当を LSI 化することにしました。とはいっても、実は GRAPE-1 そのままでは
LSI 化はできません。これは、 GRAPE-1 では演算に ROM を使っていたからで
す。 ROM には 512kbit とか 1Mbit のものを複数使っていたので、これをそ
のまま LSI 化すると膨大な面積になってしまいます。
GRAPE-1 の設計の時からこういう問題はあるというのはわかっていました。も
しも LSI 化するなら演算器をもっと小さくする必要があったわけです。
ROM はどんなところに使っていたかというと、例えば最初に固定小数点で引き
算した結果を対数表現に直すところです。 ROM では引き算の結果をそのまま
入力にすれば良いので簡単なのですが、ちゃんとハードウェア設計するならもっ
と小規模にできます。つまり、普通に固定小数点形式から浮動小数点形式に変
換するのと同じように、まず先頭の 0 の数を数えて指数分を求めて、それか
ら小数部をシフタに入力して取り出し、求まった小数部を対数形式に変換すれ
ばいいわけです。
こうすると、小数部の変換にはROMテーブルを使ったとしても、そのテーブル
の大きさは小数部が 5 ビットとして32しかなく、 512 kbit の ROM は 8bit
64 k語なのでそれに比べると 1/2000 のサイズになります。もちろん、シフタ
や 0 を数える回路が余計にいりますが、これらはテーブルに比べるととたい
したことはありません。他の ROM も同様な考え方で論理回路と組み合わせる
ことで小さくできました。そのような回路構成と動作記述はこちらでやり、実
際に SCS のツールで物理設計や配置配線といった作業をするのはゼロックス
側でやりました。SCS の設計ツールは、加算器、シフタといったユニット毎に
物理的なトランジスタ配置を生成するもので、当時一般的だったゲートアレイ
を使うものではなく、例えばシフタならシフタに最適化されたトランジスタを
使った物理設計を生成するもので、理論的には小さなチップサイズと高い性能
が実現できるはずですが、その代わりに回路生成のアルゴリズムは単純で、
例えば乗算器やシフタでは遅延時間がビットサイズに比例するものになるとい
う欠点もありました。その辺も気になっていたのであまりビット長が大きくな
い回路ですむ GRAPE-1 相当で設計をしました。
これに先だって、 VME インターフェースを使って高速化した GRAPE-1 である
GRAPE-1A というのを、これは伊藤と、この年に卒業研究できた福重が開発し
ていました。上の回路構成は部分的には GRAPE-1A のために考えたものです。
これは 90年の終わり頃には完成していたはずです。
チップは 91年の春頃には完成して、それを載せるボードは奥村が設計して、
チップより少し先に出来ていました。ボードはプリント基板ではなくラッピン
グ配線で、動作クロックは 10 MHz 程度でしたが 40cm 角のボードに 24個チッ
プを載せて 9.1 Gflops と GRAPE-1 に比べると 40倍の性能を出し、さらにこ
のボードを2枚並列動作させて 18Gflops の理論ピーク性能を実現しました。
当時の最高速のスーパーコンピューターは NEC SX-3 の 22 Gflops ですから、
ほぼそれに匹敵するところに到達したことになります。 SX-3 のクロック周波
数は 340 MHz で、 GRAPE-3 は 10 MHz なので 1/34 ですが、それだけ沢山の
演算器を並列動作させた、ということです。
GRAPE-3 では、インターフェースは GRAPE-2 と同様の VME インターフェース
を使い、 VME カードが入るように設計された UNIX ワークステーションであ
る SUMIStation S-300 というものを使いました。これは CPU が MIPS R-3000
で、OS は RISC-OS の珍しいマシンでしたが SUN Sparc に比べて高速で、
VME がついて安価なマシンということで導入したものです。
さて、杉本は 90年にも大規模システムを作るための予算申請をしたわけです
が、これは落ちました。が、GRAPE-3 で、我々にも LSI を作ったりできる、
とわかったので、杉本はもう91 年にもう一度申請します。杉本の本「手作り
スーパーコンピューターの挑戦」はちょうどその時期に書かれたものです。
この年にはまず面接審査まで進むことができ、それには私も鞄持ち、というよ
り実際に GRAPE-3 のボードを運ぶ役で杉本にお伴しました。この面接でのプ
レゼンテーションはかなりインパクトがあったと思われ、結果的には 92 年度
から大規模並列システムの開発をスタートさせることができました。これが
GRAPE-4 となります。
GRAPE-4 では当初 GRAPE-3 を一緒にやったゼロックスのグループと一緒に、
という方針で検討していましたが、これはちょっと難しいということになりま
した。技術的な理由は、ビット長が長い乗算器やシフタは SCS のシステムで
は大きくなりすぎて性能がでないので、別の会社を使う必要があった、という
ものです。大抵のプロジェクトでは技術的に望ましいことでも政治的な事情と
か経緯とかでその方向にいけない、ということになるのですが、杉本の決断で
技術的にやりやすい方向で進めることができました。
GRAPE-4 では、 LSI ロジックを使うことになりました。半導体プロセスとし
ては決して最新ではなかったのですが、乗算器を始めとするライブラリの自動
生成ツールが優れていて、試作コストが安かったことが大きな選定理由です。
GRAPE では演算毎に精度を変えたり、入力データの範囲が制限されていること
を使って専用の演算回路を作ったりすることで性能を上げるわけですが、その
ためには乗算器、加算器、シフタといった演算回路の構成要素をビット長や必
要速度を指定すると自動生成してくれるツールが不可欠です。そのあたりが充
実しているメーカーというと、少量多品種の経験がある LSI ロジックのよう
な米国企業、ということに当時はなりました。もうひとつの理由は、我々は全
部で1000 個とかいう話をするのですが、国内メーカーの多くは月何万個くら
い作りますか?という話をしていて2桁くらい話があわなかった、ということ
です。
GRAPE-4 では GRAPE-2 相当をチップ化するわけですが、色々計算すると
GRAPE-3 でやったような x, y, z 3成分を並列処理ではチップサイズが大きく
なりすぎて大変だとわかってきました。といっても、では x, y, z を順番に
処理では性能が低くなりすぎます。目標を 1テラフロップスとしたので、あん
まりそれを大きく下回ると恥ずかしいわけです。
まあ、計算機に限らず、いろんな研究開発のプロジェクトで、予算が予定の数
倍かかって性能は数分の1ということはあるわけですが、下をみればきりがな
いので志は高く持つ必要があります。
というわけで色々考えたのですが、とった対策の一つは、「重力の時間微分も
計算する回路をつける」ということです。ちょっと数学的な話になってすみま
せんが、球状星団の計算では高い精度がいるので、今までは加速度を積分する
のに前の何ステップかの加速度をとっておいて、それらを滑らかにつなぐよう
な近似式を作り、その近似式を積分する、という方法を使っていました。
この方法ではステップ数を増やすと精度があがる、正確にはステップサイズを
小さくした時の精度のあがりかたが良くなります。通常は4ステップを保存す
る方法を使います。
しかし、時間積分の精度を上げる方法は他にも色々あり、その一つはステップ
毎に重力だけでなくその時間微分も計算し、それを使って近似式をつくること
です。この方法では、普通にやると 4ステップ必要なのと同じ精度が2ステッ
プででるので、結果的に計算を速くすることができます。この方法がそれまで
何故つかわれていなかったのかは良くわからないのですが、1988 年に Piet
Hut とそういう方法もあるのでは?という話をして、実際に性能評価もしてう
まくいくことはわかっていました。
この方法には、ハードウェアでやる時にには特別なメリットがあります。
重力の時間微分は重力自体に比べて小さいので、結果の精度を同じにするため
必要なビット長は短くなるのです。重力の精度を 24 ビットとすれば、時間微
分のほうは例えば 19 ビットもあれば十分です。乗算器の回路規模はビット長
の2乗に比例しますから、 19 ビットでいいと回路規模が 40% くらい小さくて
すむことになります。
さらに時間微分の時間微分、といったものも計算すればもっと精度はあげられ
るし、ハードウェアの場合には回路規模はあまり増えません。今良く考えてみ
るとそういう計算法もありな気がしますが、とりあえず当時はそれは考えませ
んでした。
この方法を使うことで、1ミクロンの設計ルールで 14mm 角、 40万トランジス
タのチップに演算20個相当の回路を入れることができました。このチップの実
際の設計は先にでてきた、現在理研でチームリーダーを務めている泰地が行い
ました。泰地は92 年に学位をとったのですが、ちょうど井田が東工大に転出
した後に助手で採用することができました。このチップの設計は、泰地が赤坂
にあった LSI ロジックのデザインセンターで LSI ロジックのツールを使って
行い、回路図入力からシミュレーションまでやっています。最後の配置配線は
LSI ロジックのエンジニアがやりました。
なお、 GRAPE-4 では重力計算の他に「予測子」といって他の粒子の位置を計
算する回路も作っていて、これもチップには入りきらなかったのでもうひとつ
チップを作りました。これは牧野がやったのですが、浮動小数点演算器等の要
素回路は全部泰地が設計したのを流用したので設計は1ヶ月ほどで終わりまし
た。
これらの LSI 開発に先行して、浮動小数点 LSI を並べたパイプラインでこの
時間導関数を計算する方式のものも開発しました。これは今は国立天文台助教
授になっている小久保がやって、彼はこの時修士1年でした。これには HARP-1
という名前をつけています。
この頃に「半自
動配線ツール」というのを開発していたように思います。
ラッピング配線では、人が基板の裏側のピンの間を専用のツールで配線してい
くのですが、どことどこを配線するかを回路図から見ていたのでは時間がかか
るし間違いも発生します。設計自体は CAD を使っているので、石のピン配置
や基板上での位置をデータとしていれておけば、どこを配線するべきか計算機
に指示させることができます。これを画面上で指示するだけでなく、 XY プロッ
タに腕をつけて基板上で直接位置を指定させるようにしたのです。これによっ
て間違いが少なく、確実に配線ができるようになりました。
91 年から 2 年にかけては他にも色々なものを作っていて、そのなかで重要な
のは GRAPE-2A です。これは、 GRAPE-2 を速くするというのと、分子動力学
計算に使えるようにするということが目的で、大正製薬の研究グループと共同
で開発したものです。実際の設計は例によって伊藤がやりました。これはコピー
も作ったりしてあちこちで使われました。
もうひとつ重要なものは GRAPE-3 のプリント基板です。 GRAPE-3 はなかなか
速いので、コピーが欲しいという話があちこちの研究グループからきました。
色々経緯があって、その頃助手で京都大学から移ってきた蜂巣がプリント基板
の設計をし、最終的には動作するものを完成しました。これは、オリジナルの
GRAPE-3 で 24 個のっていたプロセッサチップを 8 個に減らし、基板サイズ
も小さくして標準的な VME カード用のラックに入るようにしたものです。動
作クロックもも上がって 20MHz で動作したので、随分高い性能になりました。
これはその後、ロジックハウスという商社の方に紹介していただいた企業から
商品化し、特に海外に合計 100枚近く売れたようです。
話は戻って GRAPE-4 です。93年春には2つのチップが完成し、まずそれらが載
る評価用ボードをこれもラッピング配線で作りました、というと私がやったみ
たいですgこれも泰地です。夏頃にはこのボードが無事に動いて、GRAPE-2 の
10倍以上の計算速度を実現しました。このボードは VME 接続です。さらに、
このボードをプリント基板化したものも泰地が作りました。
さて、 GRAPE-4 では最終的に 2000個近くのチップを作って並列動作させ、1
台のシステムとして動作させる必要があります。普通に基板を作ると頑張って
大きな基板にしても載る LSI の数は 20から 30なので、少なくとも 60枚程度
の基板を作る必要があるわけです。また、これらの基板をどうやって制御して、
プログラムをどうやって走らせるか、という問題もあります。また、 60枚の
基板をどんな箱にいれて、どうやって電源供給してどうやって冷却するか、と
いったことも考えないといけません。
まず、ホスト計算機をどうするかを考えないといけません。計算速度がテラフ
ロップスくらいしかないので、システムが完成する 1995年頃の汎用 CPUの速
度を多少楽観的に見積もると、ホスト CPU 1 つでも計算速度は十分だとわか
りました。問題は通信速度ですが、これも当時のワークステーションのいくつ
かの専用バスなら大丈夫でした。当時使えた高速ばバスは Sun の Sbus と
DEC の TURBOchannel です。 IBM の MicroChannel も検討しましたが、規格
が複雑で良くわからなかったのでパスしました。 Sbus と TURBOchannel はど
ちら比較的簡単に作れるもので、また開発キット等も用意されていました。こ
の2つでは、 CPU がより高速なものがあった DEC のほうが良いであろう、と
いうことで TURBOchannel にしました。
TURBOchannel は理論ピーク転送速度が 100MB/s です。この速度を出すために
はカード側が DMA 転送する、つまり、アドレスを出してデータを出すなり受
けるなりするのをカード側がする必要があります。
一般にはこういった周辺機器が DMA をするのは色々難しいことがあります。
一つは、GRAPE-1 の時にもあったように、割り込み制御をするかどうかです。
割り込みを使うと周辺機器が DMA している間に CPU は他の作業をして、周辺
機器のデータ転送が終わったら処理を戻す、ということができます。これは、
OS がマルチタスクで動いていて、DMA の間に他の人の他の計算をしたい、と
いうような場合には有用ですが、1つの計算に CPU の全能力を使う時にはあま
り意味がありません。むしろ、割り込みの度に OS に制御がいってしまって、
実行プログラムから見るとオーバーヘッドになります。
というような理屈をつけて割り込みのような面倒なことはしないことにします。
DMA をするのも、GRAPE-1 の時に 9914 をユーザープログラムから直接制御し
たのと同様に、こちらで作った TURBOchannel カードを直接制御します。 DMA
を起動するために OS に制御を渡したりはしません。これにより、ソフトウェ
アによるオーバーヘッドを根絶することができます。
最後に問題になるのは、ではカードに、メインメモリのどこをアクセスしろと
いえばいいか、ということです。 MS-DOS の PC-98 ならともかく、 UNIX が
動いているワークステーションでは仮想記憶方式を使っています。 これは、
つまり、アプリケーションプログラムが見ているメモリアドレスは、実際に
CPU やデバイスのアドレス線が出す物理的なアドレスではなく、 CPU の中で
変換されたものだということです。このため、例えばアプリケーションプログ
ラムから見えているあるアドレス(仮想アドレス)に書いて欲しい、という時に
は、その仮想アドレスに対応する物理アドレスがどこかをなんらかの方法で発
見して、そこに書けという指示をカードに送る必要があるわけです。
この辺は DEC の資料にもあまりちゃんと書いてなかったのですが、サンプル
プログラム等をみてそれらしい関数を呼んで見るとちゃんとその場所にデータ
が入るのでまあ良かったということにしました。仮想アドレスと物理アドレス
の対応は 4KB毎なので、 DMA の最大サイズを 4KB にすることにします。実際
には、TUBROchannel の仕様で 256ワードを超えてはいけないというものもあ
ったはずです。
この方法の問題は、仮想アドレスに対応する物理アドレスがない(まだ割り当
てられていない)と破綻することと、いつのまにか対応する物理アドレスが変
わってしまうような場合にも破綻することです。この辺はまあ実際に作って動
いたらいいかな?というふうにやってました。
Linux では、この辺はずっとわかりやすくなっていて、カーネルの機能として
こういった DMA 用の領域をはじめから割り当てらるようになっています。こ
のため、ユーザープロセスでとった空間の物理アドレスを計算するのではなく、
逆にあらかじめ物理アドレスをとっておいた領域をユーザ空間の中にマッピン
グしなおすことになります。この方法では、ページサイズを超えた連続領域を
確保できるし、いつのまにかなくなってしまうといったことも起こらず安全で
す。
TUBBOchannel を使ってピークとしては 100MB/s と今まで使っていた VME に
比べて桁違いに高速な転送が可能になったのはいいのですが、まだ 60枚の基
板をどうやって1台のホストにつなぐか、という問題は解決していません。
GRAPE-4 では、まず、 MCM (マルチチップ・パッケージ)を作って 8 個のチッ
プを1パッケージに入れることで、ボード 1 枚当り 48 個のチップを載せるこ
とにしました。ここでは京セラのお世話になりました。パッケージの値段も数
が減る分安くなり、基板の枚数も大幅に減ったのでこれはかなりコスト削減に
貢献しています。但し、8個いれたチップが全部動くとは限らないので、ボー
ドの上でどれか死んでいたらアドレスをつけかえて、47個動いているものとし
て使えるような仕掛けをつけました。
これによりボードは40枚ほど、ということになりました。 GRAPE-4 の最終案
では、ボード 36 枚を9枚ずつに分けて、その 9 枚を1枚の「制御ボード」と
いっていたものにつなぎ、それがさらにホスト計算機につながる、という構成
になりました。4枚の制御ボードはそれぞれ別の TURBOchannel カードとフラッ
トケーブルでつなぎます。ここは TURBOchannel と同じ 32 ビット幅
25MHz 転送です。さして速いわけではありませんが、とても高い同軸フラット
ケーブルを使ってみました。 4本だけなので大した金額にはなりません。
制御ボードとプロセッサボードの間は単純な同期式バスです。バックプレーン
とかを新規設計するとまたお金がかかるので、 VME バスのバックプレーンを
そのまま使います。しかし、カードは大きいしまたそのままでは速度がでない
ので、 VME バスのバックプレーンを 3 枚使って、 32幅のデータを3個並列に
転送するようにしました。
制御ボードの重要な役割は、計算ボードから返ってきた答を合計することです。
各ボードは勝手に自分のところに送られてきた粒子への力を計算するのですが、
ここで力を受ける粒子はボード間で共通にすることを考えます。そうすると、
各ボードで力を及ぼすほうの粒子は別にすることになり、ボード上の粒子メモ
リでデータの重複がなくなるのでメモリが小さくてすみます。また、アルゴリ
ズム上も都合がよくて性能が上がります。
ここの合計の計算は、それほど速度は必要ないのですが FPGA でできるほどで
もありません。これは、結果が浮動小数点で返ってくるからです。まあ、固定
小数点で返せばよかったのですが、作ってしまったものはしょうがありません。
ここには、 GRAPE-2 で使った TI の 8847 を使うことにしました。トラブっ
た実績がある石なので不安はあったのですが、電源部分を強化するとかで予定
のクロックで動作はしました。しかし、なんだか数年たつと寿命がきたようで、
結構どんどん壊れました。バスが3本あるので 8847 も3個あるのですが、1つ
壊れるとバス2本で使うことになって性能が 2/3 になり、結構もったいなかっ
たです。
こういうわけで、 GRAPE-4 では 3種類の基板を開発しました。これらは泰地、
福重と私が適当に分担して設計、発注、デバッグをしています。 94年終わり
頃にはそれぞれが完成し、95年春に9枚のボードで並列動作ができるようにな
りました。理論ピーク性能としては 270 Gflops に達しました。
この、95年春というのがどういう時期であったかというと、 93 年に航技研数
値風洞が完成しています。 これは理論ピーク性能が 280 Gflops です。三好
先生のアイディアで分散メモリベクトル並列機を実現した画期的なマシンでし
た。また、Sandia 研究所の Intel Paragon が同程度のピーク性能を実現して
いました。これは Intel 80860 を使った超並列システムです。そういうわけ
で、理論ピーク性能としては汎用で世界最高速のスーパーコンピューターと肩
を並べるところについに到達したわけです。
そういうところに来たので、少し宣伝をしよう、というわけで、ゴードン・ベ
ル賞というものに応募してみることにしました。これは、元々 DEC のエンジ
ニアであったゴードン・ベルが、並列計算研究を推進するために作った賞で、
基本的には実際に科学技術的に意味がある大規模数値計算で最高速を実現した
グループに賞が与えられます。スーパーコンピューターの性能比較で有名な
LINPACK は、大規模な連立一次方程式を解く速度を競う、というもので実用的
な計算ではないので、それで速度を測ることに意味があるのか?という批判が
つきまとうのですが、ゴードンベル賞は意味がある計算をしています。
まあ、 GRAPE は重力計算しかできないので LINPACK の速度はだしようがない
ので、出せるゴードン・ベル賞のほうに出した、というのが正直なところでは
あります。
応募は、毎年開かれている国際会議 SC|xx への発表申込みの形でやります。
論文〆切がアメリカで西海外時間の何時、というものなので、〆切の日は徹夜
で計算してでた数字を論文にいれて投稿しました。 112 Gflopsだったと思います。
論文としては受理された、という連絡が 7 月にきて、その後最終の論文の時
には4箱 36 枚の全体が動いていたので性能も上がり、実測で 529Gflops とな
りました。 11 月には会議中に賞の発表があり、 ``Winner, Special-Purpose
Machines'' というなんだかよくわからない賞をもらいました。性能の賞は数
値風洞での QCD 計算で、 140Gflops くらいのものでした。
GRAPE-4 は 96 年にも、今度はちゃんと ``Winner, Performance'' と書いた
賞をもらいます。 95 年の計算はブラックホールバイナリがある銀河の進化、
というもので、 96 年は暗黒物質が作る構造のシミュレーションです。特に
96 年の計算結果はその当時に広く信じられていた結果を覆す重要なものでした。
まあ、賞っていうのはどうしても色々な政治的な要因とかもあり、もらうにふ
さわしい人がもらっていない、といったことはいくらでもあるのですが、この
賞は速度という数字がでてしまうので比較的おかしなことが起こりにくい(起
こらない、というわけではないことは後で述べることになります)賞です。
95 年夏には、杉本が主催して球状星団の進化に関する国際会議を東京で開き
ました。ここで、杉本が発見し、私にテーマとして与えた、重力熱力学的振動
が多体系で起きるかどうかを報告しよう、というわけでです。研究会の準備は
2年以上前から始めていたので、研究会の時にまだ結果がでてなかったら一体
どうするつもりだったのか、今考えると恐ろしくなりますが、実際には6月頃
には良い結果がでだして、8月の研究会では確かに振動が起きている、という
発表をすることができました。
話が前後しますが、94年には GRAPE-2A を LSI 化した MD-GRAPE の開発を始
めます。これは泰地が中心となって、産学共同のプロジェクトとして画像技研
と共同で、東京都等から研究費をもらってやったものです。これは画像技研か
ら最初は VME、後に PCIカードとして商品化されました。
94 年になると、 DEC の方針が変わって PCI バスを採用したワークステーショ
ンがでてきます。しょうがないので、 TURBOchannel を止めにして PCI イン
ターフェースカードも開発することにしました。これは 95年に修士に進学し
た川井(現在埼玉工業大学助教授)が修士論文の研究としてやりました。
TURBOchannel 等とは違い、規格が複雑でインターフェースを全部自分で設計
できるようなものではないので、 PCIインターフェース専用の PLX 9080 と
いう LSI を使います。これがバグだらけで川井は苦労したようですが、97年
にはこれも使えるようになりました。この PCI インターフェースの LSI はそ
の後 GRAPE-5、 GRAPE-6 でも使いました。 GRAPE-6 の開発の最初の頃までは
DEC Alpha を使っていましたが、そのうち DEC がなくなってしまったので
x86 の PC に移行します。これは 2001 年の話になります。
この頃、 GRAPE-5 の開発もスタートします。これは、ちょっとよくわからな
い経緯でついた予算で始めたもので、福重が LSI 設計をしました。基本的に
は GRAPE-3 的な精度が低いパイプラインを2本チップに入れる、というもので、
GRAPE-3 に比べて 8 倍の性能を実現しました。これは浜松メトリックスとい
うところから商品化されます。この時は、インターフェースカードは GRAPE-4
のものをそのまま流用することで開発するものを減らしました。ボードは川井
が開発しました。
GRAPE-4 は、商品として売るには大がかり過ぎるものになってしまったのであ
まり広くは販売とかしないことにしました。
さらにこの頃、戎崎は理研に移って、 MD-GRAPE をベースに大規模並列化した
MDM の開発をスタートします。