今回のスーパーコンピューターの系譜は、スーパーコンピュータの設計者シーモア・クレイ(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)というシステムである。
ベクトル型スーパーコンピューターというのは要するに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の場合、「ここまでメモリーの性能を上げればレジスターは要らないだろう」という見積もりだったと思われるが、それはベクトル長が長大な場合の話である。
インターリーブが効いてくるのは、連続してアクセスが行なわれた場合で、最初の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で大成功)

この連載の記事
- 第712回 推論をわずか20mWで実行するエッジAIチップ「ERGO」 AIプロセッサーの昨今
- 第711回 Teslaの自動運転に欠かせない車載AI「FSD」 AIプロセッサーの昨今
- 第710回 Rialto BridgeとLancaster Soundが開発中止へ インテル CPUロードマップ
- 第709回 電気自動車のTeslaが手掛ける自動運転用システムDojo AIプロセッサーの昨今
- 第708回 Doomの自動プレイが可能になったNDP200 AIプロセッサーの昨今
- 第707回 Xeon W-3400/W-2400シリーズはワークステーション市場を奪い返せるか? インテル CPUロードマップ
- 第706回 なぜかRISC-Vに傾倒するTenstorrent AIプロセッサーの昨今
- 第705回 メモリーに演算ユニットを内蔵した新興企業のEnCharge AI AIプロセッサーの昨今
- 第704回 自動運転に必要な車載チップを開発するフランスのVSORA AIプロセッサーの昨今
- 第703回 音声にターゲットを絞ったSyntiant AIプロセッサーの昨今
- 第702回 計52製品を発表したSapphire Rapidsの内部構造に新情報 インテル CPUロードマップ
- この連載の一覧へ