|
1
|
1 \section{改善案}
|
|
|
2 \subsection{HashMap}
|
|
|
3 HashMapによる探索を排除することはRemoteに対してData Segmentを送受信する際には、マネージャーキーによる探索の操作は削ることは出来ないが、Localにおいては固有のマネージャーキーによる探索は必要ない。改善案としてマネージャーキーを指定しない場合の
|
|
|
4 \subsection{Message Pack}
|
|
|
5 AliceではData SegmentをValue型という、Message Packが提供している型で保存している。
|
|
|
6 Value というクラスは動的に型付けされたオブジェクトを表現することができるため、RubyやPythonのような動的型付けの言語のオブジェクトと同様の扱いをすることができる。
|
|
|
7 分散プログラムのアプリケーションはサーバとクライアントのVersionが同じとは限らない。サーバ側が更新され、扱うData Segmentが変更された場合であっても、旧Versionとの互換性が要求される。
|
|
|
8 Aliceは、この問題をMessage PackのValue型を用いることで互換性をもたせようとしている。
|
|
|
9
|
|
|
10 改善前のAliceではData Segmentをput、updateする段階で、Value型に変換され保存されている。そして、Code Segmentが実行される段階でasClassメソッドに変換したいClassを引数として渡すことで目的の型に戻す。
|
|
|
11 しかし、Versionの問題が起こらないLocalの場合、Data SegmentをValue型に変換し、また任意の型に戻すという操作を行う必要はなく、この操作はは単なるオーバーヘッドにしかならない。
|
|
|
12 Data Segmentの送信先がRemoteの場合に限りValue型に変換するように変更した。内部ではObject型として保存されているのでCode Segment内で処理をする際にキャストを行う必要があるが、この場合もasClassメソッドにClassを引数として渡すだけでよい。
|
|
|
13 そのため、プログラマーはData Segmentとして送られてくるオブジェクトの型を気にすることなくプログラムを記述できる。
|
|
|
14
|
|
|
15 \subsection{SEDA Archtecture }
|
|
|
16 マルチコアが主流になっている背景からAliceにはSEDA Archtectureを採用しているが、SEDAはスループット重視であり、多段のパイプラインのせいでレスポンスが遅れてしまう。Aliceは現在3段のパイプラインで構成されている。今回SEDAのStageを減らす事により、レスポンスの改善を行った。
|
|
|
17
|
|
|
18 \subsection{flip}
|
|
|
19
|
|
|
20 Data Segmentの更新におけるオーバーヘッドを減らす方法としてCeriumでも良好な結果を得ているflipを提案する。
|
|
|
21 CeriumにおけるflipはInput Data SegmentとOutput Data SegmentをswapさせるAPIである。
|
|
|
22 AliceにおいてもCeriumと同様に
|
|
|
23
|
|
|
24 Code Segmentはpeek , takeを使いData Segmentを取得する。
|
|
|
25 取得したData SegmentはInput Data Segmentと呼ばれCode Segmentの Receiverというフィールドに保存されている。
|
|
|
26 そして、Code Segment内でInput Data Segmentに対して処理が行われ、Output Data Segmentとして出力される。
|
|
|
27 実際はputまたはupdateメソッドにData Segmentなどを引数として渡すことで行うことができるが、この際に、Data Segmentのコピーが行われる。
|
|
|
28
|
|
|
29 flipではInput Data SegmentコピーしてOutput Data Segmentを作成するのではなく、Input Data SegmentそのものをOutput DSMに渡すことでData Segmentの無駄なコピーを防ぐ。
|
