|
6
|
1 -title: Code Segment と Data Segment によるプログラミング手法
|
|
|
2
|
|
11
|
3 -author: 河野 真治, 杉本 優
|
|
|
4
|
|
|
5 -abstract:
|
|
|
6
|
|
19
|
7 データをData Segment、タスクをCode Segmentという単位に分割して記述する
|
|
|
8 分散ネットフレームワーク Alice を作成した。Alice によるプログラミング例を示すと共に、
|
|
|
9 本研究室で従来使ってきた Federated Linda との比較も示し、Java による実装について考察する。
|
|
11
|
10
|
|
|
11 -abstract-e:
|
|
|
12
|
|
19
|
13 We have developed an distributed programming frame Alice, which uses Data Segment and Code Segment as programming units.
|
|
|
14 We show programming examples and comparisons with our old framework, Federated Linda. We show some consideration about
|
|
|
15 our Java implementation.
|
|
11
|
16
|
|
|
17
|
|
|
18
|
|
|
19
|
|
|
20 --分散ネットフレームワークAlice
|
|
|
21
|
|
17
|
22 Alice\cite{kono11g}は、本研究室で開発を行なっている並列タスク管理フレームワーク である。
|
|
|
23 Cell 用の Open CL に似た Task 管理フレームワークCerium\cite{kono09b,cerium-sourceforge} と、Linda\cite{linda} を相互接続した分散フレームワークである Federated Linda\cite{kono05b} の開発を通して得られた知見を生かされている。
|
|
11
|
24
|
|
13
|
25 Cerium では、Taskを小さく分割して並列実行し、データ転送はパイプライン実行により隠される。Taskには依存関係があり、その記述は煩雑になるが、実際にはデータの依存関係がそのまま Task の依存関係になることが多い。繰り返し使われるデータ構造の管理が重要であり、実行時にわかるデータ構造間の依存関係が Task を複雑にしている。
|
|
11
|
26
|
|
17
|
27 Federated Linda では、Linda サーバ内部に Meta Engine と呼ばれる Linda のタプル(データ構造)をやり取りする部分を作成した\cite{kono10d}。Meta Engine では、タプルのやり取りによって起動する call back を使うが、call back による記述が分散してしまい、可読性を落としてしまう。また、複数のタプルの待ち合わせが重要だが、その待ち合わせは single threaded な Meta Engine 内部の状態に依存する。
|
|
13
|
28
|
|
17
|
29 これらが示しているのは、並列分散実行はコードの並列実行だけでなく、データの単位が重要だということである。そこで、 AliceはData SegmentとCode Segmentという単位でデータと処理を細かく分割し、それぞれの依存関係を記述して分散プログラムを作成する。Code Segment は Continuation based C の実行単位\cite{kono00a,cbc-sourceforge} であり、その双対が Data Segment である。
|
|
11
|
30
|
|
13
|
31 Data Segment は Code Segment と分離されたデータ構造であり、オブジェクトではない。オブジェクト指向プログラミングが状態を複雑に持ち、並列実行や分散実行に向かないことは徐々に理解されてきている。一方で、状態自体は有限状態遷移機械(Finite State Machine/FSM) で記述するのが自然である。Code Segment は状態遷移記述そのものであり、その状態遷移は Data Segment の到着によってトリガーされる。
|
|
11
|
32
|
|
13
|
33 カプセル化されたデータをプロセスがやり取りするのは、DFD(Data Flow Diagram)の古典的な手法であり、それ自体は新しくはない。むしろ、メインフレーム上でのソフトウェア開発に良く使われてきた手法である。Alice では、それを再実装する。
|
|
11
|
34
|
|
19
|
35 Alice は Code Segment と Data Segment を Java と Message Pack で実装したフレームワークである。トポロジーマネージャーを持ち、Blade 上での
|
|
17
|
36 分散プログラムの実験を容易に行うことができる。また、SEDA Architecture \cite{SEDA2001} を採用しており、マルチコア上でのスループットの向上を期待している。
|
|
13
|
37
|
|
15
|
38 本論文では、Code Segment と Data Segment の Alice のAPIと、その設計方針を示し、それによって実装された水族館プログラムを示す。また、これまでの Federated
|
|
13
|
39 Linda との性能評価も行う。
|
|
|
40
|
|
|
41 % また、他のマシンとの接続トポロジーの構成の機能も有しているのでユーザーはトポロジー構成後の処理を記述するだけでよい。また、AliceはJavaで実装されている。
|
|
11
|
42
|
|
|
43 --Data Segment API
|
|
|
44
|
|
13
|
45 Data Segment は数値や文字列などのデータを構造体的に保持するが、Data Segment の相互参照が問題になる。
|
|
19
|
46 AliceではData Segmentをデータベースとして扱い、Data Segment は必ずキーを持つ。つまり、Data Segment を Key Value Store として考えることができる。
|
|
13
|
47 通常のデータベースでは隠れているが、Key 毎のキューがあり、Key 毎に順に実行される。key 毎の追加と取得は、Linda に準じた設計になっている。
|
|
|
48
|
|
31
|
49 Data Segmentを管理するのがData Segment Managerである。ノード毎に local DS manager と remote DS manager がある。local DS manager は、ノードに固有の
|
|
13
|
50 key Value Store と考えることができる。したがって Key はノード内部で unique な文字列である。
|
|
|
51
|
|
|
52 remote DS manager は他のノードのlocal DS manager の proxy である。Alice のトポロジーマネージャーが remote DS manager を自動的に構成する。つまり、remote DS manager は複数あって、それぞれ対応するノードが異なる。
|
|
|
53
|
|
|
54 Key Value Store へのアクセスはキューによって、ノード内部で逐次化される。それ以外は、すべて Java の Thread pool により並列実行される。
|
|
|
55 Code Segment が実行される時には、Data Segment はすべて手元に揃っているので、Blocking が起きることはない。逆に、Blocking が必要な場合は、
|
|
|
56 Code Segment を分割する必要がある。
|
|
|
57
|
|
11
|
58 以下が用意されているData Segment APIである。これらを用いてデータの送受信を行う。
|
|
|
59 \begin{itemize}
|
|
|
60 \item {\ttfamily void put(String key, Value val)}
|
|
|
61 \item {\ttfamily void update(String key, Value val)}
|
|
13
|
62 \item {\ttfamily void peek(Receiver receiver, String key}
|
|
|
63 \item {\ttfamily void take(Receiver receiver, String key)}
|
|
11
|
64 \end{itemize}
|
|
|
65
|
|
|
66
|
|
17
|
67 ---put
|
|
|
68
|
|
13
|
69 {\tt put} はデータを追加するための API である。Key Value Store のキューに追加される。
|
|
|
70 (図 \ref{fig:put})
|
|
11
|
71
|
|
|
72
|
|
|
73 \begin{figure}[tb]
|
|
|
74 %\begin{center}
|
|
|
75 \scalebox{0.6}{\includegraphics{images/put.pdf}}
|
|
|
76 %\end{center}
|
|
13
|
77 \caption{putはデータを追加する}
|
|
11
|
78 \label{fig:put}
|
|
|
79 \end{figure}
|
|
|
80
|
|
17
|
81 ---update
|
|
|
82
|
|
|
83 {\tt update} はデータを置き換えるための API である。キューの先頭を置き換える特急メッセージのように動作する。
|
|
13
|
84 (図 \ref{fig:update})
|
|
11
|
85
|
|
|
86
|
|
|
87 \begin{figure}[tb]
|
|
|
88 \begin{center}
|
|
|
89 \scalebox{0.6}{\includegraphics{images/update.pdf}}
|
|
|
90 \end{center}
|
|
13
|
91 \caption{updateはキューの先頭を書き換える}
|
|
11
|
92 \label{fig:update}
|
|
|
93 \end{figure}
|
|
|
94
|
|
17
|
95 ---peek
|
|
11
|
96
|
|
13
|
97 {\tt peek はデータを調べる}
|
|
11
|
98
|
|
|
99 \begin{figure}[tb]
|
|
|
100 \begin{center}
|
|
|
101 \scalebox{0.6}{\includegraphics{images/peek.pdf}}
|
|
|
102 \end{center}
|
|
13
|
103 \caption{peekはデータを調べる}
|
|
11
|
104 \label{fig:peek}
|
|
|
105 \end{figure}
|
|
|
106
|
|
13
|
107 最新のData Segment がなければ、Code Segmentの待ち合わせ(Blocking)が起きる。
|
|
11
|
108 (図 \ref{fig:no_peek})
|
|
|
109
|
|
|
110 \begin{figure}[tb]
|
|
|
111 \begin{center}
|
|
|
112 \scalebox{0.6}{\includegraphics{images/peek1.pdf}}
|
|
|
113 \end{center}
|
|
|
114 \caption{希望のデータが無いときは保留する}
|
|
|
115 \label{fig:no_peek}
|
|
|
116 \end{figure}
|
|
|
117
|
|
13
|
118 {\tt put} や {\tt update} によりData Segment の更新があれば、 {\tt peek} が直ちに実行される。つまり、
|
|
|
119 Data Segment を作成した Code Segment が active queue に移される。
|
|
11
|
120
|
|
17
|
121 ---take
|
|
|
122
|
|
13
|
123 {\tt take} もデータを読み込むための API である。
|
|
|
124 読み込まれたデータは Key Value Storeのキューから取り除かれる。これは、Linda の in() に相当する。
|
|
11
|
125 (図 \ref{fig:take})
|
|
13
|
126 必要な待ち合わせが行われる。
|
|
11
|
127
|
|
|
128 \begin{figure}[tp]
|
|
|
129 \begin{center}
|
|
|
130 \scalebox{0.6}{\includegraphics{images/take.pdf}}
|
|
|
131 \end{center}
|
|
13
|
132 \caption{take はデータを読み込む}
|
|
11
|
133 \label{fig:take}
|
|
|
134 \end{figure}
|
|
6
|
135
|
|
17
|
136 --Data Segmentの実装
|
|
11
|
137
|
|
|
138 Data Segmentのデータの表現にはMessagePackを利用している。
|
|
24
|
139 MessagePackに関してJavaにおけるデータ表現は以下の3段階あり、これらのデータ表現は制限を伴うが互いに変換可能である。
|
|
11
|
140
|
|
|
141 \begin{itemize}
|
|
|
142 \item {\ttfamily 一般的なJavaのクラスオブジェクト}
|
|
24
|
143 \item {\ttfamily MessagePack for JavaのValueオブジェクト}
|
|
11
|
144 \item {\ttfamily byte[]で表現されたバイナリ}
|
|
|
145 \end{itemize}
|
|
|
146
|
|
19
|
147 Data Segment APIでは、このMessagePack for JavaのValueオブジェクトを用いてデータが表現されている。
|
|
11
|
148 MessagePackはJavaのように静的に型付けされたオブジェクトではなく、自己記述なデータ形式である。MessagePack for JavaのValueオブジェクトはMessagePackのバイナリにシリアライズできる型のみで構成されたJavaのオブジェクトである。そのため、Valueも自己記述式のデータ形式になっている。
|
|
|
149
|
|
|
150
|
|
|
151 Valueオブジェクトは通信に関わるときには、シリアライズ・デシリアライズを高速に行うことができる。
|
|
|
152 また、ユーザーはメソッドを用いてオブジェクト内部のデータを閲覧、編集することができる。
|
|
|
153
|
|
|
154
|
|
|
155 ユーザーが一般的なクラスをIDL(Interface Definition Language)のように用いてデータを表現することができる。
|
|
|
156 この場合、クラス宣言時に@Messageというアノテーションをつける必要がある。(ソースコード \ref{fig:MessagePackTest})もちろん、MessagePackで扱うことのできるデータのみをフィールドに入れなければならない。
|
|
|
157 \begin{table}[htbp]
|
|
17
|
158 \lstinputlisting[label=fig:MessagePackTest, caption=一般的なクラスをIDLのように使用]{source/MessagePackTest.java}
|
|
11
|
159 \end{table}
|
|
|
160
|
|
|
161 --Code Segment
|
|
|
162
|
|
13
|
163 Code Segmentはタスクのことである。Code Segmentをユーザーが記述するときに、Code Segment 内で使用するData Segment の作成を記述する。
|
|
|
164 Code Segment には、Input Data Segment と Output Data Segment を作る API が存在する。
|
|
|
165
|
|
|
166 Input Data Segment で作成された Data segment は、remote か local かと、key を指定する必要がある。Input Data Segment がすべて揃わないと
|
|
|
167 Code Segment は active にならない。
|
|
|
168
|
|
19
|
169 Output Data Segment で作成された Data segment にも、remote か local かと、key を指定する必要がある。Input/Output が Code Segment 間の
|
|
13
|
170 依存関係を自動的に記述することになる。
|
|
|
171
|
|
17
|
172 \begin{table}[tb]
|
|
|
173 \lstinputlisting[label=fig:SendWidth, caption=Data Segment の例]{source/SendWidth.java}
|
|
|
174 \end{table}
|
|
13
|
175
|
|
19
|
176 {\tt ids,ods} により、Input/Output を選択して Data Segment を作成する。Output には put 時にキーを指定する(図\ref{fig:SendWidth})。Input は setKey を使ってキーを指定する。
|
|
13
|
177 もちろん、{\tt cs.width} のようにアクセスするのは Java 的には正しくない書き方であり避けるべきである。{\tt SendWidth} は Code Segment であり、
|
|
|
178 Data Segment が揃った時に、 {\tt Runnable} のように実行される。{\tt SendWidth} 内部で setKey する方が Java 的には望ましい。
|
|
|
179
|
|
|
180 どの時点でキーとノードを指定するか、どのようなAPIを用意するべきかは、まだ、議論の余地がある。
|
|
11
|
181
|
|
|
182 --Code Segmentの実行方法
|
|
|
183
|
|
13
|
184 Alice には、
|
|
|
185 Start Code Segment (ソースコード \ref{fig:StartCodeSegment})というC の main に相当するような最初に実行される Code Segment がある。
|
|
|
186 Start Code SegmentはどのData Segmentにも依存しない。つまりInput Data Segmentを持たない。
|
|
|
187 このCode Segmentをmainメソッド内でnewし、executeメソッドを呼ぶことで実行を開始させることができる。(ソースコード \ref{fig:TestLocalAlice})
|
|
11
|
188
|
|
|
189
|
|
|
190 \begin{table}[tb]
|
|
17
|
191 \lstinputlisting[label=fig:TestLocalAlice, caption=Start Code Segmentを実行させる方法]{source/TestLocalAlice.java}
|
|
11
|
192 \end{table}
|
|
|
193
|
|
|
194 --Code Segmentの記述方法
|
|
|
195
|
|
19
|
196 Code Segmentをユーザーが記述する際にはCode Segmentを継承して記述する。(ソースコード \ref{fig:CodeSegment})そのCodeSegmentはInputDataSegmentManagerとOutputDataSegmentManagerを利用することができる。
|
|
11
|
197
|
|
|
198 \begin{table}[tb]
|
|
17
|
199 \lstinputlisting[label=fig:StartCodeSegment, caption=StartCodeSegmentの例]{source/StartCodeSegment.java}
|
|
11
|
200 \end{table}
|
|
|
201
|
|
|
202 \begin{table}[tb]
|
|
17
|
203 \lstinputlisting[label=fig:CodeSegment, caption=CodeSegmentの例]{source/TestCodeSegment.java}
|
|
11
|
204 \end{table}
|
|
|
205
|
|
17
|
206 InputDataSegmentManagerはCode Segmentの{\tt ids}というフィールドを用いてアクセスする。
|
|
11
|
207 \begin{itemize}
|
|
|
208 \item {\ttfamily Receiver create(CommandType type)}
|
|
|
209 \end{itemize}
|
|
13
|
210 createでコマンドが実行された際に取得されるData Segmentが格納される受け皿を作る。引数にはCommandTypeが取られ、指定できるCommandTypeは{\tt PEEK}または{\tt TAKE}である。
|
|
11
|
211 \begin{itemize}
|
|
13
|
212 \item {\ttfamily void setKey(String managerKey, String key)}
|
|
11
|
213 \end{itemize}
|
|
|
214 setKeyメソッドにより、どこのData Segmentのあるkeyに対してpeekまたはtakeコマンドを実行させるかを指定することができる。
|
|
|
215 コマンドの結果がレスポンスとして届き次第Code Segmentは実行される。
|
|
|
216
|
|
|
217
|
|
13
|
218 OutputDataSegmentManagerはCode Segmentの{\tt ods}というフィールドを用いてアクセスする。
|
|
|
219 OutPutDataSegmentManagerは{\tt put}または{\tt update}を実行することができる。
|
|
11
|
220 \begin{itemize}
|
|
|
221 \item {\ttfamily void put(String managerKey, String key, \\ Value val)}
|
|
|
222 \item {\ttfamily void update(String managerKey, String key, Value val)}
|
|
|
223 \end{itemize}
|
|
|
224
|
|
|
225 --Topology Manager
|
|
|
226
|
|
13
|
227 Alice は複数のノードで構成され、相互に接続される。通信するノードは、URLなどにより直接指定するのではなく、
|
|
|
228 TopologyManagerによって管理される。
|
|
|
229
|
|
|
230 TopologyManager関連の通信処理はCode Segmentで実装してある。
|
|
11
|
231 TopologyManagerはトポロジーファイルを読み込み、参加を表明したクライアント(以下、Topology Node)に接続するべきクライアントのIPアドレスやポート番号、接続名を送り、トポロジーファイルに記述された通りにトポロジーを作成する。
|
|
|
232
|
|
13
|
233 Code Segment 内部で remote DS manager にアクセスする場合は、Topology Manager によって指定されたノード内部だけで有効なlabel(文字列)を使う。これにより、
|
|
|
234 特定のURLが Code Segment 内部に記述されることを防いでいる。
|
|
|
235
|
|
11
|
236 ---Topology Managerの設定ファイル
|
|
|
237
|
|
17
|
238 Topology Managerはトポロジーファイルを読み込むが、トポロジーファイル自体はDOT Language\cite{graphviz}という言語で記述される。
|
|
11
|
239 DOT Languageとはプレーンテキストを用いて、データ構造としてのグラフを表現するための、データ記述言語の一種である。このDOT Languageのグラフを利用して、クライアント間の接続を表現する。DOT Languageファイルはdotコマンドを用いて、グラフの画像ファイルを出力することができるので、記述したトポロジーが正しいことを可視化して確認することができる。
|
|
|
240
|
|
|
241 クライアント間の接続にはlabelを用いて名前が割り振られており、この接続名を用いてユーザーはData Segment Managerにアクセスすることができる。
|
|
17
|
242 前述したReceiver にsetKeyを行う際、odsでputまたはupdateする際の引数のmanagerKeyがこれにあたる (図\ref{fig:ring})。
|
|
11
|
243
|
|
|
244 \begin{table}[tb]
|
|
|
245 \lstinputlisting[label=ring, caption=3台でリングを組んだ時の例]{source/ring.dot}
|
|
|
246 \end{table}
|
|
|
247
|
|
|
248
|
|
|
249
|
|
|
250 \begin{figure}[tb]
|
|
|
251 \begin{itemize}
|
|
|
252 \item {\ttfamily dot -T png ring.dot -o ring.png}
|
|
|
253 \end{itemize}
|
|
|
254
|
|
|
255 \begin{center}
|
|
|
256 \scalebox{0.6}{\includegraphics{images/ring.pdf}}
|
|
|
257 \end{center}
|
|
|
258 \caption{dotコマンドで作成された3台で構成されたリングのグラフ}
|
|
17
|
259 \label{fig:ring}
|
|
11
|
260 \end{figure}
|
|
|
261
|
|
|
262
|
|
15
|
263 Alice の Nodeを起動する際にコマンドライン引数としてTopology ManagerのIPアドレスとポート番号を指定をする。
|
|
11
|
264 そしてmain関数内でTopologyNodeをnewを行えば良い。
|
|
|
265 TopologyNodeの第一引数は Alice デーモンの設定オブジェクト、第二引数はStart Code Segmentである。
|
|
|
266 ここで指定した、Start Code Segmentがトポロジーが完成した後実行される。
|
|
|
267
|
|
|
268
|
|
15
|
269 --水族館の例題
|
|
11
|
270
|
|
|
271 今回作成した例題は水族館である。複数のクライアントのディスプレイを複数の魚が移動していくものである。魚は画面の端まで移動すると自分の画面上からは消え、別のクライアントの画面の端から魚が出てくる。また、魚のうち一匹はクライアントが直接操作することができる。トポロジーはTopologyManagerによりツリー状に構成してある。
|
|
|
272
|
|
|
273 \begin{enumerate}
|
|
|
274 \item ユーザーが魚を操作するまたはCode Segmentにより魚の座標が更新される。
|
|
|
275 \item 画面に表示させるためのSetLocation (Code Segment)が実行され実際に魚のオブジェクトにセットされ画面に反映される。
|
|
|
276 \item Update(Code Segment)にFishPosition(魚の座標データ)が渡される。
|
|
|
277 \item Updateにlist(送信者リスト)が渡される。
|
|
|
278 \item Updateが実行され、listを元にデータが送信される。ただし、この時にFishPositionには送信元情報が付加されているので、送信元には送信されない。
|
|
|
279 \item 各clientで2 - 4が実行される。
|
|
|
280 \end{enumerate}
|
|
|
281
|
|
15
|
282 --実験
|
|
|
283
|
|
16
|
284 Ring 上のトポロジーを構築して、100周回時間を測定してみた。
|
|
|
285 マシン48台,CPU Intel(R) Xeon(R) X5650 @ 2.67GHz, 仮想コア数4,CPU キャッシュ12MB。Blade 上の仮想マシン上での測定となっている。
|
|
25
|
286 従来のFederated Lindaよいも若干遅い結果になっている。一部の異常なデータがあるが、データ量が増えると差は縮まっている。これは、コピーの影響よりも、個々の通信の手間の影響が大きいことを示している。
|
|
16
|
287
|
|
|
288 \begin{figure}[htbp]
|
|
17
|
289 \begin{center}
|
|
|
290 \includegraphics[width=70mm]{./images/ring10B.pdf}
|
|
|
291 \end{center}
|
|
|
292 \caption{10 bytes のデータを100周させたときの1周にかかる平均時間}
|
|
|
293 \label{fig:ring10B}
|
|
16
|
294 \end{figure}
|
|
15
|
295
|
|
16
|
296 \begin{figure}[htbp]
|
|
17
|
297 \begin{center}
|
|
|
298 \includegraphics[width=70mm]{./images/ring10KB.pdf}
|
|
|
299 \end{center}
|
|
|
300 \caption{10 Kbytes のデータを100周させたときの1周にかかる平均時間}
|
|
|
301 \label{fig:ring10KB}
|
|
16
|
302 \end{figure}
|
|
|
303
|
|
|
304 \begin{figure}[htbp]
|
|
17
|
305 \begin{center}
|
|
|
306 \includegraphics[width=70mm]{./images/ring100KB.pdf}
|
|
|
307 \end{center}
|
|
|
308 \caption{100 Kbytes のデータを100周させたときの1周にかかる平均時間}
|
|
|
309 \label{fig:ring100KB}
|
|
16
|
310 \end{figure}
|
|
|
311
|
|
|
312
|
|
15
|
313
|
|
|
314 --評価と考察
|
|
|
315
|
|
|
316 今回の実装は、Java により Code Segment と Data Segment に必要な API を洗い出すためのものであった。この実装でもいくつかの問題が明らかになっている。
|
|
|
317
|
|
19
|
318 {\bf API } Class を継承したり、Input Data segment や Output Data segment の作成に factory object を使うのは Java を使う際の技術的なものであり、Alice のAPI自体は Java に固有である必要はない。むしろ、Java の Object 指向な記述が全体を煩雑にしている部分がある。{\tt update} は、Data Segmentの競合的な更新に使われるべきだと思われる。
|
|
11
|
319
|
|
17
|
320 {\bf SEDA } Federated Linad に比べて、通信のレスポンスが遅い原因の一つはSEDA architectureのせいだと思われる。SEDA はスループット重視の実装であり、多段のパイプラインのせいでレスポンスは遅れてしまう。実際、スレッドプールを使用しないほうが、Ring の結果は良くなる(図\ref{fig:ringnothread})。
|
|
15
|
321
|
|
16
|
322 \begin{figure}[htbp]
|
|
17
|
323 \begin{center}
|
|
|
324 \includegraphics[width=70mm]{./images/ring_notp_10b.pdf}
|
|
|
325 \end{center}
|
|
|
326 \caption{Code Segment のスレッドプールを使用せずに、 10 bytes のデータを回した時の実験結果}
|
|
|
327 \label{fig:ringnothread}
|
|
16
|
328 \end{figure}
|
|
15
|
329
|
|
16
|
330 レスポンスが要求される部分のスケジューラーを別にするなどの工夫が必要だと思われる。それを記述そのものに入れるのが良いかどうかには議論の余地がある。
|
|
|
331
|
|
|
332
|
|
17
|
333 {\bf MessagePack } 今回の実装では単純な Message の転送の場合でも MessagePack の decode/encode が必要になる。これは単純に overhead になる。encode/decode 抜きに直接処理できる方が望ましい。また、Data Segment の一部の修正に Data Segment を再構成するのは望ましくない。Cerium では Input Data Segment と Output Data Segment を swap する API があり、若干状況は複雑になるが良好な結果を得ている。この辺りは、ユーザから見えない最適化として実装する方が望ましいが、なんらかの制御方法も必要だと思われる。
|
|
15
|
334
|
|
17
|
335 {\bf Key } 本実装では Data Segment 相互の参照は Key 経由となる。Linda や分散実装では、それは妥当だが、並列実装では、すべての Data Segment を
|
|
16
|
336 Key Value Store
|
|
|
337 に格納するのは性能的な問題を引き起こす。一方で、分散記述と並列記述がかけ離れてしまうのも好ましくない。現状は Key Value Store は Java の Concurrent
|
|
|
338 Hash map を用いているが、今のベンチマークでは、そこがネックになっているわけではないと思われる。本来は、このKey Value Store は持続性を持つべきだと
|
|
|
339 思われるが今回は実装していない。
|
|
15
|
340
|
|
17
|
341 {\bf Java }
|
|
16
|
342 Ring の実験での異常なデータは、Java の分散プログラミングでは良く現れる。一つは Java のGCの影響だと思われる。Alice では、すべての Data Segment
|
|
|
343 は Key Value に格納され、実行時の Data Segment は Code Segment が active な時のみにメモリ上にある。この最大値を見積ることは、Active Task の
|
|
|
344 量を見積もれば良い。したがって、Alice には Garbage Collection は必要ない。一方で、Key Value Store 上のデータは決して Garbage Collection の
|
|
|
345 対象にならない。しかし、それは Garbage Collector には負荷をかけてしまう。つまり、Alice 自体は Java で実装するのには向いていない。
|
|
15
|
346
|
|
17
|
347 {\bf 拡張性}
|
|
16
|
348 分散アプリケーションでのプロトコルは常に変更されるものであり、Alice もそれに対応する必要がある。Alice 上で走るプロトコルは、
|
|
|
349 Data Segment と Code Segment によって決まる。Key とトポロージーマネージャーをプロトコル毎に別に用意すれば、複数のプロトコルを
|
|
|
350 同時に走らせることが可能である。プロトコル間の互換性はいろいろあり得る。Data Segment と Code Segment の結びつきは弱いので、
|
|
|
351 Data Segment に余計な値がある場合、あるいは、値が足りない場合に適切な値を設定することにより、古い Code Segment を変更せずに
|
|
|
352 プロトコルを拡張できると考えている。実際、水族館の例題で、2次元と3次元版を両立させることは容易である。
|
|
|
353
|
|
11
|
354
|
|
|
355 --まとめと今後の課題
|
|
|
356
|
|
17
|
357 今回、Code Segment と Data Segment による並列分散フレームワークの Java による実装を示した。前の設計\cite{kono11g}と異なる部分は、
|
|
31
|
358 実装でしか得られない知見である。
|
|
11
|
359
|
|
16
|
360 Java による実装は、ラピッドプロトタイピングとしては適切であり、例題の記述と基本性能の確認に向いている。一方で、Java が Aliceの
|
|
|
361 実装に不向きであることもわかってきた。
|
|
|
362 Code Segment / Data Segment を見たコンパイラ的アプローチ、あるいは実行時最適化などが有効であると思われる。
|
|
17
|
363 あるいは、CbC\cite{cbc-sourceforge} による実装が効果的だと考えている。
|
|
16
|
364
|
|
|
365 特に、今回はノード内の並列実行や GPGPU による並列実行などは考慮していないので、将来的には、それを含めた実装をしていきたい。
|
|
|
366
|
|
|
367
|
|
|
368
|
|
|
369
|
