\subsection{実験環境}+今回はSEDAが非力なマシーンでは動作しないことを考慮して、メニコア環境で実験を行った。\hline+\end{tabular}+\end{center}+\end{table}+++\subsection{実験概要}+今回それぞれの改善案の効果を調査するために以下の3つの実験を行った。Segmentを10000回実行される時間を計測する。+SEDAを使用した場合と、しない場合の2つの比較を行い、その効果を測定する。Segmentを10000回追加するのにかかる時間を計測する。+flipコマンドを使用して追加する場合と、putコマンドを使用して追加する場合の2つの比較を行う。sortにより、100万の要素をもつ配列のSortにかかる時間を計測する。分割数は10個で行った。+今回改善を行う前と後を比較し今回のどの程度、速度改善が行われたかを調べる。+\end{center}+\end{table}+SEDAを使わずにコマンドを処理する方が約3.7倍差が見られた。+\end{center}+\end{table}++flipを使う方が若干ではあるが速度改善が見られる。+\end{center}+\end{table}++\subsection{考察}+実験の結果より今回の改善により、約10\%程Aliceの速度改善を行うことができた。この差のほとんどがSEDAから来ていると推測される。+LinkedBlockingQueueを使ったSEDAの実装は、コストが高くレスポンスを求めるには不向きであることがわかった。file+\section{まとめ}+今回の改善はAliceのLocalにおける並列処理の速度を向上させるためのものであった。その結果約10%程処理速を改善することができた。+しかし、まだまだ十分な速度であるとは言いがたい。Segment生成からの実行されるまでに、オーバーヘッドがあるとの実験結果が出ている。Segment側のオーバーヘッドを取り除くことで、更なる速度改善が見込まれる。Segmentの更新する際にはまだSEDAを使用している。今回の実験によりRemoteにおいてもSEDAを使用しないことでレスポンスの向上が見込まれるので、実験を行い確認したい。Lindaと同等の速度を目指している。++また、Aliceが抱える問題はAPIのシンタックス的な問題や拡張性の問題、永続性の問題などが現在判明している。これらの問題を解決し、Aliceが信頼性とスケーラビリティーを持つように改良を行なっていく必要がある。いうクラスは動的に型付けされたオブジェクトを表現することができるため、RubyやPythonのような動的型付けの言語のオブジェクトと同様の扱いをすることができる。分散プログラムのアプリケーションはサーバとクライアントのVersionが同じとは限らない。Segmentが変更された場合であっても、旧Versionとの互換性が要求される。PackのValue型を用いることで互換性をもたせようとしている。SegmentをValue型に変換し、また任意の型に戻すという操作を行う必要はなく、この操作はは単なるオーバーヘッドにしかならない。SegmentをValue型に変換し、また任意の型に戻すという操作を行う必要はなく、この操作は単なるオーバーヘッドにしかならない。Segmentの送信先がRemoteの場合に限りValue型に変換を行われるように設計をすれば良い。内部ではObject型として保存する。Segmentを処理をする際にキャストを行う必要があるが、asClassメソッドでキャストを行うようにすることで、RemoteとLocalの記述を同じにすることができる。Segmentとして送られてくるオブジェクトの型を気にすることなくプログラムを記述できる。Packのオーバーヘッドを減らすことができる。Segmentをセットするステージの三段のパイプラインで構成されている。Segmentをセットするステージはpeekとtakeの時のみ実行される。-今回、二段目と三段目を一つにまとめることによってステージを減らすことによりオーバーヘッドを減らす。Segmentをセットするステージの三段のパイプラインで構成されている。これを全て同一のステージにまとめ、Localの環境下においてSEDAを使用せずに処理を行うように変更する。Segmentの更新におけるオーバーヘッドを減らす方法としてCeriumでも良好な結果を得ているflipを提案する。SegmentをswapさせるAPIである。SegmentをswapさせるAPIである。\end{table}--AliceにおいてもCeriumと同様にflipを実装する。Segmentの無駄なコピーを防ぐ。Segmentである。書き換えならばswapを行い、2つの領域を入れ替えることで無駄なmemcopyを防ぐことができる。+AliceにおいてもCeriumと同様にflipを実装することで、無駄なデータのコピーを防ぐ。Lindaに実行速度で及ばない。sortの例題も期待した結果を得ることができなかった。そこで、実行速度の改善を行うために、オーバーヘッドになっている原因の洗い出しを行った。その結果以下のような原因が見つかっている。Segmentのキーによる探索などHashMapを多用している。この検索かかる時間が多少ではあるが、オーバーヘッドになっているものと考えられる。Segmentのキーによる探索などHashMapを多用している。この探索を行う際に排他制御を行うためかかる時間が多少ではあるが、オーバーヘッドになっていると予想される。PackによりValue型へと変換が行われている。Segment内でValue型から変換元の型への変換が行われる。PackによりValue型へと変換が行われている。Segment内でValue型から変換元の型への変換を行う必要がある。この作業もオーバーヘッドになる。配列の要素数が増えると変換に時間が多くかかるので、この作業はできるだけ避けたい。Architectureが挙げられる。マルチコアスレッドを用いて大量の接続を管理し、受け取ったデータを処理ごとに分けられたステージと呼ばれるスレッドに投げ、処理が終わると次のステージにデータを伝搬させて行く処理方式である。SEDAはスループット重視の実装であり、レスポンス重視ではない。逆に多段のパイプラインのせいでレスポンスは遅れてしまう。非力なマシーンではSEDAの効果を得られず、スレッドを切り替える等の時間もオーバーヘッドになってしまう。Architectureが挙げられる。マルチコアスレッドを用いて大量の接続を管理し、受け取ったデータを処理ごとに分けられたステージと呼ばれるスレッドに投げ、処理が終わると次のステージにデータを伝搬させて行く処理方式である。SEDAはスループット重視の実装であり、レスポンス重視ではない。逆に多段のパイプラインのせいでレスポンスは遅れてしまう。データを次のステージへ伝搬させていく際にLinkedBlockingQueueを使用しているがenqueue時、dequeue時にロックを掛けるのでオーバーヘッドの原因と思われる。LinkedBlockingQueueは片方向の連結リストをベースとしたQueue実装である。dequeueの操作時の排他制御にはそれぞれ別々のロックオブジェクトが使用されている。そのため、enqueueとdequeueが重なってもロック解除待ちは発生しないが、そのかわりに連結リストのNodeオブジェクトの生成操作などが発生してしまうため、enqueue操作の処理コストが高い。+さらに、非力なマシーンではSEDAの効果を得られず、スレッドを切り替えが頻繁に起こりオーバーヘッドになってしまう。Segmentが毎回新しく作成される。変更された値のコピーが行われる。\maketitle。