|
1
|
1 \section{現状のAliceの問題点}
|
|
|
2 Aliceを用いた例題を通して、様々な問題点が明らかになった。
|
|
|
3 APIのシンタックス的問題、永続性の問題、実行速度の問題など解決すべき問題は多々ある。
|
|
|
4 特に実行速度の問題では分散環境をテストする例題として作成されたRingの例題(トポロジーを円状に構成し、メッセージが1周する時間を計測する)ではシングルスレッドで実装されているFederated Lindaに実行速度で及ばない。また、並列環境をテストする例題として作成したbitonic sortの例題も期待した結果を得ることができなかった。そこで、実行速度の改善を行うために、オーバーヘッドになっている原因の洗い出しを行った。その結果以下のような原因が見つかっている。
|
|
|
5
|
|
|
6 {\bf HashMapの多用 }
|
|
|
7 AliceではData Segment Managerのマネージャーキーによる探索、Data Segmentのキーによる探索などHashMapを多用している。この検索かかる時間が多少ではあるが、オーバーヘッドになっているものと考えられる。
|
|
|
8
|
|
|
9
|
|
|
10 {\bf Message Packの convert / unconvert }
|
|
|
11 現在の実装ではputまたはupdateを呼ぶとMessage PackによりValue型へと変換が行われている。また、Code Segment内でValue型から変換元の型への変換が行われる。
|
|
|
12 この作業もオーバーヘッドになる。また、配列の要素数が増えると変換に時間が多くかかるので、この作業はできるだけ避けたい。
|
|
|
13
|
|
|
14 {\bf SEDA Architecture }
|
|
|
15 Federated Lindaに比べて、通信のレスポンスが遅い原因にはSEDA Architectureが挙げられる。SEDA とはマルチコアスレッドを用いて大量の接続を管理し、受け取ったデータを処理ごとに分けられたステージと呼ばれるスレッドに投げ、処理が終わると次のステージにデータを伝搬させて行く処理方式である。しかし、SEDAはスループット重視の実装であり、レスポンス重視ではない。逆に多段のパイプラインのせいでレスポンスは遅れてしまう。また、非力なマシーンではSEDAの効果を得られず、スレッドを切り替える等の時間もオーバーヘッドになってしまう。
|
|
|
16
|
|
|
17 {\bf Data Segmentの再構成 }
|
|
|
18 取得されたData Segmentに変更を行いKey Value Storeへ追加する際に、Output Data Segmentが毎回新しく作成される。そして、変更された値のコピーが行われる。
|
|
|
19 このコピーに時間がかかっているのではないかと推測される。この無駄なコピーを無くすことで速度改善ができるのではないかと思われる。 |
