|
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型を用いることで互換性をもたせようとしている。
|
|
3
|
11 しかし、Versionの問題が起こらないLocalの場合、Data SegmentをValue型に変換し、また任意の型に戻すという操作を行う必要はなく、この操作は単なるオーバーヘッドにしかならない。
|
|
1
|
12
|
|
3
|
13 従って、Data Segmentの送信先がRemoteであるならばValue型に変換を行い、Localであるならば変換しないという具合に改善をすれば、LocalにおけるMessage Packのオーバーヘッドを減らすことができる。
|
|
|
14
|
|
1
|
15
|
|
|
16 \subsection{SEDA Archtecture }
|
|
3
|
17 Localにおいてはput や peek に沿ったCommand を作成するステージ(Code Segmentが実行されているスレッド)、受け取ったCommandを処理するステージ、Code SegmentにData Segmentをセットするステージの三段のパイプラインで構成されている。これを全て同一のステージにまとめ、Localの環境下においてSEDAを使用せずに処理を行うように変更する。
|
|
2
|
18 \subsection{Data Segmentの再構成}
|
|
1
|
19 Data Segmentの更新におけるオーバーヘッドを減らす方法としてCeriumでも良好な結果を得ているflipを提案する。
|
|
3
|
20 CeriumにおけるflipはInput Data SegmentとOutput Data SegmentをswapさせるAPIである。(ソースコード \ref{fig:flip})
|
|
1
|
21
|
|
2
|
22 \begin{table}[tb]
|
|
3
|
23 \lstinputlisting[label=fig:flip, caption=Ceriumにおけるflip]{source/Cerium_flip.cc}
|
|
2
|
24 \end{table}
|
|
3
|
25 {\tt readbuf}がInput Data Segment、{\tt writebuf}がOutput Data Segmentである。
|
|
|
26 Output がinput の書き換えならばswapを行い、2つの領域を入れ替えることで無駄なmemcopyを防ぐことができる。
|
|
|
27 AliceにおいてもCeriumと同様にflipを実装することで、無駄なデータのコピーを防ぐ。
|
