1/14日メモ

プログラミング 卒論

今日の先生からの指摘は特に気になったのでメモ

結局DMIの処理と一緒じゃないの?

  • DMIでDMI_group_read()をINVALIDATEキャッシュで実行して、実際に必要な値をDMI_read()で取ってくることを考える。
  • こうすると、最初にまとめてローカルに持ってくる＝通信のaggregationがうまく行っていることになる。
  • 一方で俺の処理系の場合は二分探索とかしているせいで遅い。
  • なぜ同じことをするのに時間が全然違うのか?

DMIのポインタから実際の値を持ってくる方法

  • 先頭16bitで何回目のmmapかを調べる
  • ページサイズを用いてどのページのアドレスか調べる
  • そのページのページテーブルを読む。NULLなら通信を起こして持ってくる。
  • オフセットを使って結果を返す。

まとめ：なんで俺の処理系は遅いのか

簡単に言うと上でページサイズが1byteであって、テーブルを作っていないようなものだから。
DMIはページサイズ(mmapごとに可変)というある程度荒い粒度で管理しているためテーブルを作ってウハウハという訳だ。

今後の方針

DMIべったり作戦

もしもDMIべったり作戦が使えればこれを使う。ただ、大きいページサイズの割に読み込む領域が小さいとかなると通信・メモリの無駄遣いがひどくて遅くなることがありえる。例えば、一つのページ中1ヶ所しか読まないような疎行列とか。対角成分以外ほぼ読まない(1ページ中に1つも読まないことが多い)とかなら気にならないかもしれない。これは要テスト。

インデックスの集約

DMI_group_init()に渡すときのように、連続した領域を集約して、サイズを別の配列にしてしまう。ブロック状になっている場合は効果があると考えられる。ただ、すごくバラバラに読む場合は効果が低い。

4分探索にする

定数時間の削減が図れるかもしれない。美味しいかどうかは分からない。

テーブルの実装

ある程度適当なサイズで区切ってしまってテーブルを実装する。ただ、車輪の再発明感が否めないのでしたくはない。まあ、上で言った4分探索の4を大きくするようなもんなんだけどね。

今後の行動

  • とりあえず実装完成させる。
    • 右辺値・左辺値判断をパーサに実装する。
  • INVALIDATEキャッシュによる行列積を書いてみて(簡単)、性能を見る。DMI_read()のcall時間が遅すぎる気もするけど、あ、First Iterだけをこれにすればいいのか!
  • インデックスの集約の実装
  • 先生に言われているHPFとかの通信のaggregationを調べる。有用な情報が得られるかも。
  • 関係ないけどmdの実装しないとヤバくね。