第9回 HPF合同検討会 議事録

  1. 日時： 1997年5月28日(水) 10時00分〜16時30分
  2. 場所： 財団法人 高度情報科学技術研究機構(中目黒) 大会議室
  3. 出席者： 以上24名
  4. 配布資料
  5. HPF仕様の検討議事
    1. LOCAL節 / LOCAL指示文 の提案 (富士通 岩下氏)
      (提案説明)
      • RESIDENTでは性能を保証できないのではないかと考え提案。
      • 書式はRESIDENTと同じ。
      • 目的は、
        1. プロセッサごとに通信が閉じることを保証。 (RESIDENTは活動プロセッサ内のどこかにあることを指示するだけであり 活動プロセッサ間の通信はあり得る。)
        2. 対象変数を記述しないLOCAL指示によって、LOCAL手続きを指定。
        3. SHADOW付データのSHADOWにも有効としたい。 (オリジナルHPFではSHADOWに関するRESIDENTは指定できない)
        4. SHADOW部実行時、活動プロセッサが2台になってしまい、複雑な問題が 発生。また性能も落ちる。この問題を、SHADOW付実行はLOCAL付に 限るとして解決したい。すなわち、本体の実行と袖の実行は独立に (各プロセッサに閉じて)行なっても良い場合に限定。


      (議論)
      • RESIDENTとLOCAL という同じようなものが2つあってユーザが混乱する。 LOCALだけあれば、RESIDENTがいらないのであれば、LOCALをメインに できる。
      • LOCALの意味が不明確。活動プロセッサが各々ローカルコピーを持っている ということか？
        → 厳密には定義と参照で異なる。
        参照データ：実行する人がすべてローカルにデータを持っている。
        しかし、それが他のプロセッサにあっても良い。
        定義データ：実行する人がローカルにデータを持っていて、
        他のプロセッサにあってはいけない。
        RESIDENTの条件＋活動プロセッサの各々が袖を含めてデータを持っている ということである。

      • プロセッサ毎に通信が閉じることを保証するのであれば、 LOCALを使わなくても inherit A で、BをAにアラインしておけばよいのでは？
        → 実際にはインダイレクトアクセスとか、アクセスパターンが転置やストライド など宣言部には書けない場合に有効である。

      • もし、LOCAL(B)と書いて、Bがプロセッサ中に無い時はどうなるのか？
        → エラーになるかも知れないが、一般にすべてのエラーを検出するには困難。

      • もし、活動プロセッサが1台なら、LOCAL = RESIDENTか？
        → しかも、SHADOWがなければそうだ。

      • LOCALを指定した場合、SHADOWの部分も埋めなさいということか？ → 現在はそう考えているが、さらに検討している。定義側に指定した場合 検討を要する。

      • LOCALとあっても、ON HOME(..) WITHSHADOW での定義があると、定義 側にある配列は、すべてON HOMEで指定された集合と一致していなければ ならないのではないか？ つまりSHADOWを含めたALIGNと同じである。

      • 以下の例は、A1をWITHSHADOWで実行するということだが、A2のSHADOW も埋めるとすると、IについてのWITHSHADOWと考えたほうがよい。 ON HOME(A1(I)) WITHSHADOW LOCAL(A2(I),B(I)) BEGIN A1(I)=B(I) A2(I)=B(I) END ON

      • これは、代入文ごとにON HOMEを書くべきでは？ 1つにまとめようと するのでややこしい。
        → コンパイラがその2つのALIGN関係を読み切れないと2つのブロックが 融合できない。

      • 上の例で、SHADOWなしの配列A3があって、A3(I)=B(I)という文が あったらどうなるのか？
        → 文法違反。

      • このLOCALの定義では、変数指定のないLOCAL指示下に CALLがあった時、 その中の変数は、すべて複製(REPLICATE)しなければならなくなるのでは ないか？ ユーザに全部複製の指示をさせるのは辛い。
        → 呼び出せるサブルーチンには制約がある。1つは通常の逐次のFORTRAN (FORTRAN_LOCAL)。

      • HPF_LOCALを呼び出すのはどうか？
        → あとのEXTRINSICの所で、議論したい。

      • 2.の対象変数を指定しないLOCALの効果というのはちょっと置いておいて 1,3,4の効果だけでまず考えたい。

      • 4の目的で、WITHSHADOW付きの実行にはLOCALがいることにすると、 SHADOWのさらに隣をアクセスすることが出来なくなるがよいか？
        → そのような場合があるか、ユーザ側に聞きたい。
        → ユーザ側としては、その制約を受け入れても良い。

      (採決) LOCAL を検討するかどうかのFirst Reading
      賛成 15 : 反対 0 : 棄権 4
      検討を継続することに決定した。

    2. REDUCTION 種別 MAXLOC/MINLOC の提案 (富士通 岩下氏)
      (提案説明)
      • REDUCTIONのMAX、MINで位置を取るものを追加する。
      • reduction-kindとして、MAXLOC、MINLOCを追加。
      • 同一の値があった時の位置は、最初に見付けた要素の位置とする。

      (議論)
      • VPP FORTRANでは、同じものがあった時、どの位置が返るかはシステム 依存で、分からない。(プロセッサ数や最適化の違いで変り得る)。 これでも良いのではないか？
        → 論理上いい場合もあるが、逐次の実行結果と同じにならないのはやはりまずい。

      • (VPP FORTRAN型でなく)最初の要素を取り出すために、並列化の最適化 が制約されることはないか？
        → 本来、コンパイラが並列化する場合、逐次実行結果と同じでなければ ならないので、制約されると言うことはないが、最初の要素に限定し なければ、最適化がさらに進む可能性はある。

      • インデックスI,Jの値の定義があいまいでは？
        → I,Jは最大(小)値のイテレーションで定義されるというものだ。

      • 兄弟ループがある場合は？ 
            例
           DO J=1,N
            DO I=1,N
             IF(AMAX.LT.A(I,J)) THEN
               AMAX=A(I,J)
               ILOC=I
               JLOC=J
             END IF 
            END DO
            DO I=1,N
             IF(AMAX.LT.B(I,J)) THEN
               AMAX=B(I,J)
               ILOC=I
               JLOC=J
             END IF 
            END DO
           END DO
        → 多重ループの場合、REDUCTION指示は、最外側ループにだけ書けば良い。 上の例では、AMAXは、A(I,J)とB(I,J)[とAMAX]のMAXになる。 ILOC,JLOCはAMAXと同時に定義される。 必要なら、ベンダ側で議論して詳細をつめる。

      • 構文上の問題として、 REDUCTION SUM(A,B) のように2つ書けるのと、 MAXLOC(AMAX,LOC)とは整合が悪い。
        → 別途検討する。

      (採決)
      Reduction種別自体は、すでに2回の採決で採用が決定している。
      ここでは、MAXLOC,MINLOCに関するFirst Readingの採決を行った。
      賛成 15 : 反対 2 : 棄権 3
      検討を継続することに決定した。

    3. DYNAMIC 変数 - 問題点 (日立 太田氏)
      (提案説明)
      • HPF2では、DYNAMIC変数が手続き呼び出しの実引数になっている時の仕様が あいまいであった。仕様によれば、仮引数もDYNAMICなら、手続きからの return後もその状態(手続き内でremappingされた状態)を保持するとあるが その変数にALIGNしている変数をどうするのかが不明であった。 これは、HPF Forumに問い合わせしているが、未だ返答がない。
      • そこで、以前のJAHPFで
        • 暫定仕様として、DYNAMIC変数の実引数も、return時に常に元の mappingに戻すこと。
        • また、mappingを戻さない方法も別途考える。
        と決めた。今回これを決着したい。


      (議論)
      • ADIや多次元FFTにおいて、サブルーチン境界をまたがって、mapping 状態を引き継ぐようなパッケージが既に存在するので、余分のremapping が発生しないようにして欲しい。
            subroutine 
    redistribute ..(block,*)
    ...
    redistribute ..(*,block)
    return
              この状態で引き継いでほしい
    subroutine 
    redistribute ..(*,block)
    ...
    redistribute ..(block,*)
    return
        → HPFF本家の方でも議論が進んでいないようなので、 HPFFのJAHPF第2版で検討としたい。

      (採決)
      1. JAHPF第1版では、DYNAMIC実引数/仮引数は手続き内でremappingされても return時には、全て呼び出し時のmappingに戻す。2nd reading。
        賛成 18 : 反対 2 : 棄権 0
        により、元に戻すことに決定した。
      2. 手続き内でのremappingを元に戻さない方法の検討は、第1版では保留とする こと。
        賛成 15 : 反対 3 : 棄権 2
        (反対は、第1版で必要という意味)
        により、保留とすることに決定した。


    4. ON/RESIDENT の第2回目の採否 (日立 太田氏)
      (提案説明)
      • 前に提案した案(onはresidentを伴う。residentには変数名しか指定できない) を撤回し、on/residentはHPF2の仕様のまま受け入れるように提案変更。

      (採決)
      賛成 17 : 反対 0 : 棄権 3
      により、on/residentはHPF2の仕様のままとすることを決定した。


    5. TASK_REGION の第2回目の採否 (日立 太田氏)
      (説明)
      • TASK_REGIONについて(ON+RESIDENTとの関係等) 再度説明があった。 提案は、HPFの仕様をそのまま採用するである。

      (議論)
      • リージョン間で入出力に依存がないとはどういうことか？ 例えば同じ ファイルを使うのは？ 同一の装置番号を使うのはどうか？
        → HPF仕様書のindependentの所に規定されている。 同一ファイルまたは同じ装置に対しての操作(read,write,open...) は不可。inquireのみOK。またrandomファイルの異なるreq番号の アクセスも不可。

      • TASK_REGIONのON指示行で指定された実行プロセッサが重なっているか どうかが分からない時、無駄な同期が入るのでは？ 重なっている時は どう実行されるのか？
        → ON p(1:4) ON p(5:8) となっている時は、上の方でONに属していないプロセッサ は、IF文ですり抜けるから、並列に実行される。上のONがp(1:5)でも p(5)は両方で実行されるので大丈夫。

      • 部分プロセッサ中で realign があった時、そのrealignされた情報は end TASK_REGIONのところで、全員にbroadcastする必要がある。
        → そうかもしれない。


      (採決)
      賛成 17 : 反対 0 : 棄権 4
      により、TASK_REGIONは approved extensionの仕様をそのまま
      採用することを決定した。

    6. 部分プロセッサへのマッピング 第2回 (日立 太田氏)
      (説明)
      • DISTRIBUTE指示文のONTO節にプロセッサ配置の部分集合を指定できる機能 (下限:上限[:刻み幅)。用途は、主にTASK_REGIONとの組合せによるタスク 並列機能。

      (議論)
      • プロセッサ指定の刻み幅は必要か？ 2次元のプロセッサ指定で同様の ことは可能。
        → 特にあると困ると言うことはない。ここではこの仕様を変更せず 補正提案があれば、後で出すことにする。

      • P(1:4)→P(1:4)のREDISTRIBUTEを行った場合、部分プロセッサ内 のみでやるのか、それとも全プロセッサが係わる必要があるのか？ 海洋の計算内／大気の計算内で独立してREDISTRIBUTEしたいことはある。
        → そのREDISTRIBUTEした分散情報をTASK_REGIONの後で、コンパイラが 他のプロセッサに反映(ブロードキャスト)することで、問題なし。

      (採決)
      賛成 15 : 反対 0 : 棄権 7
      により、部分プロセッサへのマッピングを許すことに決定。


    7. Indirect分散 (日立 太田氏)
      (検討経緯説明)
      • indirect分散には巨大なインデックス変換テーブルが必要で、しかも スケーラビリティが無い。
      • インデックス変換テーブルが必要でない場合がある。そのようなコードの 特徴は、ループ範囲が配列宣言範囲と一致し、他のプロセッサのデータを 参照せず、しかも全ての添字が同一の場合。これは限られた場合ではないか？
      • BLOCK_INDIRECT分散を作れば巨大テーブルは必要無いのでは？ →これでも テーブルサーチなどで性能が出ない。
      • 結局性能を出すには、inspector/executer法が必須。
      (提案)
      • inspector/executer法が成熟するまで保留にしたい。

      (議論)
      • インダイレクト分散がないと、非常に書きにくい場合がある。 FFTの場合で、円形の領域Aがブロック分割された時、これを矩形領域 Bに詰め替えした時、Bをインダイレクト分散にしておくと、A=B の代入で転送が発生しない。 a_fft(ix(ig),iy(ig),iz(ig)) = b(ig)
        粒子系では、粒子の詰め替えをユーザが書くのではなく、インダイレクト 分散にしておいて、コンパイラが自動的にやってほしい。
      • FFTでの必要性が未だはっきりしないので、もう一度議論したい。
        → 6末のFirst Versionでどうするかをまず決めたい。

      (採決)
      第1版(6末)にいれるかどうかの採決。
      賛成 0 : 反対 11 : 棄権 10
      第1版には入れないことに決定。第2版で検討するものとする。

      その他、粒子の詰め替えを行うライブラリルーチンを用意しては
      どうかという意見があり、ベンダ側で検討することとした。

    8. FULL SHADOW 指示行(旧 SHRUNK/NOSHRUNK) の2回目 (NEC 林氏)
      (提案説明)
      • 前々回、shrunk/noshrunk指示行として提示したものと内容的には 同じであるが、その時、shadowと同じようなものが何種類もあるのは 分かりにくいとの意見が出たので、shadowの中に組み込んでしまう ことにした。

      (議論)
      • 多次元配列のある次元だけをfull shadowに出来ないか？
        → コンパイラの都合だけから考えると、ある次元だけfull shadowに してもアドレス変換しないというメリットはない。しかし それが有用であれば検討する。

      • shadowの他の機能(with shadowやreflect)との互換性を考えないと いけなくなる。キーワードを変えるか、再検討が必要。

      (採決)
      仕様を含めて、これでよいか？
      賛成 4 : 反対 9 : 棄権 9
      否決された。

      仕様を修正して検討すべきか？
      賛成 12 : 反対 2 : 棄権 7
      仕様を修正して検討することに決定した。
      修正の方向は、
      • 各次元で指定できるようにすること
      • 他のshadow機能との互換性を検討
      である。

    9. EXTRINSIC手続き 2回目 および LOCAL PURE 2回目 (NEC 末広氏)
      (提案説明)
      • やりたいことは、 HPFから他言語・他実行モデルの呼び出しにおいて、拡張の実行モデル であるPRIVATEの提案と 他言語・他実行モデルからHPFの呼び出しの提案 である。
      • その前提として、GLOBAL,LOCAL,SERIAL,PRIVATEの各実行モデルを説明
      • PRIVATEは並列ループから呼び出せる。

      (議論)
      • LOCALの場合、residentかどうかは誰が保証するのか？
        → プログラマが問い合わせ関数を用いて、問い合わせる。 PRIVATEでは、residentでないものがあっても、コンパイラがデータ 転送を加えることで、並列化しうる。

      • PRIVATEとLOCAL_PUREの違いは？
        → LOCAL_PUREでは分散配列のアクセスが出来ない。

      • LOCALモデルとPRIVATEモデルの違いは？
        → LOCALモデルは並列ループ中から呼び出せない。
        → PRIVATEの目的は、並列ループ中から呼び出したいということ。 例えば、一次元FFTをループで回して多次元FFTとして使いたい。 これが現在の機能で出来るか出来ないかはっきりしないので PRIVATEを提案した。
        LOCAL_PUREについては、メーリングリストで議論して、既存 機能で出来るようなので、提案を取り下げた(太田氏)。

      (結論)
      • この機能は必要そうなので、ベンダ側でもう一度議論して詰める。 特に、HPFから既存のF90を呼び出せること(PRIVATEとして)は重要。


    10. ファイルI/Oについて
      (問題提起)
      • 並列プログラムからI/Oする場合、現状では1台のプロセッサに集めて read/writeしているが、これだと配列サイズが大きくなり、出来ない 場合がある。どうやるのか教えて欲しい。

      (議論)
      • 要求としては
        • ファイル見えは1つ。読み／書きでプロセッサ数が変っても正しく処理できる。
        • 物理的にばらばらになっていても、編集可能。
        • 装置の数に応じて、スケーラブルな性能。
        • sequential/directアクセス共に可能
        • write文の書き方は変っても良い。

      (結論)
      • 次回に 各社で現在考えていること、コンパイラとOSのインタフェースで何がいるか などを提示すること。


  6. JAHPFホームページについて RISTよりサーバーのセットアップとネットワークの接続が出来たとの報告が あった。ホームページ上に何を載せるか。議事録、資料、マニュアル、HPFFミラー 仕様書 がありうる。末安氏より案を出すことにした。
  7. 入会希望の件 妹尾氏より、京大大型計算機センタの岡部助教授の入会希望が伝えられた。 次回までに、紹介状を用意することとした。
  8. HPF関連テキストに関する合意事項 前回指摘事項の字句修正を行い、承認された。
  9. 事務連絡
    今後の日程
    • 第10回 6/18(水) 10:00-
    • 第11回 7/2 (水) 10:00-
    で終了したい。
    次回の内容は
    • 非同期転送の詳細仕様の詰め
    • manual shadow
    • range 指示行および代替案
    • 手続き境界の非同期マッピング
    • full shadowの仕様
    • keep buffer/ release buffer
    • local_pure, extrinsic, private
    • reductionのmaxloc,minloc詳細
    である。
以上