このページの本文へ

前へ 1 2 次へ

ロードマップでわかる!当世プロセッサー事情 第274回

スーパーコンピューターの系譜 ベクトル型の傑作STAR-100

2014年10月13日 12時00分更新

文● 大原雄介(http://www.yusuke-ohara.com/

  • この記事をはてなブックマークに追加
  • 本文印刷

 今回のスーパーコンピューターの系譜は、スーパーコンピュータの設計者シーモア・クレイ(Seymour Cray)が去った後のCDC(Control Data Corporation)の話を紹介したい。

ベクトル型スーパーコンピューターの傑作
STAR-100

 CDC 8600の開発当時、同社はもうひとつSTARプロジェクトというものを手がけていたことは前回少しだけ触れた。最終的にはSTAR-100として登場した製品の指揮を執ったのはジム・ソーントン(Jim Thornton)で、CDC 6600ではシーモア・クレイと共同で開発していた。

STAR-100の模型。画像はComputer History Museumより

 ミネソタ大の写真アーカイブの中に、“Cray, Thornton, and other Shipping the 6600, Chippewa Falls, WI”(関連リンク)なるものがあるあたり、ジム・ソーントンはクレイにかなり近いポジションにいたと思われる。そんなこともあってか、STAR-100のアーキテクチャーには、部分的にCDC-6600を彷彿させるものがある。

 そのSTAR-100は1972年に発表されたが、比較的初期のベクトル型スーパーコンピューターの1つとしても知られている。ちなみにもう1つは、同じく1972年に発表されたTexas InstrumentsのASC(Advanced Scientific Computer)というシステムである。

ASCのシステムルーム。画像はComputer History Museumより

 ベクトル型スーパーコンピューターというのは要するにSIMD(Single Instruction Multiple Data)である。STAR-100は64bitアーキテクチャーであるが、ベクトルそのものは128bit長である。データ型は64bit以外に32bit幅もサポートしている。動作周波数は25MHzで、実行ユニットは3つ(FPU×2とString Unit×1)という構成。浮動小数点演算の理論上の速度は次のようになる(*1)。

32bit加減乗算 100MFLOPS
32bit除算・平方根 50MFLOPS
64bit加減算 50MFLOPS
64bit乗算 25MFLOPS
64bit除算・65bit平方根(*1) 12.5MFLOPS

(*1) なぜか平方根だけが65bitだが、これは元の文献(Paul B. Schneck “Supercomputer Architecture”)に準じている。

 この性能が平均的に出ればすごいことなのだが、実際はそこまで性能が出なかった。最大の理由は、STAR-100がベクトルレジスター(x86で言えばXMM/YMM/ZMMに相当する計算機)を持ち合わせていなかったことだ。

 前回に戻ると、CDC 6600はレジスターを内蔵しており、演算はこのレジスター間で行なわれていた。これにより、メモリーアクセス待ちをせずに演算が可能になったわけだが、STAR-100ではこれを実装するのは難しかったようで、直接メモリからデータを読み込んで演算し、結果を再びメモリーに書き戻す方式となっている。

 もっともこれはベクトル演算命令のフォーマット的に不可避でもあった。STAR-100のベクトル命令は可変長構成で、最大6万5535個の要素からなる2組のデータに対して、まとめて演算が可能だった。これだけ扱うべきベクトルが大きいと、レジスターを用意するのは不可能である。

 それよりは連続してメモリーからの読み込みと書き出しを継続的に行なえるような、パワフルな主記憶を用意した方が良い。

 STAR-100はコアメモリーをベースにしており、サイクルタイムは1.28マイクロ秒(780KHz)動作と遅いが、メモリーそのものは8バンク構成で、その各々が4ウェイのインターリーブ構成になっており、見かけ上のサイクルタイムは32倍速の40ナノ秒、つまりCPUと同じ速度まで引き上げられている。

 このメモリー(最大記憶容量は4MBytesに達した)に対し、ロードユニット×2、ストアーユニット×1が用意される。各々のユニットが別々のバンクにアクセスすることで、アクセスの干渉による速度低下を防ぐ目論見だ。ちなみにメモリー周りの構成などはだいぶ違うが、Texas InstrumentsのASCもやはりベクトルレジスターを持たない構成であった。

STAR-100のメモリースタック(左)と、ロジックモジュール(右)。画像はComputer History Museumより

 STAR-100の場合、「ここまでメモリーの性能を上げればレジスターは要らないだろう」という見積もりだったと思われるが、それはベクトル長が長大な場合の話である。

 インターリーブが効いてくるのは、連続してアクセスが行なわれた場合で、最初の1つ目の読み出しにかかる時間は32サイクル分に相当する1.28マイクロ秒待たないといけない。

 現実問題として、STAR-100は512bit単位でメモリーの読み書きをしている。これは1つのバンクの中が4ウェイ インターリーブで、128bit長であることに起因する)から、64bit浮動小数点なら8、32bit浮動小数点だと16が最小のベクトル長となり、これより短くしてもメモリーアクセス時間は全然減らないことになる。

 加えて、ベクトル処理の性能は高かったが、非ベクトル命令に関してはString Unitが扱うことになり、このユニットの性能が高くなかったから、制御ループなどの管理がぐんと遅くなることになった。

 このため、性能を引き出すのはかなり難しかったとされる。とはいえ、当時行なわれたSTAR-100に関するベンチマークのレポートのいくつかが現在も入手できるが、最適化するとそれなりに高速だったようだ。

 たとえばNASAとNY大による遷音速流計算の比較(PDF)では、同じCDCのCyber-175(CDC 7600の派生型)と比較して以下の数字が示されており、サイクル数こそ多いものの所要時間はほぼ半分とされる。

グリッドサイズ Cyber-175 STAR-100
40×40 42サイクル/1.242秒 131サイクル/0.879秒
80×80 98サイクル/12.118秒 300サイクル/6.385秒
160×160 244サイクル/116.095秒 655サイクル/59.834秒

 あるいはGTE Information SystemsとNASAのゴダード宇宙科学研究所による、天候モデルの計算結果(PDF)では、IBMのSystem 360/95と比較して、5~10倍の速度が出ていると示されている。その意味では、CDC 8600のように完成しなかったわけではない。

→次のページヘ続く (スパコンが低迷するもHDDで大成功

前へ 1 2 次へ

カテゴリートップへ

この連載の記事

注目ニュース

ASCII倶楽部

プレミアムPC試用レポート

ピックアップ

ASCII.jp RSS2.0 配信中

ASCII.jpメール デジタルMac/iPodマガジン