−司会− 航空宇宙技術研究所 福田正大

【司会】

最後のアプリに関する発表への質問でも結構ですし、ハードから含めて全体に関係する質問でもかまいませんので、総合討論に移りたいと思います。

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

チューニングサービスの事例の並列化で、8並列で 4.7倍とか 15並列で 12倍と胸を張っていらっしゃいますが、この数字だけを見ますと、ずいぶん悪い性能と見えます。これには理屈があると思いますので、その辺を明らかにして欲しいと思います。どうしても転送の負荷がある程度高いアプリだったので、この程度しか出ないとか。

【森重】(富士通(株)システム本部計算科学技術センター HPCシステム部)

転送方法の改善、データの配列等も考えて転送等をなるべく削減するような改善を行いましたが、ご指摘のとおり、アルゴリズムの関係もありまして、こういう性能になったということです。

【中村】

そのときの演算にかかっている時間や演算量、転送にかかった時間や転送量を測っているのでしょうから、あとできちんとした数字が欲しいと思います。

【森重】

別途ご報告させていただきます。

【司会】

公開してもかまわないデータであれば、最後にニュースレターにする際に、そこに載せていただきたいのですが。

【森重】

私自身、正確な数字を覚えていませんので、別途ご報告させていただきます。

質問への回答

【質問】 並列化事例において並列性能が出ていない(16PEで12.3倍等)のはなぜか？ 【回答】 例として、3番目の多体問題解析プログラム(16PEで12.3倍)の場合について、ご説明します。 3番目のプログラムでは、ほぼプログラム全体が並列化されており、演算量とデータ転送量の比は、平均して以下のようになっています。 　　　演算量　＝　(DOループ回転数)　×　（１回転当たりの演算量）　 　　　　　　　＝　　　　(128**3)　　　　　×　　　　64　（＝Ａ）　 　　　データ転送量（配列要素数）　　　　　　　　　　　 　　　　　　＝　（２次元配列要素数）　×　（袖幅）　 　　　　　　＝　　　(128**2)　　　　　　×　　8　　　　　（＝Ｂ）　 　　　→　データ転送量／1PE当たりの演算量(16PE時)　＝　Ｂ／(Ａ／16)　＝　1/64 　上記の通り、本プログラムでは、(転送の袖幅の関係もあり)、演算量に比較して転送量が大きく、並列性能が向上しなかったものと考えます。

【中村】

可能なかぎり公表の方向でお願いします。

　次は遡りまして、大和田さんに質問です。VPP Fortranについて何も話がなかったのですが、これはちゃんとサポートされているのですか。それともわざと載せないで、次からサポートしない振りをするという高度なテクニックなのでしょうか。

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

当然サポートしております。性能的にも従来から実績もあります。それも含めて VPP向けにきちんとサポートしています。

【中村】

実行時情報のフィードバックというのがありましたが、これは実際の手順としては、ユーザがジョブを投入して 1回計測し、もう 1回それを投入したときには早くなるという意味ですか。

【大和田】

そういうことです。

【中村】

最後の質問ですが、木村さんの OSに戻ります。NQSJSですが、確か去年の合同分科会か HPCミーティングのときに、説明があったかと思います。そのときに航技研からも発表があって、機能差がずいぶんあったと思うのですが、それに対するエンハンスはなされたのでしょうか、あるいはする気があるのでしょうか。

【木村】(富士通(株)ソフトウェア事業本部 HPCソフトウェア統括部)

具体的にはどんなことですか。

【中村】

ジョブのスケジューリングのところでいろいろな機能がJSにあったと思いますが、それに対して航技研でも NWTのジョブスケジューラを発表したと思います。そのときにずいぶん機能の差があったと思うのです。

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

合同分科会のパラレルセッションのところだったと思いますが、航技研のジョブスケジューラについて説明していただいて、すばらしい機能がたくさんありました。JSと比較をして、でこぼこがあったと思いますが、そこでやったものに加えて、どれかというのはいまは言えないですが、できるものについては拡張して機能を入れたものにしています。

【司会】

今日発表があった、空き資源スケジューリングや永久待ちの回避は、うちでやっていたものと似たような機能が入っているのではないかと思います。

【中村】

ちょっとと言うか、だいぶ足りないと思いますが。

【司会】

他に質問ありますか。

【根本】（アトムテクノロジー研究体）

いまの中村先生のお話に絡むと思うのですが、ジョブの凍結機能やスワップ機能があります。これで、いまご報告があった NQSJSの永久待ちの回避というのがあったと思います。ジョブが、例えばスワップや凍結、解凍をしたときに、戻る PEが実行された PEにしか戻れないという仕様があったと思います。例えば運用を見ている人間の立場から言うと、もっと、どこの PEでも戻れる仕様の方がいいとも思うのですが、その辺の改善が技術的にも不可能で、その代わりとして永久待ちの回避という、今回の NQSJSの機能が入っているのでしょうか。

【木村】

代わりというわけではないのですが、NQSJSの機能自身はそれで有効だと思っています。確かにいまいわれたような PEを他の PEにジョブスワップされたものを移すとか、そういう機能のご要望も強くて、時期は遅れますが、実現する方向で検討しています。ただ、基本的にはジョブスワップを別のところに移すのはむずかしくて、ジョブ凍結を使って別のところに移すような機能を、いま検討しています。

【司会】

他にどなたかございますか。

【金澤】（京都大学大型計算機センター）

ハードの方で、スカラユニットの話を聞いてびっくりしました。なるほどダイレクトマッピングだったら、仕様が分かってしまって意地悪されたら、ボロボロのマシンになり、けなされるのは当然でしょう。今度の VPP800や 5000でも、2ウェイで本当に大丈夫なのでしょうか。特に、先ほど同時に 4つのプロセスがスィッチしながら動くという話しでしたが、すぐヒット率が低下すると思います。2次キャッシュでも 4ウェイというのは、ちょっと少ないのではないでしょうか。これが、第１番目の質問です。

　もう 1つは、日立のSR8000は、命令キャッシュとデータキャッシュのサイズを違えています。当然だと思います。命令はそんなに大きくする必要はないけれど、データは大きれば大きい方がいいと思います。富士通はずっと同じサイズを守り続けていますが、今後も守り続けるのでしょうか。

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

2ウェイでは少なすぎるという話ですが、確かに私も 2ウェイでは少ないと思います。しかし、今回のキャッシュ設計では、限られた資源(チップサイズ)の中で、キャッシュ性能改善効果の大きい、キャッシュ容量の倍数と、2ウェイ化を実施しました。

　命令キャッシュとデータキャッシュのサイズの問題ですが、これも実はそれぞれのキャッシュに適した容量に最適化するべきだと思います。しかし、今回のキャッシュ設計では、命令長を 64ビットから 128ビットと倍に増加させた関係から、現行機レベルの命令キャッシュ性能を確保するため、命令キャッシュの容量増加も同時に行いました。次に、キャッシュ容量を増加させる時は、データキャッシュを優先させると思います。

以上のように、VPP800/VPP5000のキャッシュは、キャッシュ性能改善効果の高いところを強化できたと考えています。

【司会】

ちょうど時間にもなりました。11月4日〜6日、連休と日曜日のあいだで木、金、土ですが、SS研の合同分科会が神戸であります。2日目の金曜日に、科学計算分科会第2回目があります。それから、6日の土曜日になりますが、エンドユーザという立場から見た HPC ということで、HPCミーティングという会議も予定されています。ぜひ出席していただいて、今日議論できなかった続きをしていただきたいと思います。

　本日、長くお付き合いいたしまして、皆さん、ありがとうございました。(拍手)