サーバー並行性は現実，クライアント並行性は未来 – Radium Software

サーバー並行性は現実，クライアント並行性は未来 – Radium Software

クライアントでの平行性も必要なのは、基本的にCPUのクロックはさほど上がらず、Coreアーキテクチャの改善による速度向上は緩慢で、それ故ムーアの法則で増えるトランジスタ数はコア数を増やすことに消費するしかなく、Any Core時代に突入するのは明らかで、そのときに目の前にあるコンピュータのパフォーマンスを改善するにはその方法しかないからです。

現状のマルチコアであれば従来のマルチプロセッサ対応のOSカーネルによるプロセス・スレッド管理の機能でそれなり有効にプロセッサを使えるのだけど、コア数が16とか32とかになってくるとプロセッサの外側のバス、用はメモリバスの帯域がすべてのコアがメモリアクセスするときに必要とする帯域より小さくなることは明らかで、ここがパフォーマンスのボトルネックに今以上になってしまう。したがってAny Coreの時代では遅い外部メモリのアクセスが必要になるキャッシュ破壊を起こさないよう、出来るだけプロセッサ内のキャッシュメモリだけで動作できるよう今のプロセスよりももっと小さい単位で資源管理できる用にし、この今までよりも小さなプロセス間で分散処理が可能になることが望ましい。

従って、Any Core時代にはクライアント向け平行性ライブラリ等というものではなく、それにあった実行管理が出来るOSが必要になってくるはずだ。

追記

メモリはCPUほどすぐに高速にならない。ただし、今のマルチコアはメモリの帯域をあげることで極端なパフォーマンスの低下を防いでいる。

メモリバスボトルネックの要因になるSMPにおけるメモリのロックを回避する一つの方法がNUMAアーキテクチャで、その有効性も実証されてきていると思うが、CPUのCore数が増えてしまうと結局NUMAの１つのCPUブロック内でSMPの時と同じ問題が発生してしまう。ただ、SUNのSparc T2のアーキテクチャを見ると、プロセッサのメモリアクセスアーキテクチャの改善により、ただキャッシュを増やす以上の効果をもたらすことが出来るような気もしている。この辺はハイパフォーマンス側で鍛えられてきたSparcやIBMのPowerの方がIntel/AMDより1日の長があるように思う。