--- a/compare.tex	Mon Jul 14 13:30:06 2008 +0900
+++ b/compare.tex	Mon Jul 14 16:28:37 2008 +0900
@@ -36,16 +36,28 @@
 \tabref{tab:hyoka3} より、SPE の台数を増やす事によって、
 実行速度が向上しているのがわかる。
 しかし、正しく台数効果が出ているとは言えない。
-原因として
 
-\begin{enumerate}
-\item アルゴリズムのミス
-\item 効率的なデータ及びコード分割がされていない
-\item 全てのタスクを SPE 上で実行していない \label{list:d3}
-\end{enumerate}
+%%原因として
+%%
+%%\begin{enumerate}
+%%\item アルゴリズムのミス
+%%\item 効率的なデータ及びコード分割がされていない
+%%\item 全てのタスクを SPE 上で実行していない \label{list:d3}
+%%\end{enumerate}
+%%
+%%等といった事が考えられる。
+%%ここでは、原因(\ref{list:d3})について考察する。
 
-等といった事が考えられる。
-ここでは、原因(\ref{list:d3})について考察する。
+今回の実験環境で、SPE 上で実行している Rendering タスクの処理は、
+PPE から取得した Span から、実際に描画する RGB 値を計算して FrameBuffer に
+書き込む事である。将来的にシェーディングやアルファブレンディングを
+実装する事になるが、現在はそこまで多くの計算をしているわけではない。
+主に PPE からの大量の Span データの取得、
+そして FrameBuffer へのメモリコピーとなる。
+従って、今回の実験結果は、Rendering タスク内のメモリネックが
+影響しているものと考えられる。
+この事に関し、描画領域を広げ、メモリコピーの量を増やす事で
+検証していく必要がある。
 
 
 %その原因として、TaskManager の実装の不備があげられる。
@@ -59,9 +71,9 @@
 %全てのタスクを SPE 上で実行できるようになれば、
 %実行速度はさらに向上すると考えられる。
 
+また、Rendering のタスクだけを SPE 上で実行しているのは、
 SPE の 256KB という容量では、現在の Cerium の全てのタスクを
-SPE 上に乗せる事は出来ないため、\tabref{tab:hyoka1} のように
-Rendering のタスクだけを SPE 上で実行している。
+SPE 上に乗せる事が出来ないからである。
 これを回避するために、SPE プログラムの on-demand load の実装が必要となる。
 実装の方法として、以下のような手段が考えられる。