Orz日記 by Akio Morita

Sharedリソースを管理するLUNバッファにC_PTR型もしくはpointer型を格納可能にする(語長非依存のアドレス表現の導入)
mapallocによる割り当てをmmap_utils経由に切り替える
- unmapを考えると pointer型に長さを保持させる方が良い？
Sharedによるdump/restoreコードの共有バッファ参照をrlistから独立した格納バッファ参照に切り替える
- union的な動作を前提とするなら、FortranよりもCで書く方が良いか？

2018-11-21 [長年日記]

内部実装を確認したところ、参照動作時にpack表現内部のreference位置とheap/stack系のreference位置が同一視できることを前提にコーディングされている

アドレス空間を分離する為に再実装するのであれば、pack表現も見直した方が良い模様

多分、stdint.h + union + switchで Cで書き直す方が移植性的には素直

オブジェクトキャッシュの実装は、SAD stack or Heapは考えておくべき (最悪、リストの長さの合計スケールのstackが必要) dump側で辞書領域の大きさを書き出しておくと、 restore側は辞書のrealllocationが不要になる

少なくとも型フィールドが余っているので、リストの種別毎にデータ構造を分離する(List of Reals, List of Non-Real, Generic List)することで、特化リストの格納効率を上げられる(iad/iavが不要になる)

また、混合リスト時の表現もReal型フラグベクトルを導入すると圧縮出来る

uint64_tにするか uint32_t 2語でデザインするかは一考

unit64_tだとイテレータループが単純になるが、32bit環境だと型が存在しない可能性がある

長いリストの場合、64要素当たり 64 * 16bytes -> 8 + 64 * 8bytes 短いリストの場合、2要素の時 2 * 16bytes -> 8 + 1 * 8bytes (1要素の場合は、自明なリスト構造)

recall動作時に型判定・再帰動作を含むループを回しているので、動作効率面での劣化は、フラグベクトルの条件判定分のみと推定される

TFRBUFへmmap pointer/sizeテーブルを追加して、生のmmap/munmapを使ったOpenSharedを再実装した

残作業

とにかくテスト
- mmap失敗とサイズオーバーフロー系はテスト済み
~~=汎リストのパッキング~~=(実装完了)
- 現行実装は、Listのみで任意の頭部を扱えない
- Real型は頭部になれないので、頭部格納領域のフォーマットは制限される点に注意
- 実装済みのListコンテナに条件分岐追加で対応するのが簡単と思われる
~~=パッキングコンテナのレイアウト情報~~=(構造体定義にコメント他を追加/可変長表現が複数つながる場合は、後続をコメント化)
- 特に汎リストコンテナが面倒(頭部オブジェクト含め、格納要素が可変長)
辞書実装
- String/リストコンテナの再参照時の表現圧縮用
- 辞書格納用の構造体及びAPIの実装
- エントリ毎に必要な情報は、type/reference index

辞書を使ったpack表現の圧縮を実装した

他のプロセスとの干渉等が原因で、辞書の拡張に一時的に失敗した後に、別のオブジェクト挿入時に拡張に成功するとその間のオブジェクトの登録状態が異なる状態(非決定論的)になるので、拡張失敗時には辞書サイズを凍結するように変更した

さらに、メモリ使用量とテーブル検索時間を制限する為に、辞書サイズに上限を設定した

一応、問題なく動くところまで来た

古いFortranコードに、対象を制限しない形でSAVE属性を宣言しているものがある

一部のコードは、明かに状態を保持していないので、削除すべきか？

これが原因で、特定のコンパイラ系でエラーになるっぽぃ

エラーメッセージは、COMMON属性とSAVE属性を同時に設定出来ないというもので、内容から考えて、環境依存最適化のレベルの問題では無いと思われる

問題が出ているgfortranは、開発途上の古いsnapshotなので、特定revisionでのregressionの可能性が高い、さもなくばRed Hatが変なパッチを当てている？

危険なケース

安全性を保証するには…

locked read/write
- inter-process lockの実装コストが高い
バスアライメントレベルでの領域分割(write/write干渉の排除)
- write combinedまで考慮するとキャッシュラインレベルで分離すべき？
- 配列添字の飛び越し走査だと保証するのは難しい
atomic read/write
- ISO C/C++的には実装できるが、ISO Fortran内の命令生成は保証が無い？

結局、ISO Fortran的には、master-worker間の通信に限定して、worker毎に個別の共有メモリを割り当てるのが無難という結論に…

implicit noneの標準化
- inc/TFMACRO.inc依存コード 104ファイル/123関数
- inc/TMACRO.inc依存コード 28ファイル/33関数
itfmalocp相当物の実装
- process local割り当てなら、割付配列が使える
  - ISO Fortran 2003から、割付配列が仮引数経由で渡せる
  - 定義スコープからの離脱時に自動的に解体される
- mmap割り当てなら、配列ポインタが使える
  - 使用後にmunmap_arrayする必要がある
- ポリモーフィックな定義をするならmodule手続き化する必要がある
  - module名候補
    - list_utils - 含意が広すぎる
    - list_math_utils - 方向性がずれている
    - list2array_utils - 実態ベースの名称(matrix/vector双方をサポートするので、arrayの方が良い)
- complex版itfcmalocには、mapalloc化するmap引数は存在しない(italocで割り当てが行われる)
- 再実装により明示的なmapalloc/mapfreeの呼び出しを廃止出来る
italoc/tfreeペアの書き換え
- 割付配列相当の使い方の部分が多いので、割付配列に書き直す
- 型・形状の明確化及び、可搬性の確保
tffscalc内のワークエリア割り当てコードの修正
- 並列リージョン間の共有を想定しているコードがあるので、適切に割り当てる必要がある(mmap_private_array/mmap_shared_arrayの使い分け)
  - 2018/04/13の日記を参照