−司会− 九州大学大型計算機センター 渡部善隆

【司会】

京都大学の報告について質疑ご討論をいただきたいと思います。

【中村】（航空宇宙技術研究所）

2つほどお聞きしたいのですが、1つは、MVPP連携がまだ動いているということは、まだ MSPマシンがあるということですか。

【平野】(発表者：京都大学大型計算機センター)

はい、そうです。

【中村】

もう1つは、全部のキューを足すと PE数を超えるのですが、これはどういう運用をされているのでしょうか。マルチジョブ運用ですか、それともジョブスワップでしょうか。

【平野】

マルチジョブではなく、シングルでやっています。もう少し戦略的にやればいいのですが、現状、フルに走ることは、キュークラス全体でジョブ待ちが発生することはないと見込んでいまして、こういうような設定で流しています。

【中村】

例えば PE数 40の hクラスがきたときに、最長で 540分は滞在している可能性があるわけですよね。その間に TSSとか小さなジョブがきたときには待たされるのですか、それとも追い出されるのですか。

【平野】

待たされます。設定的には、40が走っているときには、あと20に残っていますから 10が 1本とベクトルのジョブは走るという考え方です。Eとか F、10PE 使うジョブが複数入れられると、それが PEアロケーション待ちになるということは事実です。

【中村】

そうしますとファイル・システムの方でジョブスワップ領域とか取ってありますが、これはどういう用途に使われるのでしょうか。

【平野】

今後使うというだけです。ファイルシステム設計のときにそういう領域を用意しましたが、現状は使っていません。ただ領域として用意しているということです。

【中村】

いまはまだ初期の段階なのでジョブが空いているということですか。

【平野】

そういうことです。

【司会】

他に何かありますか。

【谷口】（大阪教育大学情報処理センター）

性能結果の図2 〜図9 ですが、私はこういう計算機を使ったことがないのでよく分からないのですが、例えば極端なところですと、図7 で 2000くらいのところに 1つ段差があって、4000にも段差が出ていますね。それは何に原因があるのでしょうか。

【平野】

後ほど VPPのハードの発表で話しがあると思いますが、ベクトルレジスターがありまして、最大ベクトル値を 2048という部分で一旦切れるという話がありまして、一旦切られてまた立ち上がるという部分でのオーバーヘッドでこのような図になるということです。

【司会】

富士通の方で分かりやすく説明できる方がいらっしゃるでしょうか。またあとでということでよろしいでしょうか。では、それ以外にありますか。

【福田】（航空宇宙技術研究所）

NQSで使えるメモリが 7GBと書いてありますが、残りの 1GBはどうなっているのですか。

【平野】

現状、京大でやっている分は、IOPEといわれる分が、OSで 512MB必要です。セカンダリーの PEは 256しか使っていないので、データサイズを 7GBに設定して、それ以外にスワップとか、そういう部分はその外に出しています。

【福田】

ユーザリージョンが 7GBで、残りは OSのリージョンやデータ転送のためのバッファに食われているという意味ですか。

【平野】

そうです。それでいるのが IOPで 512MBなのです。

【福田】

512MBというのは、OSがそれだけ食っているのですか。I/O のためのバッファが、例えば 380MBほどあってということなのでしょうか。OSで 512MBというのは、とんでもない数字だと思うのですが。富士通の方、そんなものなのですか。

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

いま平野先生からもお話がありましたが、プライマリーPE が 512MBで、セカンダリーが 256MBということで、プライマリーのところは、I/O の制御をするとか、それのバッファを持っているとか、システム全体の制御をするというところが入っていまして、少し大きくなっているということです。

【福田】

標準指定されているバッファ容量では足りなくて、例えば大きくしたいといったときは、その追加バッファは当然その 512MBに入っていないわけですね。

【大空】

それはシステムが使う 512MBの中に入っています。

【福田】

ちょっと取りすぎじゃないですか（笑）。
もう1つ、姫野さんに伺います。NFSではっているというのは、他にソリューションがないからですか。NFSでは遅くてたまらないのではないかと思うのですが、そうでもないですか。

【姫野】(理化学研究所)

実は私自身が使ったことがないという問題があるのですが、NFSではってあるのはユーザのホームディレクトリだけで、そこには大きなデータは置かないという暗黙の了解をしてもらっているということです。ワークは直接 Gen5がつながっています。

【福田】

そのファイルは、例えばファイルシステムとしては、ユーザは FTPなどで送るのか、あるいは別のファイルシステム、一元的にサポートしてくれるファイルシステムがあって、それを使えばユーザはそんなにアーカイブするのを気にしなくて済むのか、どうなるのでしょう。ローカルに 700の下にあるファイルに一旦データが入りますね。ある程度時間が経つとか何かしたときは、テープアーカイブの方へ自動的に行きますか。

【姫野】

それはユーザが自分でコピーします。

【福田】

何か適当なファイル転送の仕組みでもあるのですか。

【姫野】

フロントエンドに入ってもらって、自分で /workから /arcへテープアーカイブ装置に自分でコピーします。テープアカイブ装置に入ったら、あとは勝手に時間経過とともにテープへ落ちるということです。

【福田】

長時間ジョブがありましたね。あれは一度に60時間とか走らせるのではなくて、例えば 5時間ずつ 12回に切るとかいうことになるのではないかと思うのですが、そんなことはないですか。

【姫野】

それは直接ユーザとの話し合いで決めますが、とくに希望すれば 50時間ずっと走りっぱなしでも・・・。ちょっといまこわいですけれども（笑）。

【福田】

そうしたとき、いろいろなことを考えてジョブをつなぐ方がいいと思うのですが、例えば 118台で動かした場合、1回ジョブを終わり、継続するためにデータを吐き出し、次にまた読み出しますね。フルの構成で走らせたとき、どのくらい時間がかかるか計測してみたことはありますか。

