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