BG/L の場合の性能が低いのは、embedded DRAM のバンド幅がそもそも足りな い、ということによっている、と論文には書いてありますが、演算性能に対す る DRAM バンド幅は QCDOC の 1/2 はあるのに性能が 1/3 になっているのは ちょっと計算があいません。この辺は計算法とかメッシュサイズとか細かいと ころによります。が、まあ、 BG/L のほうが効率が 1/2 以下になるのは確か なところでしょう。

問題は、QCDOC にしても BG/L にしても、次はどうするか、です。まあ、 BG/L の場合はあまり問題ではなくて、 90nm, 65nm と使えるトランジスタの 数が倍になる度にコアの数を倍にして、 DRAM もそれなりに増やす、というこ とでいいわけです。もちろん、ネットワークをどうするかは問題です。 1.4Gbits/s 6方向で総計 20Gbits/s 近いバンド幅をもたしているわけで、こ れを演算性能に比例してあげていくのはそんなに簡単ではありません。

もっと問題なのは QCDOC のほうです。問題が大きくなる理由は簡単で、次世 代機は最低でも 5年ほど先のことになるからです。 現実的にはもう少し先で しょう。すると、プロセスルールとしては 32nm 程度を想定することになり、 トランジスタ数は QCDOC の32倍になります。

QCDOC と同じように4次元とか5次元のトーラスを構成することを考えると、 32 コアの場合に QCDOC の16倍の本数の線がいります。仮にコアが 2GHz 動作 とすると、 2 Gbits/s の線を入力、出力とも 200本程度出す、という感じで す。QCDOC の場合、ネットワークのバンド幅は要するに QCD 計算ができるく らいに設定されているので、設計案としては演算速度に比例してバンド幅も増 やしておく必要があります。もちろん、 32 コアも入れるのでチップにはいる メッシュサイズも少しは大きくなるのですが、メッシュ数が16倍になっても1 次元方向のメッシュ数は半分(4次元メッシュなので)となって、演算速度当り のバンド幅は半分になるだけです。上の 16倍というのはそれを見込んだもの です。

2Gbits/s の線を 200本というのは、かなり大変ですがコスト的にできないこ とではありません。大雑把にいって今の Cray XT3 の半分くらいだからです。 チップ間接続の実装をどうするかはもちろん問題ですが、まあ、5年後に難し いかというとそんなこともないでしょう。

では、それで OK でそういうものを作ればそれでいいか？というのは実は問題 です。チップ設計コスト、量産コスト、基板コスト、基板間接続のコスト、と いったものを考えた時に、 QCD 計算だけを考えてこれはベストな案か？とい うことです。 QCDOC では演算器はチップ当り1セットで、メモリは 4MBでした。 演算器の数を増やす時に、メモリ量も増やす必要があるのか？というのがひと つの問題です。QCDOC や BG/L では、演算器自体はチップ上の大した面積をとっ ていません。まず、だから BG/L ではプロセスルールが1世代しか変わってな いのに演算器の数を4倍にできたわけです。仮に、 CPU コアは1つで後は SIMD 動作、というものなら、 BG/L の 130nm 技術でも 128個くらいの演算器はい れられます。 QCD 計算だけを考えるならメモリを大きく増やす必要はありま せん。まあ、128はいいすぎとしても 64 個くらいはなんとかなるでしょう。 これを 32nm までもっていくと 1024 個の演算器、となります。メモリは オンチップで 128MB くらいはあるわけで、 QCD 計算に対して不足、というこ とはないでしょう。

問題は、この場合チップ間通信の線がさらに30倍程度必要、つまり、入力、出 力それぞれ 6000本ほど必要になることです。これは全然無理なので、何か考 える必要があります。

何かというのは一体何か？というのが問題です。上の大雑把な計算は、要する に現在のマシンバランスを保って QCD 計算に使える計算機を作ろうとすると、 チップ上で計算に使える面積はほんのわずかになる、ということを意味してい ます。実は現在の BG/L や QCDOC でもわずかなので、 QCD 計算というものは そういうものであるということでそのままやっていく、というのは一つの方針 でしょう。

もうひとつの方法は、相対的に通信が減るアルゴリズムを考えることです。要 するに CG 法なので、理屈では構造解析で使っているような領域分割法とか CGCG 法、マルチグリッド(これは計算は速くなっても通信はもっと増えるかも、、、) といった方法の適用が考えられるわけで、これらによって通信速度が遅くても 効率がでるようにしたい。これは、例えば Luescher のアルゴリズム等が提案 されていて、 PACS-CS ではそもそもそういうのでないと性能がでないバラン スになっているようです。

そもそもモンテカルロなんだから、沢山の格子を使って独立に計算することに して通信を減らす、ということだって原理的には可能に思えるのですが、これ はメモリが余計にいるということを考えると少し難しいかもしれません。DRAM とかを外付にして扱える格子を大きくしようとするとまた転送速度が問題にな るからです。

QCD 専用計算機についてまとめると、 QCDOC (apeNEXT もほぼ同様)で既に、 演算器がチップ面積に占める割合がほんのわずかであるにもかかわらず、性能 がメモリバンド幅やネットワークバンド幅でリミットされる、という状況になっ ています。プロセス技術が進めばこの傾向は一層進んで、どんどん演算器に使 える半導体の割合は小さくなり、高い性能を出すことが困難になります。

それでも、計算法が現在の普通の CG法である限り、ネットワークをちゃんと 作れば PC クラスタより性能がでるので PC クラスタに負けることはないし、 ネットワークは近接結合ですむのでもっと汎用なネットワークがついたベクト ル並列機にも負けることはありません。従って、予算がとれる限りはトランジ スタ利用効率が極度に悪くなってきていても、他と比較した結果は良いもので あるでしょう。

しかし、アルゴリズムを工夫してやれば同じシリコンで10倍とか、2010年なら 100倍近くまで性能をあげられる可能性もあります。これは、工夫したア ルゴリズムで PC クラスタでやったほうが現在のアルゴリズム用に専用計算機 を作るより良くなってしまう可能性もある、ということです。QCD 専用計算機 が成り立つものかどうかは、 QCDOC の時点で難しい問題になった、というこ とでしょう。

Previous

ToC

Next