Mercurial > hg > Papers > 2015 > sugi-master

comparison paper/chapter4.tex @ 8:f948d683c29a

Find changesets by keywords (author, files, the commit message), revision number or hash, or revset expression.
modify chapter4 and add source
author sugi
date Wed, 07 Jan 2015 19:01:15 +0900
parents a9a8f37945d4
children 7e1112025b3a
comparison
equal deleted inserted replaced
7:a9a8f37945d4 8:f948d683c29a
1 \chapter{改善点} \label{chapter:chapter4} 1 \chapter{改善点} \label{chapter:chapter4}
2 %この章では、分散フレームワークAliceに対して行った改善点を示す。 2 %この章では、分散フレームワークAliceに対して行った改善点を示す。
3 \section{並列環境における改善} 3 \section{並列環境における改善}
4 分散フレームワークAliceは、並列環境に対応したフレームワークである。しかし、並列環境に対応していることを確認するためにbitonic sortを作成、計測したところ、Data Segmentの更新のオーバーヘッドにより、期待した効果を得ることができなかった。その際に、行った改善点を示す。 4 分散フレームワークAliceは、並列環境にも対応したフレームワークである。しかし、並列環境に対応していることを確認するためにbitonic sortを作成、計測したところ、Data Segmentの更新のオーバーヘッドにより、期待した効果を得ることができなかった。その際に、行った改善点を示す。
5 \subsection{SEDA Architecture} 5 \subsection{SEDA Architecture}
6 SEDA Architectureとはマルチコアスレッドを用いて大量の接続を管理し、受け取ったデータを処理ごとに分けられたステージと呼ばれるスレッドに投げ、処理が終わると次のステージにデータを伝搬させていく処理方式である。 6 SEDA Architectureとはマルチコアスレッドを用いて大量の接続を管理し、受け取ったデータを処理ごとに分けられたステージと呼ばれるスレッドに投げ、処理が終わると次のステージにデータを伝搬させていく処理方式である。
7 スループット重視のでありレスポンスは多段のパイプラインのせいで遅れてしまう。 7 スループット重視のでありレスポンスは多段のパイプラインのせいで遅れてしまう。
8 Aliceに置いてSEDAを実装するにあたり、データを次のステージにへ伝搬する際、LinkedBlockingQueueを使用している。LinkedBlockingQueueは片方向の連結リストをベースとしたQueue実装である。enqueue / dequeueの操作時の排他制御にはそれぞれ別々のロックオブジェクトが使用されている。そのため、enqueueとdequeueが重なってもロック解除待ちは発生しないが、そのかわりに連結リストのNodeオブジェクトの生成操作などが発生してしまうため、enqueue操作の処理コストが高い。 8 Aliceに置いてSEDAを実装するにあたり、データを次のステージにへ伝搬する際、LinkedBlockingQueueを使用している。LinkedBlockingQueueは片方向の連結リストをベースとしたQueue実装である。enqueue / dequeueの操作時の排他制御にはそれぞれ別々のロックオブジェクトが使用されている。そのため、enqueueとdequeueが重なってもロック解除待ちは発生しないが、そのかわりに連結リストのNodeオブジェクトの生成操作などが発生してしまうため、enqueue操作の処理コストが高い。
9 さらに、非力なマシーンではSEDAの効果を得られず、スレッドを切り替えが頻繁に起こりオーバーヘッドになってしまう。 9 さらに、非力なマシーンではSEDAの効果を得られず、スレッドを切り替えが頻繁に起こりオーバーヘッドになってしまう。
10 10
11 以上の理由からLocal Data Segmentに対して操作をする際はSEDAを使用せず処理を行なうように変更した。 11 以上の理由からLocal Data Segmentに対して操作をする際はSEDAを使用せず処理を行なうように変更した。
12 変更前は、Local Data Segmentに対して操作する場合、putやpeekに沿ったCommandを作成するステージ(Code Segmentが実行されているスレッド)、受け取ったCommandを処理するステージ、Code SegmentにData Segmentをセットするステージ（peekとtakeの場合）の2段または3段のパイプラインで構成されていた。これらを1つのステージにまとめて処理することで、並列環境における性能を向上させた。 12 変更前は、Local Data Segmentに対して操作する場合、putやpeekに沿ったCommandを作成するステージ(Code Segmentが実行されているスレッド)、受け取ったCommandを処理するステージ、Code SegmentにData Segmentをセットするステージ（peekとtakeの場合）の2段または3段のパイプラインで構成されていた。これらを1つのステージにまとめて処理することで、並列環境における性能を向上させた。
13
13 \subsection{Data Segment の再構成（flip 機能の追加）} 14 \subsection{Data Segment の再構成（flip 機能の追加）}
15 Data Segment APIのput、updateを呼ぶとOutput Data Segmentが毎回新しく作成される。そして出力するデータのコピーが行われる。しかし、Input Data Segmentとして取得したデータに変更を行い、Output Data Segmentとして出力する場合、コピーを行なうのは無駄である。そこで、このコピーを減らすことで速度改善を行った。
16
17 このコピーを無くし、Data Segmentの更新におけるオーバーヘッドを減らす方法としてCeriumでも良好な結果を得ているflipを用いた。Ceriumにおけるflipは、Input Data SegmentとOutput Data SegmentをswapさせるAPIである。(ソースコード \ref{src:flipCerium})
18
19 \begin{table}[html]
20 \lstinputlisting[label=src:flipCerium, caption=Ceriumにおけるflip]{source/flip.cc}
21 \end{table}
22
23
24 \begin{table}[html]
25 \lstinputlisting[label=src:flipAlice, caption=Aliceにおけるflip]{source/flip.java}
26 \end{table}
27
28 \begin{table}[html]
29 \lstinputlisting[label=src:exampleFlip,caption=flipの使用例]{source/Sort.java}
30 \end{table}
31
32 Ceriumの場合、Output Data SegmentはTaskが実行された段階ですでに用意されている。そのためデータをOutput Data Segmentに書き込む前にflipを呼ぶ。
33 Aliceの場合、putまたはupdateを呼んだ段階でOutput Data Segmentが作られるため、ソースコード\ref{src:exampleFlip}のようにInput Data SegmentであるReceiverをflipメソッドに引数として渡すことで、無駄なコピーを減らす。
34
14 \subsection{Data Segmentのデータ表現の追加} 35 \subsection{Data Segmentのデータ表現の追加}
15 変更前はData Segmentのデータ表現はMessage Pack for JaveのValueオブジェクトのみを用いて表現していた。 36 変更前はData Segmentのデータ表現はMessage Pack for JaveのValueオブジェクトのみを用いて表現していた。
16 Valueオブジェクトとは、Message Packのバイナリにシリアライズできる型のみで構成されたJavaのオブジェクトであり、自己記述形式のデータ形式となっている。そのため、ArrayValueを用いることにより、ユーザーはデータを後からつなげたりすることも可能である。 37 Valueオブジェクトとは、Message Packのバイナリにシリアライズできる型のみで構成されたJavaのオブジェクトであり、自己記述形式のデータ形式となっている。そのため、ArrayValueを用いることにより、ユーザーはデータを後からつなげたりすることも可能である。
17 38
18 このValueオブジェクトの特徴の1つに、通信に関わる際のシリアライズ・デシリアライズを高速に行えることがある。 39 このValueオブジェクトの特徴の1つに、通信に関わる際のシリアライズ・デシリアライズを高速に行えることがある。
20 41
21 しかし、Local Data Segmentに対する通信においては逆効果である。データをLocal Data Segmentに対してputするたびにValue型に変換するコストがかかる。データをpeekする際にもValue型から元の型に変換するというコストがかかる。 42 しかし、Local Data Segmentに対する通信においては逆効果である。データをLocal Data Segmentに対してputするたびにValue型に変換するコストがかかる。データをpeekする際にもValue型から元の型に変換するというコストがかかる。
22 43
23 この問題を解決するために、一般的なJavaのクラスオブジェクトでもデータ表現を可能にした。Local Data Segmentに対してputする場合は、Valueオブジェクトに変換せず一般的なJavaのクラスオブジェクトのままで、Remote Data Segmentに対してputする場合にのみValueに変換する。これにより、無駄な変換コストを抑えられるようになった。 44 この問題を解決するために、一般的なJavaのクラスオブジェクトでもデータ表現を可能にした。Local Data Segmentに対してputする場合は、Valueオブジェクトに変換せず一般的なJavaのクラスオブジェクトのままで、Remote Data Segmentに対してputする場合にのみValueに変換する。これにより、無駄な変換コストを抑えられるようになった。
24 \section{分散環境における改善} 45 \section{分散環境における改善}
46 AliceVNCを実装するにあたり、Aliceの送受信部分に問題が発見された。ここでは発見された問題の解決方法を示す。
47 \subsection{Data Segmentのデータ表現の変更}
48 AliceVNCは、\ref {section:AliceVNC}で説明したように、当研究室で開発しているTreeVNCを分散フレームワークAliceを用いて実装した画面共有システムである。
49
50 Topology Nodeは受け取った画面データを描画すると同時に、Remote Data Segmentに送信する。Remote Data Segmentに送信する際にはMessage PackによりValue型に変換し、その後シリアライズ化（byteArrayで表現されたバイナリに変換）される。Topology Nodeは受信するとデシリアライズしValue型に変換した後putされる。
51
52 このValue型への変換が問題である。受け取ったデータを自分の子ノードに対して送信する際には、デシリアライズしValue型に変換する必要はない。シリアライズ状態のまま子ノードに送信すれば、Value型に変換するオーバーヘッドとValue型をシリアライズするオーバーヘッドを無くすことができる。そこで、Remoteからputされたデータ表現をValue型からbyteArrayで表現されたbinaryに変更した。
25 \subsection{Protocolの再設計} 53 \subsection{Protocolの再設計}