|
1
|
1 \section{改善案}
|
|
|
2 \subsection{HashMap}
|
|
2
|
3 HashMapによる探索を排除することは複数のRemote DSMがあるので難しい。しかし、Localに対してはDSMが固有であるので、マネージャーキーによる探索は必要ない。
|
|
|
4 従ってLocal 専用の Data Segment APIを提供することによりHashMapによる探索の回数を減らすことができる。
|
|
|
5
|
|
1
|
6 \subsection{Message Pack}
|
|
|
7 AliceではData SegmentをValue型という、Message Packが提供している型で保存している。
|
|
|
8 Value というクラスは動的に型付けされたオブジェクトを表現することができるため、RubyやPythonのような動的型付けの言語のオブジェクトと同様の扱いをすることができる。
|
|
|
9 分散プログラムのアプリケーションはサーバとクライアントのVersionが同じとは限らない。サーバ側が更新され、扱うData Segmentが変更された場合であっても、旧Versionとの互換性が要求される。
|
|
|
10 Aliceは、この問題をMessage PackのValue型を用いることで互換性をもたせようとしている。
|
|
2
|
11 しかし、Versionの問題が起こらないLocalの場合、Data SegmentをValue型に変換し、また任意の型に戻すという操作を行う必要はなく、この操作はは単なるオーバーヘッドにしかならない。
|
|
1
|
12
|
|
2
|
13 以上のことからData Segmentの送信先がRemoteの場合に限りValue型に変換を行われるように設計をすれば良い。内部ではObject型として保存する。この場合、Code Segment内でData Segmentを処理をする際にキャストを行う必要があるが、asClassメソッドでキャストを行うようにすることで、RemoteとLocalの記述を同じにすることができる。
|
|
1
|
14 そのため、プログラマーはData Segmentとして送られてくるオブジェクトの型を気にすることなくプログラムを記述できる。
|
|
|
15
|
|
|
16 \subsection{SEDA Archtecture }
|
|
2
|
17 Localにおいてはput や peek に沿ったCommand を作成するステージ(Code Segmentが実行されているスレッド)、受け取ったCommandを処理するステージ、Code SegmentにData Segmentをセットするステージの三段のパイプラインで構成されている。最後のCode SegmentにData Segmentをセットするステージはpeekとtakeの時のみ実行される。
|
|
|
18 今回、二段目と三段目を一つにまとめることによってステージを減らすことによりオーバーヘッドを減らす。
|
|
1
|
19
|
|
2
|
20 \subsection{Data Segmentの再構成}
|
|
1
|
21 Data Segmentの更新におけるオーバーヘッドを減らす方法としてCeriumでも良好な結果を得ているflipを提案する。
|
|
|
22 CeriumにおけるflipはInput Data SegmentとOutput Data SegmentをswapさせるAPIである。
|
|
|
23
|
|
2
|
24 \begin{table}[tb]
|
|
|
25 \lstinputlisting[label=fig:CodeSegment, caption=Ceriumにおけるflipの例]{source/Cerium_flip.cc}
|
|
|
26 \end{table}
|
|
1
|
27
|
|
2
|
28 AliceにおいてもCeriumと同様にflipを実装する。
|
|
|
29 AliceにおけるflipはInput Data SegmentコピーしてOutput Data Segmentを作成するのではなく、Input Data SegmentそのものをOutput DSMに渡すことでData Segmentの無駄なコピーを防ぐ。
|
|
|
30
|
