前列左から、大野洋介氏、泰地真弘人氏、 |
理化学研究所 生命システム研究センター
生命モデリングコア計算分子設計研究グループ
グループディレクター 泰地 真弘人
理化学研究所 次世代計算科学研究開発プログラム
次世代生命体統合シミュレーション研究推進グループ
生命体基盤ソフトウェア開発・高度化チーム
上級研究員 大野 洋介
理化学研究所 HPCI計算生命科学推進プログラム
高度化推進グループ 高度化推進チーム
上級研究員 小山 洋
理化学研究所 次世代計算科学研究開発プログラム
次世代生命体統合シミュレーション研究推進グループ
生命体基盤ソフトウェア開発・高度化チーム
研究員 舛本 現
理化学研究所 次世代計算科学研究開発プログラム
次世代生命体統合シミュレーション研究推進グループ
生命体基盤ソフトウェア開発・高度化チーム
リサーチアソシエイト 長谷川 亜樹
泰地 ハードウエア的には、最初から非常に安定していたという印象があります。急に止まったといった話もほとんど聞きませんでしたし、最初からわりと大きな規模で流れましたからね。はじめのうちは、いろいろ落ちたりして苦労するだろうと覚悟していたのですが、私たちが触れるようになった昨年の春には、とても安定していました。
大野 確かに、ハードウエアのトラブルがほとんどなかったのは意外といえば意外でしたね。いろいろと問題が出たのは、基本的にソフトウエア関係の方でした。特にコンパイラは開発途中ということもあって、CやC++はFortranに比べるとちょっと遅れていて、プログラムとして問題ないはずなのにコンパイルに失敗したり、結果が間違ったり、そういうことがありました。まあ、ソフトウエアまわりについては、早く使わせてもらう代わりに、そうしたバグ出しにも協力するということで……(笑)
大野 最初のうちは、性能面でもFortranの方が速いという状況がありましたし、開発途中のコンパイラでも最適化してくれるような書き方をするということもやりました。ただ、最近は他のコンパイラも含めてだいぶ改善されてきています。
小山 僕自身がFortranユーザーだからいうわけではありませんし、別にメーカーをよいしょするつもりもありませんが、コンパイラのFortranの自動並列に関しては、かなりよくできています。ユーザーは限定されるかもしれませんが、今までずっとFortranやってきた人は使いやすいだろうと思います。ただ、一方でメモリバンド幅の問題があります。地球シミュレータなどのベクトルマシンを使ってきたFortranユーザーの人たちの移植は楽かと思ったのですが、メモリバンド幅的に性能が出るか、出ないか、そこは完全に分かれてしまいます。出ない場合は、根本的にアルゴリズムを変えない限り、絶対に性能は出ないので、それはもうどうしようもないというところが、結構つらくもあり、チャレンジングでもあり……。
小山 ただ、そこで暗明が分かれて、助かった人とそうでない人が出るというのは、厳しいですね。
大野 確かに、Fortranでループ文がきれいに書いてあると、自動並列で結構いい性能が出ます。
小山 もちろん開発努力を続けてこられた結果ではありますが、ある意味では、非常に幸運でもあった(笑)。しかし、「CやC++でプログラミングしたものも、ちゃんと最適化してほしい」というのが、多くの「京」ユーザーのニーズなので、そこはメーカーにも考えてもらわないといけませんね。
舛本 流体などをやってきた人たちは、もちろんベクトル型スーパーコンピュータの経験があると思いますが、バイオ分野ではスーパーコンピュータを使ってこなかった研究者も多いので、普通にCとかC++を使っているということを想定して、もう少し準備をしてほしかったという気はしますね。
小山 とはいえ、これはあくまで現状の話でして、本格運用のころには大きく状況が変わっていると思います。
大野 言語仕様的に高機能になっているとコンパイラをつくるのは大変なので、後まわしになっている可能性もありますね。最初からできるだけ性能を出さなければいけないというプレッシャーもあったでしょうし。
舛本 まずは、やりやすいFortranから、というのは考えられる話ですね。
泰地 「京」には、超並列計算を効率的に実行するため、VISIMPACTと呼ばれる並列計算モデルが導入されていて、コア間の同期を高速にとる機能が付いています。それを使うと、ベクトル的な並列化がわりと簡単にできます。そのため、普通、コア間の並列をするときは上の方で並列化しますが、「京」の場合は下の方で並列化していて、そのループを分解するような形で並列化するのが得意という特徴があります。恐らく、そこで自動並列化できるかで、自動並列化がうまくいくかどうかが決まると思います。
小山 できるだけループ構造にして、たくさんデータを流すようなやり方をしていた人は、比較的スピードが出ています。メモリバンド幅の問題もありますが、最適化という意味では、ベクトルでやってきた人たちは、自動並列化が結構簡単に適用されそうな感じもします。
舛本 僕が担当したアプリケーションは、どれもCとC++だったので、最初のうちはコンパイルに苦労しました。あるアプリケーションは、すぐに性能を出さなければいけなかったこともあって、大野さんにも協力してもらい、できるだけのことをやり、最近すごくよくなってきています。ただ、別のアプリケーションでは、コンパイラが成熟するのを待つか、今のコンパイラに合わせて書き直すか、ちょっと考えています。時間が許すのであれば、トリッキーなことをしないで、コンパイラが整備されるのを待った方がいいんじゃないかと……。
舛本 C++限定の悩みですけどね。Cはまだいい方だと思います。だから、小山さんの話を聞いて、Fortranはそんなにいいんだと思って……(笑)。
小山 確かにさくっと通ったし、Fortranはすごくよかったという印象はあります(笑)
長谷川 私の担当しているデータ解析のアプリケーションは、移植自体はそれほど大変ではなくて、わりとすんなりいきました。ただ、まだハイブリッド並列などで性能を出していく余地はいろいろあると思うので、今後はそこに向けて取り組んでいこうと思っています。あとは、大量のI/Oとかがあるのですが、そこはシステム自体がまだ本番になっていないので、ちょっとペンディングといいますか、チューニング自体はもっと後になってしまうかもしれません。
舛本 他のアプリケーションと比べると、I/Oがネックになりそうな印象があります。
長谷川 それほど苦労していないというと語弊がありますが(笑)、もちろん苦労はしていますが、今できることが限られているという感じですね。もう少しI/Oが整備されたら、いろいろと考えることはあると思いますが。
小山 例えば流体の計算では、ダミーデータでも計算結果はあまり変わらないというか予測できるので、I/Oを後回しにできるのですが、バイオ分野ではデータありきといいますか、ヒット率が影響するようなベンチマークを取らないと意味がない場合があります。ダミーだと全然ヒットせずに空まわりで終わってしまい、それなりに本格的なデータを使ってチューニングしないと意味がなかったりするため、早い段階でI/Oが必要になるケースがあるのです。そのあたりは、苦労していることのひとつです。
大野 cppmdのMD計算では、データ量に対して演算が比較的多く、あまりメモリネックにならない計算でしたから、実はキャッシュが足りないということがあまりなくて、セクタキャッシュ機能を使わなくても十分に性能が出てしまいました。今扱っているライフサイエンス分野のアプリケーションでも、セクタキャッシュを使うところまでいっているものは、まだないですね。ネットワークについても、MDの場合は比較的通信の比率は少ないので、ギリギリまでチューニングしなくても、結構いい性能が出ています。どちらも、まだフルには使っていないので、本当の性能が試されるのは、まだ先になるのではないでしょうか。
泰地 「使ってみなければ分からない」という考え方は今も変わりませんが、いちばん意外だったのは、最初にお話したとおり、ハードウエアのトラブルが少なくて、結構安定しているということでした(笑)
泰地 そうですね。悪い方では、先ほどから話に出ているように、コンパイラがFortran優先になっていることで、まだ開発途中とはいえ、そろそろC++もちゃんと動くようになってほしいですね。
小山 いちばんの難しさは、開発途中でまだ未実装であったり、バグを回避するために、どの程度アプリケーションに手を加えるべきかというところですね。例えば、今、大がかりに手を入れて性能を上げなくても、バージョンアップされたら高い性能が出るかもしれないわけです。そこをどうするか……。
舛本 今までにもずいぶんありましたよね(笑)。ただ、そういう努力は、アプリケーションにとっては無駄かもしれませんが、われわれにとってはスキルアップにつながりますし、「京」の特性を理解する上で、全く無駄ということでもありませんが。
小山 確かに、経験を積む意味でも大事なことですが、個々のアプリを開発し、研究成果を出そうという人たちに、そこまで手間をかけていいのかを考えると、悩ましい気もします。
舛本 それでも、最初につくられたコードそのままで素晴らしい成果が出るということは、絶対にあり得ませんからね。いろいろと試すことは必要だと思います。もちろん、元に戻すところもたくさんあるでしょうけど(笑)
舛本 以前は、「コンパイルがうまく通りません」という問い合わせがずいぶんありましたね(笑)
小山 クロスコンパイルで手間取るケースがいくつかありました。
大野 「京」は、フロントエンドと計算ノードとが違うCPUのマシンになっているため、異なる環境で動かなくなってしまうケースがあるわけです。今は全部通りましたが、最初は苦労したものもありました。
小山 「京」がまだ開発中ということで、いろいろと機能制限もあるので、そこに引っ掛かってうまくいかないといった問い合わせもあります。もちろん、バグの場合も(笑)
舛本 まだまだ初心者の人たちが常にいる状態ですから、初歩的な質問も多いですね。でも、マニュアルはよくできていると思います。思ったよりも最初からちゃんとしています。
大野 むしろ、マシンの方がマニュアルに追い付いていない部分もある(笑)
小山 個別にはいろいろありますが、一般論としてのアドバイスは難しい。
大野 「京」を使って大規模な計算をするのであれば、並列化が2階層のハイブリッド並列が必要ですね。このハイブリッド並列に手間取っているケースがそこそこ見受けられます。
舛本 ハイブリッド並列は、実施本部も推奨していますよね。
小山 「京」に限らず、大規模なマシンではノードあたりのコア数が増える方向に向かっていますし、その意味でも、今後はハイブリッド並列でないとCPUパワーを引き出せないと思います、今のHPCの流れからすると。
大野 基本的なことですが、やっぱりアプリケーションを書く人の頑張りが必要ですね。どれだけHPCの性能を引き出せるかも、実はそこにかかっています。
大野 そういう意味では、私たちのような開発・高度化チームを利用するのは、1つの手だと思います。極端なのは完全分業で、ひたすらコードをチューニングする人と、それを使って研究する人を分ける形ですが、その場合、アルゴリズムまで見直したいというときに、研究者の計算したいものを壊さない変更でないといけませんから、ターゲットまでは理解していないにしても、計算手法とか、何を計算するのか、どういう計算をしたいのかというところまでは理解してチューニングしないといけません。完全分業だと、意思疎通などで問題があります。ある程度は研究にも片足を突っ込んで、コードのチューニングを行う、そういうスタッフが必要だと思います。
※2011年ゴードン・ベル賞エントリのための特別利用による成果
BioSupercomputing Newsletter Vol.6