2012年8月7日火曜日

GRAPEとMIC


GPUCPUと似た取り組みにGRAPEがある。これは天文計算のために、天文を実際に計算する人が作り、1/rや1/r^3の計算が高速にできるよう作ったaccelaratorである。(計算機は四則演算のうち割り算の計算がもっとも時間がかかる。)彼らはこれで大量に論文を書いた。必要に迫られて使う人が作ったacceleratorが実際に役にたったわけで素晴らしい。

Gaussianのacceleratorを作ろうとした人もいた。しかし、物はできたがclockがあげられず、そうこうしているうちに5年位たってしまい、CPUの速度があがり並列計算が当たり前の世の中になり、速度という唯一の利点がなくなってしまった。GRAPEが成功してこちらが失敗した違いは基本的な開発次期の違いと言っていい。GRAPEはPC98の頃からやっておりbusのハードルが低いときから経験を積めたが、busの速度が上がってしまった時にいきなりやろうとして失敗したわけだ。GPUCPUの場合はもともとbusの専門家が作った物だったからその点は問題なかった。

数年後にintel MICが来るがどうだろうか。CPUと接続しGPUCPUのようにcoprocessorとして動かした場合失敗するだろう。失敗する理由はCPUとMICの転送速度の低さである。しかし、CPUと協調させなくてもMIC同士で協調させて動く場合は成功するかもしれない。思い出されるのはhitachi SR8000である。これはPA-RISCをカスタムしてresigter切り替えとfetchなどでpseudovector機に仕立てたCPUを持っていた。このSR8000上にUNIXが乗っていたがこのUNIX front endは絶望するくらいのろかった。しかし、ここで諦めずに気の遠くなるような時間をかけてコンパイルをし計算をさせるととても高速な計算機に変わった。MICも計算は高速だが、通常処理はのろいという計算機として完成するかもしれない。それにしてもAtom processor位の速度で動くのであれば問題はないだろう。


2012年8月1日水曜日

GPU computingと・・・

GPU computingが流行ったことがあったが、一過性のブームだった。GPU computingではlinpackなど簡単なものは性能が上がるが、実際のprogramでは性能が思ったほど上がらない、ということが分かってしまったからだ。

CPUーGPUとつなげてPCを作り、CPUとGPUとを協調させて計算をやらせようとすると、
どうしてもCPUとGPUとの間の転送速度が律速になってしまう。

CPUとGPUとで倍精度で10倍peak性能が違ったとしても、実際はせいぜい3、4倍にしかならない。3,4倍であるならば、GPUで処理をせずに、CPU内のcoreで並列化をすれば十分だし、その方が汎用的なコードになる。
実際、すでに8core以上のCPUが存在するのでGPUを使わない方がかなり速いことになる。CPUだけでPCを作る場合とCPU+GPU(Tesla)とでPCを作ることを考えるとCPUだけの方が価格的にも消費電力的にも利点が大きい。GPUを使うprogrammingの手間も考慮に入れると更にGPU computingの魅力は減る。


もちろんGPUで速くなる計算も存在する。どんな計算かというと、CPUーGPUの転送が少なく、GPU内部で単純な計算を永遠とできる場合だ。そういうprogramの人はGPUを使えばいい。実際、そういうものがそれがもともとのGPUの計算だった。そういう計算のためにできたarchitectureなのだから、高速で当然なわけだ。
ただ、多くの意味のある計算はそういう単純計算とは大きく異なるというだけである。

将来のGPU computingを否定するわけでは無いが、現状では、GPU computingというのはかなり限られたprogramでしか性能を発揮できないという理由から、計算機センターなどで強力にGPU computingを推進するだけの価値も理由も無い。CPU+GPUの構成にするよりも、同じ予算ならばCPUx2にした方がかなり多くのprogrammingでの実際の性能はかなり上がる。
今GPUを使った大きなPCクラスターをもつ大学の計算機センターは単に金と消費電力の無駄使いをしているだけでしかない。

linpackを性能指針としているおバカな評価基準のせいでこんなことが起きているという感も否めない。GPUという実際にはほとんど使えないdopingによって、計算機性能の順位がいくつか上がる。そのためにGPUを入れる。計算機を専門家としている人がそんなことでいいのだろうか。お金をもらってくるために、悪魔に魂を売っているに等しい。

