2011年11月5日土曜日

ベクトルマシンの限界?

# Togetterもどき

http://twitter.com/#!/Prof_hrk/status/129776790913822720
@jun_makino ベクトルマシンにこだわる事は悪くないのですが、ベクトルマシンの優位性のポイントが広くは理解されていないことは問題だと感じます。「メモリ性能を最大限に高められるアーキテクチャ」という事ではないので。
http://twitter.com/#!/jun_makino/status/129777711643246592
@Prof_hrk 優位性のポイントはなんでしたっけ?
http://twitter.com/#!/Prof_hrk/status/129808216543592449
@jun_makino 昔は、高価だった倍精度演算器を効率良く仕えたこと。今は電力の無駄使い(真の共有メモリとか)により、並列化コンパイラの最適化が易しいこと。でも、真の共有メモリはスケールしないので、所詮最後の抵抗だと思います。
@Prof_hrk そういう意味では、並列化コンパイラの最適化が易しい理由は、演算性能に対して(電力の無駄使いにより)「メモリ性能を最大限に高め」てるからでは?9はそでしたっけという気もしますが、それはそれ。
@jun_makino 私の書いた事に近いですが、「メモリ性能を最大限に高め」でコンパイラに効くのは、メモリアクセスの局所性を低減させることだと思います。勿論バンド幅はあるほうが良いですが、相対的問題と思います。
@jun_makino 「メモリ性能」が問われています。多くのプログラムでは、実はLatencyも大きく効きます。限られたメモリアドレス範囲で高バンド幅なことも重要で、勿論資源をつぎ込んで出来るだけグローバルな共有メモリも重要です。ベクトルマシンは最後のポイントに着目です。
@Prof_hrk 局所性を低減させるというのは、非局所的なメモリアクセスに対してもそこそこの性能を提供する、という意味、という理解で正しいですか?
@jun_makino 正しいです。SX-9でも、1筐体の中では各CPUチップから平等に足が出ています。コンパイラ屋さんからみると、まだ有効なメモリ非局所性の使い方ができてないというべきでしょう。
@Prof_hrk そうですね。原理的には、アプリ側の並列度が十分あって、非局所アクセスに対してバンド幅があればレイテンシはある程度大きくても良いはずですが、まあ上手く作らないと Cyber 205の轍を踏むわけで、最近の某マシンもそうなってますね。
ベクトルマシンを今まで有利たらしめていたのは、圧倒的なメモリバンド幅ではなく、むしろ、メモリアクセスの局所性を低減させていたことにあった。そして、「真の共有メモリはスケールしない」、すなわち、メモリ性能を保ったまま演算器を増やそうとすると、どうしても「距離の遠い」メモリが出てきてメモリの局所性が発生してしまうので、この先、ベクトルマシンの優位性は無くなってしまうだろう。

…という風に理解しました。

裏を返すと、1PF未満の領域ではベクトルマシン的な手法が有利である可能性は残っているということでしょうか。たとえば、現在のGPGPUのGPUの部分に1チップベクトルプロセッサを使った超並列マシンなんてアプローチはありうるんですかね。まあ、GPGPUと比べるとコスト的に見合わないような気もしますが。

あるいは、当面、超並列な方向に行きそうにないPCであれば、ベクトルマシン的な性能強化というのはありうるんでしょうか? でも、それではOfficeは速くならないだろうし、そもそもそれってGPGPUでは? という気もするし。ああ、DRAMをスタックしてメモリ帯域を稼ぐなんて話は広い意味ではそっち系なのかな?

なお、上記のやり取りの元ネタになったのは以下の記事と思われます。

震災を乗り越えた東北大のスパコンが目指す未来

0 件のコメント:

コメントを投稿