【姫野】

100GBの入出力があった場合に、確か片道 30分くらいだったと思います。

【福田】

もし 5時間でジョブを切ったとしたら、1時間は入力と出力にかかるということですか。

【姫野】

はい、そうです。

【司会】

他にありますか。

【姫野】

VPP500と 800の演算速度の比ですが、理論ピークは 5倍ですね。それに対してふつうの乗算や加算は、せいぜい 3倍くらいしか早くなっていないということですね。それが設計なのですか（笑）。

【平野】

理論性能と実測値が合っていないということですか。

【姫野】

そうではなくて、理論ピークを上げるために実際には出ないような設計になっているのか、それともちゃんと理論ピークを賄えるだけの設計になっているのかという質問です。

【田村】（富士通(株)コンピュータ事業本部 HPC開発統括部）

乗算性能を測定したジョブは、ロード、演算(乗算)、ストアが組み合わされた性能測定になっていると思います。

【平野】

はい、そうです。Fortranでコーディングしたループです。

【田村】

乗算性能評価ジョブですが、実際のパイプラインの動きは、データ供給(ロード): 2回、演算(乗算): 1回、結果の格納(ストア): 1回 となるため、本性能測定ジョブのように演算が少ない場合は、ロード/ストアパイプライン動作によって性能値が変わります。

【福田】

ピークに対して 5倍というのは、M&Aが走れば 5倍だけれども、Mしか走らなければ実はピークに対して 2.5倍で、ピークに対して 2.5倍がハードのクロックと私は理解しています。それに対して 3.2倍というのは出すぎで、それは逆に言うと、オンメモリのベンチマークになっていればメモリ系が強化されている分早くなっているという話ですね。

【田村】

VPP500も、乗算パイプラインと加算パイプラインの 2本のパイプラインを合わせて 1.6 Gflops ですから、乗算だけで比べると VPP500のピーク 0.8 Gflops と、VPP800のピーク 4.0 Gflops で 5倍となります。
今回の性能測定は、ロード: 2回、乗算: 1回、ストア: 1回ですから、VPP800では 3チャイム、VPP500では 2チャイムが必要となりますので、3.3倍になると思います。

【福田】

クロックで 5倍、チャイムで 2/3だから、3.3倍はだいたいリーズナブルということですね。分かりました。

【田村】

計算上はそういうことだと思います。

★補足情報★ VPP800の乗算性能実測値(VPP500比：3.2倍)に対する論理的解析

VPP500(ピーク性能：1.6 Gflops、クロック：10ns)は、下図のように 2チャイムで処理される。従って、乗算パイプと加算パイプが全て使用された時に達成するピーク性能：1.6 Gflops の1/4が実際に使用されている。

1.6 Gflops × 1/4 ＝ 0.4 Gflops …………………(1)

■■：使用されたパイプ
□□：空きパイプ 　

	チャイム数
	1	2
ロードパイプ	■■■■■■ ＶＬ ■■■■■■ ■■■■■■■■■■■■■■	■■■■■■ ＶＬ ■■■■■■ ■■■■■■■■■■■■■■
乗算パイプ	□□□□□□□□□□□□□□ □□□□□□□□□□□□□□	■■■■■■ ＶＭ ■■■■■■ ■■■■■■■■■■■■■■
ストアパイプ	□□□□□□□□□□□□□□ □□□□□□□□□□□□□□	■■■■■■ Ｖ Ｓ Ｔ■■■■■ ■■■■■■■■■■■■■■
加算パイプ	□□□□□□□□□□□□□□ □□□□□□□□□□□□□□	□□□□□□□□□□□□□□ □□□□□□□□□□□□□□

VPP800(ピーク性能：8.0 Gflops、クロック：4 ns)は、下図のように 3チャイムで処理される。従って、演算パイプが乗算&加算で全て使用された時に達成するピーク性能：8.0 Gflopsの演算能力の 1/6が実際に使用されている。

8.0 Gflops × １/6 ＝ 4/3 Gflops …………………(2)

■■：使用されたパイプ
□□：空きパイプ

	チャイム数
	1	2	3
ロードor ストアパイプ ※1	■■■■■ ■ ＶＬ ■■ ■■■■■ ■■■■■	■■■■■ ■ ＶＬ ■■ ■■■■■ ■■■■■
乗算&加算 or 乗算 or 加算パイプ	□□□□□ □□□□□ □□□□□ □□□□□	■■■■■ ■ ＶＭ■■ ■■■■■ ■■■■■	□□□□□ □□□□□ □□□□□ □□□□□
ロードor ストアパイプ ※2			■■■■■ ■ Ｖ Ｓ Ｔ■ ■■■■■ ■■■■■

※1と ※2 は同一パイプ

(1)と(2)より、VPP500と VPP800の乗算性能比は、以下のようになる。

VPP800/VPP500 ＝ 4/3 ÷ 0.4 ＝ 10/3 ≒ 3.3 (倍)

従って、京都大学殿が行ったVPP800の乗算性能評価実測値 3.2倍 は、論理的な解析値(3.3倍)とほぼ一致しており、妥当な値と考える。

【司会】

もう 1件くらい時間がありますので、どうぞ。

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

ループの回転数が 2000および 4000を少し超える所で性能段差が見られる件ですが、これはベクトルレジスタの最大長が 2048ですので、2048毎にループのベクトル処理が繰り返されます。このためのオーバーヘッドによるものです。
このオーバーヘッドは、最大値検索、総和演算、内積等のマクロ演算では若干大きくなります。それが図7、8、9 の性能段差となって現れています。

【司会】

午後のセッションが詰まっていますので、ここで締めたいと思います。平野さん、ありがとうございました。(拍手)