- 日時： 1997年4月21日 (月) 09時00分〜16時40分
- 場所： 財団法人高度情報科学技術研究機構（中目黒）大会議室
- 出席者（氏名アルファベット順，敬称略）
- 林康晴（日本電気株式会社）， 岩下英俊（富士通株式会社），
- 神谷幸男（富士通株式会社）， 河合伸一（宇宙開発事業団），
- 松元亮治（千葉大学）， 三好甫（高度情報科学技術研究機構），
- 長嶋利夫（株式会社三菱総合研究所），中村寿（高度情報科学技術研究機構），
- 野方康一（株式会社日立製作所）， 布広永示（株式会社日立製作所），
- 荻津格（東京大学物性研究所）， 岡田信（富士通株式会社），
- 太田寛（株式会社日立製作所）， 坂上仁志（姫路工業大学），
- 左近彰一（日本電気株式会社）， 妹尾義樹（日本電気株式会社），
- 嶋英志（川崎重工業株式会社）， 新内浩介（株式会社日立製作所），
- 末広謙二（日本電気株式会社）， 末安直樹（富士通株式会社）(記)，
- 鈴木睦（環境庁 国立環境研究所）， 高橋俊（株式会社日立製作所），
- 高村守幸（富士通株式会社）， 谷 啓二（日本原子力研究所）
- 山崎昇（株式会社富士総合研究所），
- （事務局）秦万美子（高度情報科学技術研究機構）
以上２６人
- 配布資料
- 第７回HPF合同検討会 議事次第(事務局)
- 第６回HPF合同検討会 議事録(末広氏)
- HPF合同検討会 概要(事務局)
- JAHPF拡張提案 通信スケジュール再利用(妹尾氏)
- HPF公認拡張 EXTRINSIC手続(林氏)
- JAHPF拡張提案 Extrinsic手続きに関する拡張(末広氏)
- HPF公認拡張 組込み手続きとライブラリ(末広氏)
- SHADOW関連の仕様(岩下氏)
- HPF仕様の検討議事
- SHRUNK/NOSHRUNK指示行について
[提案の趣旨説明] (林氏)
- SHRUNK/NOSHRUNK指示行を追加したい。
[討議内容]
- 主要でない配列のためにNOSHRUNKが必要と言うのはおかしい。そもそも
主要でない配列は、SHRUNKで構わない。
- BLOCK分散は、SHRUNKだけでも構わないが、CYCLIC(n)や複雑なalignでは
SHRUNKでは性能が出せない。
⇒ しかし、それらは遅くても構わない。
- NOSHRUNKとSHRUNKを比較してはいけない。アプリの側から現実的に考えると、
NOSHRUNKとreplicatedを比較すべきである。
- NOSHRUNKとreplicatedでのデータ転送コストを比較すると、
readではreplicatedが勝り、writeではNOSHRUNKが勝る。
- コンパイラのオプションとして、NOSHRUNKを選択する方法を
用意するかも知れない。
⇒ あっても悪くはない。
- replicated,noshrunk,shadow,... のように多くのレベルがある。
(バッファの大きさ,通信の度合)をキーにして、統一的に扱うことはでき
ないか？
[採決]
- このような指示行が必要であるか？
賛成 11 反対 7 棄権 2 ⇒ 引続き検討する。
- バッファ制御機能について
[提案の趣旨説明] (妹尾氏)
- KEEP_BUFFER/RELEASE_BUFFER指示行を追加したい。
[討議内容]
- 再配置に伴う転送に比べれば、領域確保の時間的コストは大きくない。
- 別々の配列を用意すれば、この機能はいらない。
- KEEP_BUFFERの度にkeepするのは、大変な数のバッファをkeepすることに
ならないか？
[採決]
- このような機能が必要であるか？
賛成 14 反対 5 棄権 1 ⇒ 引続き検討する。
- 組込み手続とライブラリについて
[提案の趣旨説明] (末広氏)
- (a) 公認拡張での組込み手続とライブラリの拡張
- (b) 公認拡張でのtransposeの拡張
[討議内容]
- 新しい機能を加える場合には、ライブラリの拡張も同時に提案して欲しい。
[採決]
- 提案(a)を採用するか？
賛成 19 反対 0 棄権 1 ⇒ 採用する。
- 提案(b)を採用するか？
賛成 13 反対 3 棄権 4 ⇒ 採用する。
- Extrinsic手続に関する拡張について
[提案の趣旨説明] (末広氏,林氏)
- (a) (HPF,Fortran,F77,C)x(LOCAL,SERIAL)の各々のモデルに対する採否。
- (b) PRIVATEモデルを追加したい。
- (c) LOCAL_PURE手続を追加したい。
- (d) 他言語・実行モデルからHPF_GLOBALを呼び出す機能を追加したい。
[討議内容]
- local_pureは、resident+onで実現できるか？
⇒ 部分的にYes。local_pureは、parallel loop以外からも呼び出すこと
ができる。つまり、重複的な実行をする関数になれる。この機能は
resident+onでは実現できない。
- resident+on方式とprivate方式の違いは、intent(in)のpreload機能の有
無だけだ。
- Global,Local,Privateのそれぞれの例とその動作を示して欲しい。
⇒ 提案(a),(b),(c)に関しては資料をまとめ、再提案する。
[採決]
- 提案(d)の機能が必要であるか？
賛成 15 反対 1 棄権 4 ⇒ 引続き検討する。
- 通信スケジュール再利用について
[提案の趣旨説明] (妹尾氏)
- HPF+相当の通信スケジュール再利用機能を追加したい。
[討議内容]
- HPF+にはindirect分散があるのか？ ⇒ Yes。
- inspectorは、同じ要素を複数のプロセッサでreadする場合にも有効であ
る点がindirect分散と違う。
- indirect分散でデータ転送を減らせるのは確かだが、それがゼロにはなら
ない以上、inspector機能も必要だ。
- この機能があれば、manual shadowは不要になるのか？
⇒ No。manual shadowは、通信自身を減らす仕様である。
[採決]
- 詳細な検討が必要であるか？
賛成 20 反対 0 棄権 0 ⇒ 引続き検討する。
- 非同期転送について
[提案の趣旨説明] (岩下氏)
- (a) 非同期再分散，非同期再整列機能を追加したい。
- (b) 非同期代入機能を追加したい。
[討議内容]
- 非同期再分散，非同期再整列の制約として、次のものも考えられる。
- ON HOMEなどでの分散情報の参照
- HPF_LOCALルーチンの呼び出し(暗黙のbarrierとの整合性)
- async-idは、いちいちSEQUENTIALと宣言する必要があるのか？
⇒ 制約としては、"明示的な分散を記述してはならない"で十分ではない
か？
- 非同期転送中の対象変数に関する制約は、コンパイラでチェックすべきか？
⇒ できない場合がある。ユーザの責任としたい。
- async-idがCOMMON変数や引数ではいけない理由は何か？
⇒ コンパイラの最適化のために制約とした。
- 非同期代入文に関しては、サブルーチンを跨いでWAITしたい。
- ASYNC REDISTRIBUTE文をASYNC文とREDISTRIBUTE文に分けてはどうか？
- WAIT REDISTRIBUTE文，WAIT REALIGN文をWAIT文として統一したい。
- 再配置実体に引数やModule変数を指定できない理由があれば示して欲しい。
[採決]
- 提案(a)を採用するか？
なお、async-idの扱いや構文はベンダ側に一任するものとする。
賛成 22 反対 0 棄権 1 ⇒ 採用する。
- 提案(b)を採用するか？
原案どおりで賛成 10 反対 7 棄権 6 ⇒ 引続き検討する。
- 手続を跨る非同期転送を検討すべきか？
賛成 8 反対 5 棄権 10 ⇒ 引続き検討する。
- SHADOWの拡張について
[提案の趣旨説明] (岩下氏)
[討議内容]
- ONで複数のプロセッサが選択された場合、MANUAL SHADOW部分をRESIDENT
と指定しても整合性が取れるのか？
- REFLECT文があればMANUAL文は不要だと思う。
- ユーザが出すreflectとコンパイラが出すreflectが混在するのか？
- MANUAL SHADOWの付いた変数はコンパイラが一切の通信を生成しないとい
う案もある。
- 非同期REFLECT文を用意して欲しい。
- SHADOWの一部分に対するREFLECT文があってもいい。
- 次回は、高橋氏，太田氏，岩下氏の案を示して貰いたい。
- 新会員の紹介
- 事務連絡
次回は5月14日(水)10時から高度情報科学技術研究機構にて開催する．
以上