Mercurial > hg > Papers > 2018 > nozomi-master

comparison paper/nozomi-master.tex @ 173:52a43c1336d9

Find changesets by keywords (author, files, the commit message), revision number or hash, or revset expression.
merge
author Nozomi Teruya <e125769@ie.u-ryukyu.ac.jp>
date Mon, 05 Feb 2018 14:59:41 +0900
parents 34383a096d75 d28d691e33ed
children f0e9cc7d13f9
comparison
equal deleted inserted replaced
169:34383a096d75 173:52a43c1336d9
153 153
154 Aliceは、タスクをCode Segment、データをData Segmentという単位で記述し、Code SegmentはインプットとなるData Segmentが全て揃うと並列に実行される。 154 Aliceは、タスクをCode Segment、データをData Segmentという単位で記述し、Code SegmentはインプットとなるData Segmentが全て揃うと並列に実行される。
155 Data Segmentは対になるkeyが存在し、Data Segment Managerというノードごとに存在する独自のデータベースによって管理されている。 155 Data Segmentは対になるkeyが存在し、Data Segment Managerというノードごとに存在する独自のデータベースによって管理されている。
156 各ノードにはラベル付きのプロキシであるRemote Data Segment Managerを立て、ラベルとkeyを指定してデータをtake/putするプロトコルとなっている。 156 各ノードにはラベル付きのプロキシであるRemote Data Segment Managerを立て、ラベルとkeyを指定してデータをtake/putするプロトコルとなっている。
157 157
158 158 %Topologymanagerもここにかく？
159 \newpage 159
160 160 \newpage
161 %問題といったら参考文献が必要,わかりづらいとハッキリ書かない
161 記述の面において、Akkaではメッセージが集中した場合にそれを処理するパターンマッチが増えてしまう問題や、複数のインプットを待ち合わせる際に記述が煩雑になる問題があった。 162 記述の面において、Akkaではメッセージが集中した場合にそれを処理するパターンマッチが増えてしまう問題や、複数のインプットを待ち合わせる際に記述が煩雑になる問題があった。
162 しかしAliceはインプットを明確に記述でき、複数のインプットを持てる。 163 しかしAliceはインプットを明確に記述でき、複数のインプットを持てる。
163 164
164 プロトコルの設計方針において、AkkaやHazelcastは分散通信の複雜さを抽象度を高めることで隠す方針であるため、ロケーション透過性が高く、プログラマからは処理の流れを把握しにくくなっていた。 165 プロトコルの設計方針において、AkkaやHazelcastは分散通信の複雜さを抽象度を高めることで隠す方針であるため、ロケーション透過性が高く、プログラマからは処理の流れを把握しにくくなっていた。
165 一方でAliceは分散計算のチューニングをメタ計算として行う。これによりメタ計算から分離された処理の流れを明確にすることができる。 166 一方でAliceは分散計算のチューニングをメタ計算として行う。これによりメタ計算から分離された処理の流れを明確にすることができる。
889 もしDGがなければ、リモートから来たコマンドもローカルの場合と同様にLocalDGMのwaitListに入る。 890 もしDGがなければ、リモートから来たコマンドもローカルの場合と同様にLocalDGMのwaitListに入る。
890 891
891 REPLYを受け取るとRemoteDGMはwaitListに入っていたコマンドを解決する。 892 REPLYを受け取るとRemoteDGMはwaitListに入っていたコマンドを解決する。
892 893
893 \chapter{再設計への考察} 894 \chapter{再設計への考察}
894 895 InputDGの指定において、CGにDGを宣言するというのは、DGをそのままflipできるようにするためであった。
895 \chapter{まとめ} 896 逆に言えばそれ以外でDataGear型でプログラマが利用することは少ない。
896 897 そのため、DGをアノテーションから生成し完全にメタレイヤーに移すことで、DGの宣言のないより分かりやすい記述が可能だと考える。
897 %設計しなおしでNAT越えなどの機能拡張が期待できる 898 flipする場合は、keyを指定するだけにしたほうが良い。
898 %スケーラブルになった 899 また、put/flipする際にDGM名を直接指定する書き方も、まだひと目でアウトプットしている部分が分かるようなシンタックスではないため、改善の余地がある。
899 %テストしやすくなった 900
900 %また、アノテーションを用いたことでよりユーザーフレンドリーなAPIを実現した。 901 DGMは一種のデータベースであると述べたが、現状のDGMはデータベースに必要なトランザクションを持っていない。
901 %型を気にしなくて良くなった 902 当研究室で開発しているJungleデータベースはトランザクションを持っており、更にマージ可能な差分管理システムを持っている。
902 %信頼性を高めた 903 そのためJungleデータベースとの統合することで、DGMへの操作を信頼性高くできるようにしたほうが望ましい。
903 904
904 \chapter{今後の課題} 905 現在はノードごとにDGMとDGのkeyが与えられているが、URLのような大域で使えるkeyを用意することで
905 \section{TopologyManagerの実装} 906
907 \chapter{結論}
908 \section{まとめ}
909 本研究では、まず分散フレームワークに必要な要件を洗い出し、Akka、Hazelcastと比較しながら分散フレームワークAliceが分散性を意識して記述できる特徴をもつことを示した。
910 また、Aliceの持つCode Segment/Data Segmentの計算モデルや記述方法、Meta Computationについてを説明し、AliceでNAT越えを実現するための手法を示した。
911 さらに現状のAliceの問題点として、NAT越えをするために必要なLocal Data Gear Managerの複数立ち上げができないこと、分散プログラムのテストがしづらいこと、APIシンタックスの分離により信頼性が損なわれていること、型の整合性がとれていないことなどを示し、再設計の必要性を述べた。
912 そして、分散フレームワークChristieの設計を示し、Code Gear ManagerというCode Gear/Data Gearの管理機構を挟むことでNAT越えやテスト解決することを述べた。
913 また、アノテーションを用いることでシンタックスの分離問題を解決し、さらに型整合のとれたより信頼性の高い記述が可能になったことを示した。
914 そして、これら実装したChristieに対しても更に改善すべき点を考察した。
915
916 \section{今後の課題}
917 \subsection*{TopologyManagerの実装}
906 Aliceと同じく、静的・動的なトポロジー管理のできるTopologyManagerの実装が必要である。 918 Aliceと同じく、静的・動的なトポロジー管理のできるTopologyManagerの実装が必要である。
907 Christieでは複数のLocalDSMが立ち上げ可能なため、TopologyManagerでのNAT超えも実装し実用性があるかを検証する 919 Christieでは複数のLocalDSMが立ち上げ可能なため、TopologyManagerでのNAT超えも実装し実用性があるかを検証する
908 また、通信の信頼性を保証するために、TopologyManagerがダウンした際に新たなTopologyManagerを立ち上げる機能もあるべきだと考える。 920 また、通信の信頼性を保証するために、TopologyManagerがダウンした際に新たなTopologyManagerを立ち上げるMeta Computationも必要だと考える。
909 921
910 922
911 \section{実用性の検証} 923 \subsection*{実用性の検証}
912 本論文ではChristieの設計と基本実装までを行ったが、それがどれほどの分散性能を持っているのかはまだ計測していない。 924 本論文ではChristieの設計と基本実装までを行ったが、それがどれほどの分散性能を持っているのかはまだ計測していない。
913 CG/DGのプログラミングモデルなどの基本的にはAliceと同じであるが、アノテーションの処理がどれほどのオーバーヘッドに繋がっているか現時点では不明である。 925 CG/DGのプログラミングモデルなどの基本的にはAliceと同じであるが、アノテーションの処理がどれほどのオーバーヘッドに繋がっているか現時点では不明である。
914 そのため、Aliceと同等の速度性能を持っているか、コードの量や複雑度は抑えられているかなどを分散処理の例題を用いて測定する必要がある。 926 そのため、Aliceと同等の速度性能を持っているか、コードの量や複雑度は抑えられているかなどを分散処理の例題を用いて測定する必要がある。
915 927
916 \section{GearsOSへの移行} 928 \subsection*{GearsOSへの移行}
917 GearsOSはまだ開発途中であったため、本論文の作成時点ではChristieのような分散機能を実装することが叶わなかった。 929 GearsOSはまだ開発途中であったため、本論文の作成時点ではChristieのような分散機能を実装することが叶わなかった。
918 GearsOSではモデル検査機構akasha\cite{}があるため、待ちに入っているkeyのputし忘れなどをコンパイルの段階で見つけることができる。 930 GearsOSではモデル検査機構akasha\cite{}があるため、待ちに入っているkeyのputし忘れなどをコンパイルの段階で見つけることができる。
919 GearsOS上で分散プログラミングができればより信頼性の高いプログラミングが期待できるため、将来的にはChristieをGearsOSの分散機構として取り込みたい。 931 GearsOS上で分散プログラミングができればより信頼性の高いプログラミングが期待できるため、将来的にはChristieをGearsOSの分散機構として取り込みたい。
920 932
921 GearsOSにChristieを移行するには、GearsOSにJavaのアノテーションに相当するMeta Computationを実装する必要がある。 933 GearsOSにChristieを移行するには、GearsOSにJavaのアノテーションに相当するMeta Computationを実装する必要がある。