Previous ToC Next

38. 最適な設計とは? (2006/12/7)

もう一度、大雑把な話として、計算機の性能は

で決まる、という話に戻ってみます。明らかに、これらのそれぞれに対する要 求の程度はアプリケーションによって違います。違わなければ計算機はそれに 合わせた1種類でよくて、こんな話を考える必要もありません。そうすると、 結局、色々なアプリケーションでまんべんなく性能がでるようにするためには、 これらに同じくらいづつ資源を配分するのが最適な設計になります。つまり、 極めて大雑把にいって資源の 1/3 を演算器、 1/3 をメモリバンド幅、 1/3 をネットワークバンド幅につかうわけです。レイテンシは資源を使って減らせ るものではあまりなくて、むしろ余計な資源を使わない単純な設計にすること のほうが大事です。

こういう観点からすると、現在の普通の計算機は PC クラスタにしてもベクト ル計算機にしても全く論外です。例えば資源を CPU 上のトランジスタにかぎっ たとしても、その中で演算器に使われている部分は限りなく 0 に近いからで す。倍精度浮動小数点演算器1セットは 10万トランジスタもあればできますが、 最新のマイクロプロセッサは数億トランジスタを使って2-4 セットの演算器し かもっていません。 GRAPE-DR では 512 セットの演算器を数億のトランジス タで実現していて、20% くらいが演算器です。

まあ、GRAPE-DR でも 20% で、これはメモリバンド幅とかネットワークを限り なく無視した計算機ですから、もうちょっとまともな計算機を作った時に CPU 面積の数%以上を演算器にするのは困難である、というのが現実かもしれ ません。しかし例えば GRAPE-DR の 20% が上限だとしても、それの 1/3 より ずっと少ない演算器しかもたないようなプロセッサがあったとすると、 演算器を増やすことで性能をあげられるようなアプリケーションがかなり色々 あるはずです。

つまり、例えば 90nm でチップ内の演算器が 100個以下の設計は、上の意味で は最適から遠い、ということになります。1/3 だと170個ですが、まあもうちょっ とということで 100 にしてみました。 65nm だと 200 個、 45nm だと 400個 です。 Intel の 4 コアのチップは 65nm で 8 個なので、大体最適値の1/25 という辺りです。 NEC SX-8R も同様です。富士通の SPARC64-VI は90nm で 4 個なのでこれも同様です。IBM Power6 は 65nm で 4 個しかなく、1/50 まで 落ちます。もっとも、これらは 2-4 GHz と高いクロックで動作しており、そ のために浮動小数点演算器もパイプライン段数が増えているので、演算器に必 要なトランジスタの数はいくらか増えています。しかし、それは「いくらか」 であり、 25倍とか 50倍という数字がたいして変わるわけではありません。

さて、上の話は、資源を CPU チップの中のトランジスタ数だけで評価した場 合の話です。実際に計算機を作ると、例えば基板とか箱とか電源とか、ネット ワークの配線とか建物とかにもコストがかかるので、演算器、ネットワーク、 メモリといったものが全体としてどれくらいコストに影響しているか、という ことを考えて物事を決める必要があります。そうするとどうなるか、というと 傾向を予測するのは簡単で、メモリは CPU 以外にそもそも DRAM チップを別 につけるとか、基板上の配線とかパッケージのピンとかでコストがかかってい ますし、ネットワークはケーブルとか基板とかでまたコストがかかります。こ れに対して演算器は結局チップの中だけなので、全体からみたコストの割合は、 電源とか箱とかを考慮しても CPU チップ内のトランジスタの割合よりも低く なります。つまり、上の数字よりもうちょっと頑張って演算器を増やしたほう が得になる、ということです。

ここまでの話は、アーキテクチャとか命令セットとかを一切考えずにしてきま した。これは要するに私が計算機アーキテクチャの専門家ではないからです。 「これからが面白いプロセッサアーキテクチャ」という研究会での 五島正裕氏のプレゼンテーションとかを見ると、計算機アーキテクチャ というのはなかなか大変な分野だというのがわかります。

少し本題から外れますが、このプレゼンテーションは興味深いもので、スライ ド 19 では計算機科学の専門家が並列言語とか並列化コ ンパイラとかを作ったけれど誰も使ってくれなかった、と書いてある のですが、スライド 21 を見るとその理由がまったく理解されていない、 ということがわかります。並列化言語とか並列化コンパイラを誰も使わなかっ たとすればそれはそれらが使いなれた言語ではない上に遅くて話にならなかっ たからで、そのために実際に並列計算機を使う人は、ベクトル並列機のような 素晴らしいコンパイラとハードウェアの組み合わせが用意されていた環境以外 では MPI のような低レベルだけれど性能は出る環境を使わざるを得なかった わけです。

並列計算機で良いプログラムというのは速いプログラムのことですから、 性能がでないような並列化コンパイラとか並列言語というのはまるで存在意味 はありません。

と、本題に戻って、アーキテクチャとか命令セットはどうするの?というわけ です。そういうのは、餠は餠屋で専門家におまかせするべきなわけですが、で はチップ上のトランジスタの 20% が演算器であるような計算機で、ちゃんと 実用アプリケーションで性能がでるようなものを設計してくれ、といわゆる計 算機アーキテクチャの専門家にお願いしたら作ってくれるか、というとそうい うことはないわけで、そんなことを考えるの自体が素人のあさはかさであると 教えてくれるのがせいぜいです。もちろん、上の同じ研究会の発表の中には メ ディア処理で128コアを使い倒そうというものもあり、ちゃんとそう いう方向を考えている専門家もいるわけです。

もちろん、画像処理は Illiac-III の頃から SIMD 並列計算機向きの仕事だっ たわけで、現代でもそれが有用なのは当然という面はあります。大体 1980年 代中頃までの計算機は、主記憶まで含めても1チップに入るようになってきて いますから、データ規模が小さい画像処理は、 I/O 速度に比べて演算が十分 複雑なら SIMD 方式のメリットがあります。また、十分な数の演算器をもたせ ることで低クロック、低消費電力化できれば組み込みシステムではさらにメリッ トが大きいわけです。また、プログラム可能とはいえかなり特定処理に近いも ので、画像データの供給のされかたも決まっているからこういうのができる、 とはいえます。

しかし、それなら科学技術計算でも、全く何に使われるかわからないものを作 るのでなければその辺どうするかを考えて作ればいいわけです。
Previous ToC Next