# HG changeset patch
# User e095732 <e095732@ie.u-ryukyu.ac.jp>
# Date 1356009356 -32400
# Node ID 83a9162efd5edc4a923f79b13d027f7bc2596e14
# Parent  8370b9afbf33ba97ff96081e79a1a4c34a9de1c7
add image file

diff -r 8370b9afbf33 -r 83a9162efd5e presen/images/aquarium.png
Binary file presen/images/aquarium.png has changed
diff -r 8370b9afbf33 -r 83a9162efd5e presen/index.html
--- a/presen/index.html	Thu Dec 20 16:29:59 2012 +0900
+++ b/presen/index.html	Thu Dec 20 22:15:56 2012 +0900
@@ -283,10 +283,17 @@
       <article>
 	<h3>水族館の例題</h3>
 	<ul>
+	  複数の魚が複数のディスプレイ上を移動していく。<br>
+	  魚のうち一匹はクライアントが直接操作することができる。<br>
+	  トポロジーはツリー状に構成してある。
 	</ul>
       </article>
 
       <article>
+	<img src="images/aquarium.png" width=550>
+      </article>
+
+      <article>
 	<h3>性能比較 - 実験概要</h3>
 	<ul>
 	  AliceとFederated Linda で性能比較を行った。<br>
@@ -381,8 +388,8 @@
       </article>
       
       <article>
+	<h3>実験結果</h3>
 	<ul>
-	  <h3>実験結果</h3>
 	  <strong>100kbyte</strong>
 	  <img src="images/ring100KB.png" width=650><br>
 	  データ量が増えると差が縮まっている。これはここの通信の手間の影響が大きことを示している。
@@ -402,12 +409,12 @@
       
       <article>
 	<h3>評価と考察</h3>
-	<ul>
 	  <p><strong>SEDA</strong></p>
-	  <li>Federated Lindaに比べ遅い原因の一つはSEDA architectureのせいと思われる</li>
-	  <li>SEDAはスループット重視の実装であり、多段パイプラインのせいでレスポンスが遅れてしまう</li>
-	  
-	</ul>
+	  <ul>
+	    <li>Federated Lindaに比べ遅い原因の一つはSEDA architectureのせいと思われる</li>
+	    <li>SEDAはスループット重視の実装であり、多段パイプラインのせいでレスポンスが遅れてしまう</li>
+	    
+	  </ul>
       </article>
       
       <article>
@@ -421,8 +428,8 @@
 
       <article>
 	<h3>評価と考察</h3>
+	<p><strong>MessagePack</strong></p>
 	<ul>
-	  <p><strong>MessagePack</strong></p>
 	  <li>今回の実装では単純なMessageの転送時にもMessagePackのdecode/encodeをしているが、overheadになってしまうため、decode/encode抜きに直接操作できるほうが望ましい</li>
 	  <li>Data Segmentの一部の修正をするたびにData Segmentが再構成されているがこれは望ましくない</li>
 	  <li>AliceもCeriumのようにInput Data SegmentとOutput Data SegmentをswapするAPIがあるとよいと思われる</li>
@@ -430,6 +437,49 @@
       </article>
 
 
+      <article>
+	<h3>評価と考察</h3>
+	<p><strong>Key</strong></p>
+	<ul>
+	  <li>分散実装においてはData Segmentの相互参照はKey経由が打倒であるが、並列実装では全てのData SegmentをKey Value Storeに格納するのは、性能的な問題を引き起こす</li>
+	  <li>分散記述と並列記述を分ければ解決するが、2つの記述がかけ離れるのは好ましくない</li>
+	  <li>本来Key Value storeは持続性を持たせる必要がある</li>
+	</ul>
+      </article>
+
+      <article>
+	<h3>評価と考察</h3>
+	<p><strong>Java</strong></p>
+	<ul>
+	  <li>Data SegmentはCode Segmentがactiveの時のみメモリ上にあり、その最大値はActive Taskの量を見積もればよいのでAliceにGarbage Collectionの機能は必要ない</li>
+	 <li>key Value Store 上のデータは決してGarbage Collectionの対象にはならないが、それがGarbage Collectionに負荷をかける結果となるためAliceとJavaの相性は悪い</li>
+	</ul>
+      </article>
+
+      <article>
+	<h3>評価と考察</h3>
+	<p><strong>拡張性</strong></p>
+	<ul>
+	  <li>分散アプリケーションのプロトコルは常に変更されるため、Aliceもそれに対応する必要がある</li>
+	  <li>Keyとトポロジーマネージャーをプロトコル毎に別に用意すれば複数のプロトコルを同時に走らせることが可能</li>
+	  <li>Data SegmentとCode Segmentの結びつきは弱いため、Data Segmentに余計な値がある場合、値が足りない場合に適切な値を設定することで古いCode Segmentを変更するとこなしにプロトコルを拡張できる</li>
+	</ul>
+      </article>
+
+      <article>
+	<h3>まとめと課題</h3>
+	<ul>
+	 <p>今回Code SegmentとData Segmentによる並列分散フレームワークのJavaによる実装を示した。実装でしかえられない知見を得ることができた。</p>
+	 <p>今回Javaによる実装を行ったがJavaがAliceの実装に不向きであるということもわかった。</p>
+	 <p>
+	  <li>Code Segment/Data Segmentを見たコンパイラ的アプローチ</li>
+	  <li>実行時最適化</li>
+	  <li>CbCによる実装</li>
+	  などが有効、効果的だと思われる。</p>
+	 <p>今回はノード内の並列実行やGPGPUによる並列実行などは考慮していない。将来的にそれを含め実装をしていきたい。</p>
+	</ul>
+      </article>
+
 </Section>
 </body>
 </html>