ToDo:
ISO Fortran 2008追加分の実装状況
SADの内部実装で使用する数学関数的には、GCC 4.5を最低ラインにすべきか？
要素毎に適用可能な数学関数のアルゴリズムドライバ部を提供する関数
cfunに関しては特殊なdummy関数tfdummyを呼び出すケースのコード が含まれるが、複素関数が未実装なケースでir=-1を返すためのもので、適用対象は Gamma0 のみ
cmplが偽の場合、cfunの戻り値は実部のみが返される
SAD引数に対する処理
引数のうち、fun,cfun,cmpはコンパイル時に確定するので、テンプレートからコード生成すると分岐処理と関数の間接呼び出しが削減出来る。特に、funやcfunが組み込み関数の場合、機械語命令への展開・最適化が期待できる。
テンプレート展開するデメリットは、リスト処理を含んだコードのバリエーションが関数毎に生成されるので、その部分のキャッシュヒット率が低下する懸念がある。影響の大きさは、リストに対する評価頻度に依存する。itfunalocも含めた最適化を行いtable dispatchするケースでは、call/ret削減による効果が大きいと思われる
テンプレート展開自体は、開発時のSAD数学関数追加時にしか行われないので、shell script等の簡易ツールで賄える
直接SADScript評価器からtable dispatchを行うには、entryが2種類必要(SADScript標準インターフェースと再帰用)となるが、function tableを改修するのであれば、再帰的な数学関数用のタイプを用意してしまいtable dispatcher側で処理してしまうのが良いかも
cfunにtfdummyが設定されるケースも、テンプレート展開時に最適化可能で、ダミー関数の呼び出し自体を削除出来る
backendの関数テーブルを含めて、モジュールベースでの再実装を行い、dlfunalocとの統合を実施した
dlfunaloc経由で登録した関数については、itfunalocが構成した関数ポインタテーブルから直接ディスパッチ出来る
1引数と2引数に対応するtfeintf・tfeintf2相当のドライバコードを生成するジェネレータをshell scriptにて実装
出力されるのは、関数テーブルへの登録を行うinit関数を持つmoduleのFortran 2008ソース
tfeintf2と異なり、2引数のケースに付いても複素数関数のサポートを可能とし、Log[base, x]に関しても log(z2)/log(z1)の形で定義可能とした
テンプレートからのコード生成時に、埋め込む数学関数の式展開を行うので、リスト再帰・組み込み数学関数呼び出しに関しては、外部関数呼び出しオーバーヘッドが低減されているはず
また、コンパイラーが十分賢ければmodule scope内にprivate functionで実装しているlistQ/numberQをinline展開してくれるはず
後は、ひたすらテスト… テストベクター生成器と検査器を作らないと…
Log[x_Real, y:{___Real}]なケースを考えると、現行実装のように map属性付きのように振る舞う2引数数学関数の実装が欲しい
もっとも、現行実装のLog[x, y]の実体は、Log[y] / Log[x]なので Length[x]<>Length[y]のケースがうまく定義出来ていない上に、Length[x]==Length[y]の時にMapThread[Log, {x, y}]のように振る舞うのが悩ましいところ
Log[x_Real, y_List]のケースとの整合性を考えるとmap属性扱いで Map[Log[#, y]&, x]の用に振る舞うべきだが、既存のコードとの互換性はどうしよう
Listに対しては、Map的に作用する1引数数学関数として、tfefunrefから tfcmplxf@src/tfeexpr.f経由で実装しており、mode引数は Re/Im/Conjugateに対して1/2/3が割り当てられているのだが、List再帰条件がtflistq(it,ia) .or. mode .eq. 3で設定されているので、
Re[{1, 2+I, I}] -> {1, 2, 0}
Re[a[1, 2+I, I]] -> Re[a[1, (2+I), I]]
Im[{1, 2+I, I}] -> {0, 1, 1}
Im[a[1, 2+I, I]] -> Im[a[1, (2+I), I]]
Conjugate[{1, 2+I, I}] -> {1, (2-I), (-I)}
Conjugate[a[1, 2+I, I]] -> {1, (2-I), (-I)}
のような謎動作となる。 ちぐはぐな動作なので、実装バクっぽぃ
仮に、List以外のコンテナ型に対して作用させるなら
Conjugate[a[1, 2+I, I]] -> a[1, (2-I), (-I)]
を返すべきだと思うが、Complex型もコンテナ型なので Conjugate[Complex[a, b]]は、Complex[Conjugate[a], Conjugate[b]]のように評価すべきという話となり一貫性を欠く
他の数学関数と同様のframeworkで綺麗に実装出来るのだが、この変な挙動に依存したコードが存在したらどうしよう…
甲作戦にて海域クリアしました
瑞鶴改二甲/伊勢改/千代田航改二/千歳航改二/瑞鳳改/鈴谷改二(サブ)
大淀改/熊野改二(サブ)/初月改/雪風改/大井改二/北上改二
装備
進撃ルートは、OPQRS
瑞鶴改二甲/伊勢改/千代田航改二/千歳航改二/翔鶴改二甲/鈴谷改二(サブ)
大淀改/熊野改二(サブ)/初月改/大井改二/雪風改/北上改二
削りからの変更点
進撃ルートは、OPQRS
続くE4は、乙作戦かなぁ
伊400の堀をどうするかが問題だが…
| ゲージ | 戦力(1) | 輸送 | 戦力(2) |
| 燃料 | 3000 | 8000 | 9000 |
| 弾薬 | 2000 | 7000 | 9000 |
| 鋼材 | 2000 | 1000 | 2000 |
| ボーキ | 1000 | 2000 | 10000 |
| バケツ | 10 | 31 | 30 |
戦力ゲージ(2)でのボーキサイトの消費が…
調査結果のまとめ
src/CaSearch2.cから繋がっているEPICS CA callbackのまとめ
tfepicsvaluecb_とtfepicsstatcb_にて、CaMonitor@rl[chid]を検索する部分は共通化出来る 古い実装では、EPICS\$ConStatCB[chid, con-stat]とEPICS\$ValueCB[chid, value, stat]を呼び出していた様で、Packages/CaSad2c.nに痕跡が見られる
作ってみたが、devel/llvm50に合わせると、flang driver側のmodule search pathとlibrary search pathが埋め込めてないのか、-I/-Lオプションが必要になるので、もう少し作業が必要の模様
少なくとも、-I/-Lオプションをつければ ISO_C_BINDINGS moduleを使ったコードがコンパイル出来ることは確認出来た
EPICS\$ValueCB及びEPICS\$ConStatCBの旧実装に関しては、 関数プロトタイプがPackages/CaSad2.n及びPackages/CaSad2c.nで同一なので、旧実装ではどちらのフロントエンドも許容できたが、現行のバックエンド実装は直接CaMonitor@rlに格納されているハッシュ経由でCallbackによる書き込みを実装しているので、Packages/CaSad2c.nの実装は動作しない状態にある
CaOpenMonitor実装(Packages/CaSad2.n)は動作不能な状態なので、削除してもリグレッションは起こらないと考えられる
また、CaOpenMonitorで実装されたアプリケーションを動かす必要が生じた際には、CaMontor対応に書き換えるもしくはCaMonitorのwrapper libraryとして再実装することで対応できる
また、cachange & cavalueハンドラからEPICS\$ConStatCB & EPICS\$ValueCBを呼び出さなくなったのは、MAIN trunk r1282(1999/05/10 12:01:37 JST)のコミットからである
作業予定をまとめておく
カテゴリー: Admin | Emacs | EPICS | Fortran | FreeBSD | GCC | hgsubversion | IPv6 | KEKB | LHC | Lisp | LLVM | MADX | Ryzen | SAD | samba | tDiary | unix | WWW | YaSAI | お仕事 | イベント | 出張 | 宴会 | 数学 | 艦これ | 買いもの | 追記 | 雑記