次世代スパコンは結局当初計画程度の予算(報道されている40億減は概算要求
からで、概算要求が元々当初計画から上載せされてたので)となって、仕分け
の騒ぎがあまり意味がある結果につながっていないような気がします。事実上
最後の計画見直しの機会をまた無為に見送った、という感じですね。
この間にアメリカでは色々面白いことになっています。一つは、 Intel がずーっ
と前から宣伝していた Larrabee が事実上の凍結、ではありませんがとにかく
去年くらいからの予定であった2010 年度にグラフィックスチップとして出荷、
という予定がキャンセルになった、ということです。まあ、その、普通にイン
テルのグラフィックス関係製品をみていれば、突然素晴らしい製品を出すなん
てことが起こるはずがないわけで Larrabee でグラフィックスを、というのは
初めから無理に決まってると思うのが自然ですが、昔だと IBM がなんかいうと
それはみんな本当と思い込む人がいた、というか、いまだに一杯いますが、の
と同じで、インテルが「我々はこういう計画である」というとそれが本当だと
思い込む人というのは世の中に一杯いて、そういう人には驚きであったのかも
しれません。
Larrabee の実チップがどういうものかの詳細は公式の発表はいまだないと思い
ますが、 SC09 では SGEMM で 1Tflops を超える数字を出した、ということで、
これが 2-3GHz 程度の動作クロックで実現したとすればクロック当りの演算数
は 512, 16 コアで 16 add + 16 mul ということになります add+mul で一組と
すると256演算器です。この、512 という演算器数はGPU に対抗するにはいかに
も少ないもので、 GT200b あたり相当、 AMD Cypress の 1600 x 2 に比べると、、、
というところです。まあ、動作クロックがかなり違うわけですが、演算性能あ
たりの消費電力は動作クロックが低いほうが必ず有利なわけで、 Larrabee も
消費電力あたりの性能はそれほど良くはなかったものと思われます。
GPU としては使えなくても HPC 用にはよいのでは、という期待もあるわけです
が、インテルのアナウンスでは結局 HPC 用としても現在実チップがあるものは
製品としては出荷しない、ということのようで、まあ、よほど色々な問題があ
るのでしょう。
NVIDIA GF100 (Fermi) ですが、こちらは 2009 年の春からずーっと「半年
後に出荷」の状態が続いています。Larrabee がなくなっても会社としては
全く困ることはない Intel とは違って、GF100 がグラフィックスチップとし
て出荷できないようなことがもしもあれば NVIDIA の存続の危機ですから、
キャンセルというわけにはいきません。とはいえ、これほど遅れ続けて
おり、しかも現在のところ出荷がアナウンスされているのは HPC 用の
Tesla C20x0 だけで、GPU としての出荷については現在のところ時期すら
明らかでないようです。
この Intel Larrabee、NVIDIA Fermi の話で共通しているところは、
グラフィックスチップとしての位置付けが大きく後退ないし遅延した、
ということで、単純なアーキテクチャで並列度向上を実現した AMD Cypress
に比べてはるかに複雑なキャッシュコヒーレントな SMP 的な構成に
なった Larrabee と Fermi のどちらも、ハードウェアかソフトウェア、
おそらくはその両方に深刻な問題を抱えた、ということと想像されます。
まあ、その、 16 コアくらいから物理共有メモリは無理がくる、というのは
Cray C-90 やその頃に開発されていたものすごく沢山の共有メモリ型並列計算
機でみんな起こったことで、その時に起こった問題点をどう解決なり回避する
か、というビジョンがあまり見えていない Larrabee や Fermi が同じような問
題に苦労するのは当然のような気もします。
C-90 は少し問題が違いますが、多コアの SMP で問題になるのはキャッシュコ
ヒーレンシを維持するためのコア間のトラフィックです。ディレクトリ方式を
使わない限り、リングバスでコヒーレンシプロトコルを実現するとトラフィッ
クはコア数に比例するので、結局リングバスのバンド幅がコア数に比例して増
えないといけない、というような話になって結局資源がコア数の2乗で増えるこ
とになり、16コアあたりで破綻がくるわけです。ディレクトリ方式にすればこ
んなふうにならない、とはいえ、今度はコア毎に巨大なディレクトリ用の
メモリとそれを操作するための複雑なハードウェアが必要になり、オンチップ
マルチプロセッサでそんなのをやるのか？という話になります。
私は計算機科学の専門家ではないので、共有メモリ並列プロセッサでキャッシュ
コヒーレンシが必要な理由がそもそも良くわかっていません。プログラムの並
列実行、ということを考えると、まず複数プロセスの場合にはそもそもメモリ
空間が違うわけで、物理アドレス空間が共通とはいえ実際にはページ単位で
メモリは切り離しされているわけで、2つのプロセッサコアで走っている別の
プロセスは同じ物理アドレスをアクセスしないわけですから、キャッシュコヒー
レンシなんてものは少なくともアプリケーションレベルでは意味がありません。
もっとも、 OS との関係とかは面倒ですが、まあ、 OS になるとどうせ
デバイスからのアクセスとかもあり、キャッシュが透過的に使えると
いうものではないので本質的な問題ではないような気がします。
ではマルチスレッドプログラムのような、本当に複数の CPU で同じ仮想アドレ
ス空間を使い、物理アドレスとしても同じところにアクセスする可能性がある
時はどうでしょうか？計算機科学の側で研究されていることは、キャッシュ間
でデータが共有される、特に、同じキャッシュラインの別のデータを別のプロ
セッサがアクセスするので、論理的には依存関係がないんだけどハードウェア
としては変な依存関係がでてくる、いわゆる false sharing をどうやって解決
するか、というのが大問題になります。汎用プロセッサとしては、マルチプロ
セッサがマルチプロセスで走って、それぞれがマルチスレッド、といったこと
を考えないといけないので一層厄介です。
しかし、HPC 用並列プロセッサでは、シングルタスクで使うのが当然で、割り
込みが入るとすれば OS の、通信とか I/O のためのものだけでアプリケーショ
ンがはいってくるようではそもそも使いものになりません。なので、キャッシュ
制御で汎用プロセッサでは考えないといけない面倒なことの大半はそもそも考
える必要がありません。また、結局マルチコアでのマルチスレッドで性能を出
すためにはキャッシュのデータ共有があってはいけないわけで、その観点から
は本来はキャッシュコヒーレンシの制御をハードウェアでするのはそもそも止
めにして、アプリケーションが(というか並列化コンパイラが)面倒みるように
すればハードウェアは非常に簡単になります。また、 HPC でチューニングする、
という観点からは、キャッシュはハードウェアの動作を予測困難にし、メイン
メモリのバンド幅を無駄に捨てる邪魔物でしかなく、アドレッサブルでオンチッ
プの高速メモリがあるほうがよほど役に立ちます。こういう構成は CDC 7600
や Cray-2 でとっていたものです。特に Cray-2 の場合にはローカルメモリが小
さすぎたことと、メインメモリと直結でなくてスカラレジスタ経由という明ら
かに何か間違えている構成のためにあまり有効ではなかったようですが、アプ
リケーションを書く、特にチューニングする側としてはキャッシュがあって嬉
しいことは殆どなく、 L1 や L3 もたいがい邪魔なので L2 相当のある程度容
量があるメモリを、レイテンシは多少あってもよいので本数のあるレジスタファ
イルと高いバンド幅でつないでくれればよいわけです。まあ、オンチップメモ
リの範囲で古典的ベクトルプロセッサ(といっても、主記憶レイテンシがそんな
に大きいわけではないのでベクトル長が 64 とかは不要と思いますが)で、主記
憶とは明示的に転送制御して、というものですね。
この構成の場合、ネットワークインターフェースも主記憶にいくのではなくて
オンチップメモリにいれる、ということが可能になり、通信のレイテンシを非
常に大きく下げることができます。現在すでに通信のレイテンシのほとんどが
PCIe のインターフェースチップや主記憶自体のレイテンシになっていて、こ
れはネットワークを改良しても下がらなくなっています。
まあ、これは要するにほとんど Cell ですね。Cell の駄目なところは
Cray-2 と同じで、ローカルメモリと主記憶の間の転送方法に制限がありすぎ
たためにアプリケーション開発が困難だった、というのが最も大きいと思いま
す。その他に浮動小数点の演算方式がおかしいとか細かいものもありましたし、
チップ間通信には適切な方法がなかったというような問題もありました。
まあ、その、こういうのは計算機科学の誰かが作ってくれることはないし F も
やらないので、こっちで作るしかない、というのが問題なわけですね。