32bit/64bit OSの性能比較とスパコンの性能比較の関係
最近Windows 7とやらが発売され、結構な人が64bit版を導入しているようです。僕は諸事情で32bitですけど。64bitと32bitの違いというと、たくさんのメモリが使えるかどうか、だと思ってる人もいると思います。それはそれで正しいのですが、計算性能でも違います。
ところで最近スパコンの性能というのが話題ですね。例えばGordon Bell C/P 賞を取った長崎大学の結果と比較して、京速計算機がうんぬんという比較です。で、この話題と32bit/64bit OSの性能差というのは密接に関係してるんですよ、というのがこの記事の話です。
まず問題を計算する際には、プログラムを実行するわけですが、プログラム中の命令は大きく2つに分かれます。計算命令とI/O命令です。計算命令というのは、CPUの中で加減乗除などを行うだけの命令で、I/O命令というのはCPUの外部と通信する命令です。I/O命令の例としては、メモリアクセスやネットワークアクセス、GPUへの計算渡し、などが含まれます。プログラム中の命令の中には、計算命令とI/O命令の二つを同時に実行するものもありますが、CPUは実際にはどちらか一方を行っている状態と考えてかまいません(パイプラインとか難しいことを言わないように！)。ここで、計算命令のほうがI/O命令よりも時間がかかっている状況をCPU bound、I/O命令のほうが時間がかかっている状況をI/O boundと呼びます。
さて、32bit/64bit OSの話に戻します。このOSによる違いは何か、というと32bit OSよりも64bit OSの方がI/O boundの問題が速くなる、ということです。具体的なベンチマークは、こんな感じです。例えばData FittingやPiの計算、行列転置などはメモリアクセスがほとんどである、典型的なI/O boundな問題です。一方、このベンチマーク中で若干遅くなっているような、行列積や数値積分問題というのはメモリアクセスが相対的に少ないCPU boundとして知られている問題です。ちなみに一般の数値積分問題では微分方程式の初期値問題などのI/O boundなものもありますが、ここでやられているのはおそらくのような問題だと考えられます。
次にスパコンの話題として、長崎大学のGPUをつないだ話をしますと、N体問題というのを解いているようです。一般のN体問題は、上でCPU boundといった行列積問題とほぼ同じであり、やはりCPU boundです。そしてこういったCPU boundな問題に対しては、GPUが効果的に使えることが知られており、こういう話題をある程度知っている人達は比較的性能に意外な点は無いと捉えているように思われます。ただし、今回の場合はちょっと特殊なとき方をしているので、別エントリで補足します。
その一方で、I/O boundな問題が速くなければ一般の問題というのはほとんど速くならないため、京速計算機にはその点が期待されています。この京速計算機に乗るCPUはSPARC64という、その名のとおり64bit CPUでして、OSも当然のように64bitが使われます・・・多分。で、ただそれでもまだまだI/O boundが解決されない、というのが問題であって、そういう問題はPC clusterなどではとても解決できないのです。
ということで、32bit OSが問題としている点と、PC Clusterや長崎大学のスパコンが問題としている点は実はほとんど同じなんですね。解決案は64bit OSだったり京速計算機だったりと違いますが。
長崎大学のGPUスパコンのアルゴリズム
エントリを変えて、長崎大学のGPUスパコンで使われたアルゴリズムについてみてみたい。資料はhttp://www.ssken.gr.jp/MAINSITE/activity/sectionmeeting/sci/2009-2/lecture-1/ppt.pdfにある。
このアルゴリズムは、一般的にはTree法とかFMMと言われている物で、詳しくはhttp://www.artcompsci.org/~makino/papers/doboku/doboku.htmlあたりを参照するといいと思う。重要なのは、大体FFTなんかと同じような計算量だという点だ。上の記事にあるMathmaticaのベンチマークの中に、FFTの結果もある。Discrete Fourier Transformと書かれているのがそれだ。これが64bitで高速になっていることからもわかるように、実はこの問題はかなりI/O boundな問題なのだ。Tree法やFMMについても同様の性質があり、やはりI/O boundと考えてよいと思う。
先に書いたように、一般のN体問題であればCPU boundなのでGPUで高速化が容易だったというのは比較的当然だったのだが、今回はI/O boundな問題をGPUで高速化できたという点が非常に興味深い。
