−司会− 高エネルギー加速器研究機構計算科学センター 石川 正

【司会】

ただいまのご報告について質問、コメント等お願いします。

【石坂】（富士通(株)システム本部第三システム事業部第一文教システム部）

東大物性研殿を担当させていただいています。藤堂先生から VPP500の MPIの性能ということで説明がありましたが、今日お集まりの方の中には、実際、最新鋭の VPP5000ではどうなんだとお感じの方もいると思います。実はプログラムをいただきまして、我々で流させていただきました。簡単に紹介させていただきます。

　資料に send & recv というのがありますが、これが VPP500ではクロスバー・ネットワークの 80％くらいの性能が出ます。これに対して VPP5000では、約 90％になります。問題の sendrecvが、VPP500では 42％となるのですが、これも VPP5000では約 90％の性能が出ます。もう 1つ、sendrecv_replaceが、VPP500の場合 23％くらいですが、これについては約 80％という値が最新の VPP5000で測ることができました。

藤堂先生から質問いただいている中から、まず sendrecv_replaceが遅いのではないか、VPP5000になっても他のものが 9割くらいなのに 8割にしかなりませんので、少し遅いのではないかという疑問と、VPP500と VPP5000で結構差が出ますので、その辺りはどうなのかということと、最後に isend & recv の性能グラフの話が出ましたので、これらについて分かる範囲で事業部からお答えします。

【大和田】（富士通(株)ソフトウェア事業本部 HPCソフトウェア統括部）

最初に富士通 VPP500上の MPIの性能が低い件ですが、この版は、MPI1という新しい言語仕様に準拠した最初の製品で、性能的には必ずしも十分でないところがあり、ピンポン性能とその他の関数の性能差が出ていたという状況です。その後、VPP300、700、VPP800、5000に向けて MPI2準拠の言語処理機を出しています。その中では、ただいま担当SEから報告があったように、実効性能で 90〜80％、そういうレベルで全体的に転送性能の改善をしています。
sendrecv_replaceの場合、sendrecvに比べて 10％性能コストがかかっていますが、特有のオーバーヘッドが入っていることが原因ではないかと思われます。

ただ、 VPP800、5000に向けても、新しい製品ということで、まだ全般的な性能チューニングが細かく実施されていません。MPI2は、100〜200というかなりの数の関数がありますので、今後とも優先順位をつけて継続的に改善をしていきたいと思っています。今回、このプログラムの例で、詳しく調べますと他にも原因が考えられる可能性がありますので、その辺はプログラムを貸していただいて、別途詳細に検討させていただきたいと思います。

　もう1つ、プログラミングスタイルについてのご指摘がありました。利用者の観点から言いますと、逐次プログラムを最初に作って、それが段階的に並列化高速化できるというアプローチが、性能を含めてできれば一番すばらしいと思います。ただ現状、プログラミングのモデルごとに適切な言語を選択していただくという状況だと思っています。Open MPが共用メモリ型の言語仕様として認知されつつありますが、Open MPの次期仕様においては、分散メモリへの対応ということでデータの分割に関する仕様等も検討されているようです。そういう意味でシステムアーキテクチャの進歩とともに、その中で一緒に言語仕様もこれから検討されていくものと考えております。

【司会】

VPP800と 5000の言語系についてはこのあと富士通からの報告、またフリーディスカッションがありますので、そこでまた議論していただきたいと思います。藤堂さん、ありがとうございました。(拍手)