Papers/2012/sugi-prosym: Paper/alice.ind comparison

comparison Paper/alice.ind @ 16:2fb744749f74

fix

author	Shinji KONO <kono@ie.u-ryukyu.ac.jp>
date	Mon, 26 Nov 2012 17:44:11 +0900
parents	3f4b3f26419a
children	fa9827772216

comparison

equal deleted inserted replaced

-:3f4b3f26419a
+:2fb744749f74
 \item 各clientで2 - 4が実行される。
 \end{enumerate}
 --実験
-Ring
+Ring 上のトポロジーを構築して、100周回時間を測定してみた。
+マシン48台,CPU Intel(R) Xeon(R) X5650 @ 2.67GHz, 仮想コア数4,CPU キャッシュ12MB。Blade 上の仮想マシン上での測定となっている。
-水族館
+従来のFederated Lindaよいも若干遅い結果になっている。一部の異常なデータがあるが、データ量が増えると差は縮まっている。これは、コピーの影響よりも、個々の通信の手間の影響が大きいことを示している。00
+\begin{figure}[htbp]
+\begin{center}
+\includegraphics[width=110mm]{./images/ring10B.pdf}
+\end{center}
+\caption{10 bytes のデータを100周させたときの1周にかかる平均時間}
+\label{fig:ring10B}
+\end{figure}
+\begin{figure}[htbp]
+\begin{center}
+\includegraphics[width=110mm]{./images/ring10KB.pdf}
+\end{center}
+\caption{10 Kbytes のデータを100周させたときの1周にかかる平均時間}
+\label{fig:ring10KB}
+\end{figure}
+\begin{figure}[htbp]
+\begin{center}
+\includegraphics[width=110mm]{./images/ring100KB.pdf}
+\end{center}
+\caption{100 Kbytes のデータを100周させたときの1周にかかる平均時間}
+\label{fig:ring100KB}
+\end{figure}
 --評価と考察
 今回の実装は、Java により Code Segment と Data Segment に必要な API を洗い出すためのものであった。この実装でもいくつかの問題が明らかになっている。
 {\bf API } Class を継承したり、Input Datasegment や Output Datasegment の作成に factory object を使うのは Java を使う際の技術的なものであり、Alice のAPI自体は Java に固有である必要はない。むしろ、Java の Object 指向な記述が全体を煩雑にしている部分がある。{\tt update} は、Data Segmentの競合的な更新に使われるべきだと思われる。
-\{bf SEDA }
+\{bf SEDA } Federated Linad に比べて、通信のレスポンスが遅い原因の一つはSEDA architectureのせいだと思われる。SEDA はスループット重視の実装であり、多段のパイプラインのせいでレスポンスは遅れてしまう。実際、スレッドプールを使用しないほうが、Ring の結果は良くなる(図\ref{fig:ringnothread})。
-Federated Linad に比べて、通信のレスポンスが遅い原因の一つはSEDA architectureのせいだと思われる。SEDA はスループット重視の実装であり、多段のパイプラインのせいでレスポンスは遅れてしまう。レスポンスが要求される部分のスケジューラーを別にするなどの工夫が必要だと思われる。それを記述そのものに入れるのが良いかどうかには議論の余地がある。
+\begin{figure}[htbp]
+\begin{center}
-\{bf MessagePack }
+\includegraphics[width=110mm]{./images/ring_notp_10b.pdf}
+\end{center}
-今回の実装では単純な Message の転送の場合でも MessagePack の decode/encode が必要になる。これは単純に overhead になる。encode/decode 抜きに直接処理できる方が望ましい。また、Data Segment の一部の修正に
+\caption{Code Segment のスレッドプールを使用せずに、 10 bytes のデータを回した時の実験結果}
+\label{fig:ringnothread}
-\{bf Key }
+\end{figure}
+レスポンスが要求される部分のスケジューラーを別にするなどの工夫が必要だと思われる。それを記述そのものに入れるのが良いかどうかには議論の余地がある。
+\{bf MessagePack } 今回の実装では単純な Message の転送の場合でも MessagePack の decode/encode が必要になる。これは単純に overhead になる。encode/decode 抜きに直接処理できる方が望ましい。また、Data Segment の一部の修正に Data Segment を再構成するのは望ましくない。Cerium では Input Data Segment  と Output Data Segment を swap する API があり、若干状況は複雑になるが良好な結果を得ている。この辺りは、ユーザから見えない最適化として実装する方が望ましいが、なんらかの制御方法も必要だと思われる。
+\{bf Key } 本実装では Data Segment 相互の参照は Key 経由となる。Linda や分散実装では、それは妥当だが、並列実装では、すべての Data Segment を
+Key Value Store
+に格納するのは性能的な問題を引き起こす。一方で、分散記述と並列記述がかけ離れてしまうのも好ましくない。現状は Key Value Store は Java の Concurrent
+Hash map を用いているが、今のベンチマークでは、そこがネックになっているわけではないと思われる。本来は、このKey Value Store は持続性を持つべきだと
+思われるが今回は実装していない。
 \{bf Java }
+Ring の実験での異常なデータは、Java の分散プログラミングでは良く現れる。一つは Java のGCの影響だと思われる。Alice では、すべての Data Segment
-拡張性
+は Key Value に格納され、実行時の Data Segment は Code Segment が active な時のみにメモリ上にある。この最大値を見積ることは、Active Task の
+量を見積もれば良い。したがって、Alice には Garbage Collection は必要ない。一方で、Key Value Store 上のデータは決して Garbage Collection の
+対象にならない。しかし、それは Garbage Collector には負荷をかけてしまう。つまり、Alice 自体は Java で実装するのには向いていない。
+\{bf 拡張性}
+分散アプリケーションでのプロトコルは常に変更されるものであり、Alice もそれに対応する必要がある。Alice 上で走るプロトコルは、
+Data Segment と Code Segment によって決まる。Key とトポロージーマネージャーをプロトコル毎に別に用意すれば、複数のプロトコルを
+同時に走らせることが可能である。プロトコル間の互換性はいろいろあり得る。Data Segment と Code Segment の結びつきは弱いので、
+Data Segment に余計な値がある場合、あるいは、値が足りない場合に適切な値を設定することにより、古い Code Segment を変更せずに
+プロトコルを拡張できると考えている。実際、水族館の例題で、2次元と3次元版を両立させることは容易である。
 --まとめと今後の課題
+今回、Code Segment と Data Segment による並列分散フレームワークの Java による実装を示した。前の設計\cite{}と異なる部分は、
+実装でしか得られない治験である。
+Java による実装は、ラピッドプロトタイピングとしては適切であり、例題の記述と基本性能の確認に向いている。一方で、Java が Aliceの
+実装に不向きであることもわかってきた。
+Code Segment / Data Segment を見たコンパイラ的アプローチ、あるいは実行時最適化などが有効であると思われる。
+あるいは、CbC\cite{} による実装が効果的だと考えている。
+特に、今回はノード内の並列実行や GPGPU による並列実行などは考慮していないので、将来的には、それを含めた実装をしていきたい。

Mercurial > hg > Papers > 2012 > sugi-prosym

comparison Paper/alice.ind @ 16:2fb744749f74