GPUを使うとlinpackの性能が上がることはGPUが出た当初から分かっていた。長崎大学で単精度GPU付きPCクラスターで世界最速になり2009ゴールド・ベル賞を受賞、というのを記憶している人も多いと思う。あの時点でGPUを使えば単精度のpeak性能で世界最速になるということは皆分かっていた。しかし、それは馬鹿げたことだったので誰もやらなかったが、彼らはやった。そして、ゴールド・ベル賞を受賞した。
ここに、問題点がある。彼らの計算は単精度で十分だったのだろうか。彼らは流体計算を行ったということだが、今もその計算を行っているのであろうか。そして彼らは自分たちが行った流体計算の意味を理解したのだろうか。3800万円の計算機はその後どうなったのであろうか。単なるGPU実証のために3800万円は高いではないだろうか。
いずれにしろ、3800万円でゴールド・ベル賞を受賞したわけで、無意味ではないし、実証したということにとても意味はある。それはπを何桁求めたという計算の価値と似ている。πの計算と同様に、メディアでだいぶ宣伝してもらったので長崎大学とその研究者、そしてCPU computingのネタを与えてくれたため関連メディア、そしてその読者にとっても3800万円以上の価値はあっただろう。



計算機にとってlinpackは性能の一面を表すにすぎない。
テストの専門家という人も世の中にはいる。例えば英語のテストを考えよう。英語の実力を評価するのにどういう問題がいいのかということを研究しているわけだ。その研究の知見が、例えば、TOEICの問題を決める参考になっている。
現実的にはGPU dopingでTOP500の順位をあげても実際に利用する多くのprogramでは性能は向上しない、と金を出す人に説明するか、linpack指針に変わるはるかに現実的な評価基準を策定するのが、計算機を専門にしている研究者がすることだろうと私は思っていた。

その後この懸念はちゃんと払拭された。
アメリカでもGPU dopingをした計算機でTOP500の上位に入ったものもあったがK computer, LLNLのセコイアはGPUのdopingのない普通の計算機になっている。2012/6のTOP500の10位までに入っている計算機で中国のもの以外は全てGPUのない普通の計算機である。だから実際の性能では中国のものはずっと下である。




日本にはオープンスパコン、T2Kという計算機仕様があった。いや、今でもある。これで4core x 4cpuで16 SMPまで可能にしてhybrid計算の実証機を行おうとしたようだ。しかし、T2K以外に売りようがないカスタムチップのせいで市価の4倍という高価になり、結果日本の計算機の総core数をだいぶ低く抑えることになった。
またopteronのmemoryがさほど高速でもなかったため、そもそも高速化にtuningが必要だった。どうせ中身はopteronだったのだからT2Kでなく普通に市場にあるものを購入すればよかったのだ。
T2Kにこだわらなければ、東大などの計算機の総core数は当時4倍あったはずだったのだ。筑波大のT2Kは市価の2倍程度だったと自慢していたが、T2Kにこだわらなければ2倍のcore使えたはずだったのだ。

今はT2Kを終わらせて、FX10に移行しつつある。しかし、FX10のopenmp性能の低さはどうするのだろう。T2Kによるhybrid並列の知見を生かして、K computerはhybrid並列必須ということだがflat mpiより数倍性能が低くなる使い方を強制してどうするのだろうか。

T2KそしてFX10、とても高価で総core数が少ないhybrid並列用計算機と、その次に来た総core数は多いがhybrid並列にすると性能の低下が著しい計算機。K computerは外国で売るために作っていたはずだが、このopenmp性能の低さでは外国で売れないだろう。
日本の計算機屋さんに付きあわされて近年の日本の計算機はちぐはぐなものになったという感が否めない。

・・・ということが現在の懸念事項である。

g++がないと言われifortが起動しなくなった場合の対処法。

$ ifort
ifort: error #10001: g++ が存在するディレクトリーを検索できませんでした。
というメッセージが出る。

remote loginする環境を変えると普通にifortが使えたりもする謎のバグ。


対処法:
# export LANGUAGE=C
# export LC_MESSAGES=C
# export LC_ALL=C