Conference Room SAD
[thread display] [new arrival display] [word search] [past log] [管理用]

Subject ： Re^15: SAD Update. V1.0.10.2.3b. g95 compatible.
Date： 2008/02/23(Sat) 23:37:43
Contributor： Akio Morita 

> 早くmain側にも反映させてください。
>
g95サポート回りですか？
基本的には src/sim/fgetc_Dummy.f捨て捨てな点以外の内容は、
CVS MAIN trunkと同じですから、動作は変わりませんが？
# API仕様的には、readstr()が EOF/Errorで戻ったときに呼び出し側で
# bufferをクリアしているコードがあったので、readstr()側でクリアするように
# 安全側に変更しています
# リターンコードを確認して使っているコードに対しては、無駄な
# white space fillingを行うことになりますが、不注意なコードが
# readstr()呼び出し前の内容が未定な bufferを読み込むことを
# 避けられます

現状の実装に関しては、こちらのbranchでも下記のような問題が山積みなので、
本格的な itfgetbuf_.cの使用は避けた方が良いと思っています
# バックポートするなら、この辺の問題が片づいてからかなと思っています
o 現状の src/itfgetbuf_.c + read(2)を使う場合の問題点
 1. Read性能の劣化(試験環境で、読み込みスループットが 1/20〜1/10へ低下)
    * Character-by-characterで read(2)システムコールを発行するため
 2. 同一Logical Unit Numberに対して Read[], Write[], SeekFile[]関数を
    組み合わせて使用した場合の動作が不定となり保証できない(ファイルの部分書き換え等)
    * Write[]/SeekFile[]は、Fortran WRITE statement/FSEEK intrinsic(ベンダー拡張)経由で
       Fortran I/O Library内のファイル位置ポインタを更新するが、Read[]はKernelが管理する
       ファイル位置ポインタを見ている。
 3. 本質的な問題の解決には、WRITE statement/FSEEK intronsicを使用している部分の
    改修が必要。ただし、そこまで実装した場合、OPEN/CLOSEしか使わない Fortran I/Oの
    存在意義がなくなる(open(2)/close(2)を直接呼び出す方が効率的になる)
    実装上の問題は、
    * READ statementよりも WRITE(lfno, ...)を使っている箇所の方が多い
    * File Descriptorで管理する場合は、実用的なI/O性能を達成には
       read/write buffering機構の実装が不可欠
       ただし、ネットワークコード(socket API)等との相性は良い
       特に、buffering機構を自前(SAD側)で実装した場合は、きめ細かな buffering制御が可能
       (TCP/UDPOpenを使ったネットワークアプリケーションには有利?)
    * libcの stdioを利用するためには、SAD側のファイル記述子とFILE型へのポインタの
      対応関係を管理する必要がある
    * 移植性/メモリ効率をそれなりに求めると、内部で動的なテーブルを管理する必要あり

現在予定しているバックポートは、以下の通り
(しばらく、CVS MAIN trunkが安定していなかったので凍結中)
1. PRNG(Pseudo-Random Number Generator)の実装入れ替え
   o SEED変数の廃止(変数自体は残りますが、もはや動作に影響を与えません)
   o SEED FFSコマンドの廃止(SEED変数との名前空間衝突のため機能していなかったもの)
   o Random[]関数ファミリーの実装入れかえ
      * 追加関数
         ListRandom[]           使用可能な PRNG pluginのリストを返す
         ParabolaRandom[]    区間(-1,1)の放物線分布乱数(*)
         UniformRandom[]      区間(0,1)の均一分布乱数(*)
         UniformRandom0[]    区間[0,1)の均一分布乱数(Random[]の別名)
         UniformRandom1[]    区間(0,1]の均一分布乱数(*)
         UniformRandom01[]  区間[0,1]の均一分布乱数(*)
         (*)は、PRNG pluginでのサポートは必須ではない
      * 仕様変更
         SeedRandom[]  返り値が、現在の PRNG plguin選択状態と
                               選択中の PRNG pluginの内部状態を含む
                               List型に変更される(旧仕様は、Real型)
                               ただし、SeedRandom[]の戻り値(*)を保存し、再び
                               SeedRandom[]の引数に与えた際に戻り値(*)を
                               返した状態へ復帰する点は変化なし
                               String型を引数とした PRNG pluginの選択機能を追加
                               List型を渡しての内部状態の初期化機能を追加
         FIXSEEDフラグ   保存されるのは、PRNG pluginの選択状態と保存時に
                               選択中だった PRNG pluginの内部状態だけです
         PUSHS_EED/POPS_EED/EXCGS_EED/PEEKS_EED FFSコマンド
                               保存されるのは、PRNG pluginの選択状態と保存時に
                               選択中だった PRNG pluginの内部状態だけです
  o 試験環境での試験状況
   * 旧実装と互換の疑似乱数系列の生成性能に劣化は無い
   * RAD/FLUC付きの KEKB HER Trackingでは、同一の疑似乱数列を使えば
     コードの変更前後で粒子分布は一致する(HER Trackingで通過する
     コードパス上での変更は、動作を変えていない)
   * RAD/FLUC付き Trackingにて放射減衰後の粒子分布の統計量に
      PRNG plugin依存性が有ることが分っている
      使用した粒子数(1000個)に依存した統計誤差の範囲か、疑似乱数列の
      不備によるものかは現時点では不明
      （理論的な平衡分布が分っているモデルによる検証が必要？)

2. CONVCASE/PRSVCASEフラグの実装
   o FFSコマンドラインでの大文字・小文字自動変換機能の部分的抑制や停止をサポートします
      これにより、小文字を含む element name/patternを FFSコマンドラインで使用可能になります
   o 現状、PRSVCASEは全ての FFSコマンドをサポートしていないので、CONVCASEフラグのみ
      先行してバックポートを実施するかも
      (主要コマンドDISP/FIT/FIX/FREE/COUP等はサポートしたが...)

- 関連一覧ツリー （Click ▼ to display all articles in a thread.）