--- a/paper/chapter5.tex	Thu Feb 09 04:31:53 2012 +0900
+++ b/paper/chapter5.tex	Thu Feb 09 17:59:09 2012 +0900
@@ -9,5 +9,91 @@
 \item 分割したコードを並列実行する実装
 \end{enumerate}
 
-となっている。逐次的な実行で正常な動作を確認した後、並列に実行した場合に正常な動作をしない場合がある。特にCell特有の問題としてデータ構造が DMA 転送に合っていないこと。つまり、DMA転送される際に、16アライメントに設定されていないか、データのサイズが16の倍数になっていない場合に注意しなければならない。またCeriumではコードがそれぞれ PPE 用と SPE 用が別個に存在するので、互いのコードが等価であるかもチェックしなければならない。一つのコードに統一しても良いが、別個で対応したい問題がでた時に対応してる。
+となっている。逐次的な実行で正常な動作を確認した後、並列に実行した場合に正常な動作をしない場合がある。特にCell特有の問題としてデータ構造が DMA 転送に合っていないこと。つまり、DMA転送される際に、16アライメントに設定されていないか、データのサイズが16の倍数になっていない場合に注意しなければならない。また Cerium ではコードがそれぞれ PPE 用と SPE 用が別個に存在するので、互いのコードが等価であるかもチェックしなければならない。一つのコードに統一しても良いが、別個で対応したい問題がでた時に対応してる。
 バグの例として、本来 SPE で動くべき Task が PPE で動作するなど、Task のスケジューリングでのバグ、Task の設定の際のバグなどがある。
+
+\section{Texture hash のバグ}
+
+本研究では、処理性能を著しく低下させる Texture cache のバグに直面した。Texture の cache は、hash で管理され、要求されたデータがキャッシュされてるかを調べるため hash 部分を走査するが、存在していても HIT しないというバグである。hash の走査は稼働率に含まれるため、処理性能は落ちるが、DMA 転送待ち時間や Mail 待ち時間には現れず、高い稼働率を示す。動作はエラーなどは発生せずに正常に行われ、顕著にはバグとして現れない。このバグは分散バージョン管理システム mercurial を用いて、処理性能が極端に低下した部分のバージョンを探し出し特定した。hash のバグの処理性能低下の値を示す。(\tabref{hash})
+
+\begin{table}[!htb]
+  \begin{center}
+    \caption{Texture hash バグの処理性能低下の値} \label{tab:hash}
+    \hbox to\hsize{\hfil
+      \begin{tabular}{|c|l|l|c|} \hline
+         & バグあり & バグなし & 性能\\ \hline
+         ball\_boud & 4 FPS & 30.2 FPS & 7.5倍向上 \\ \hline
+         panel & 0.2 FPS & 2.6 FPS & 13倍向上 \\ \hline
+      \end{tabular}\hfil}
+  \end{center}
+\end{table}
+
+panel においては 13倍もの性能差が現れた。
+
+\section{TaskArrayのバグ}
+本研究で実装した TaskArray は、改良前の Cerium の Task スケジューラに変更を加えるかたちで行った。スケジューリングは Scheduelr というクラスの状態遷移で記述している。以下に TaskArray 導入前の Task スケジューリング を示す。(\figref{tm_sm_state}) 
+
+\begin{itemize}
+\item SchedMail \\
+  メインスレッドからのメッセージ (Mailbox) を取得する
+\item SchedTaskList \\
+  TaskList を取得する
+\item SchedTask \\
+  TaskList から取得した Task を実行する
+\item SchedExit \\
+  SPE の実行を終了する
+\item SchedNop \\
+  何も行わない
+\end{itemize}
+
+\begin{figure}[htb]
+  \begin{center}
+    \includegraphics[scale=0.7]{images/tm_sm_state.pdf}
+    \caption{Scheduler クラスの状態遷移}
+    \label{fig:tm_sm_state}
+  \end{center}
+\end{figure}
+
+TaskArray  導入には、この　Scheduler の状態遷移図を変更した。TaskArray 導入後の状態遷移を示す。(\figref{stb-state})
+
+\begin{itemize}
+\item SchedMail \\
+メインスレッドからメッセージ(Mailbox)を取得する
+\item SchedTaskList \\
+TaskList を取得する
+\item SchedTask, SchedTaskArrayLoad\\
+受け取った TaskList の中の Task が 単一 Task か、Task Array なのかを判別する \\
+Task Array の時は Task Array をメインメモリから転送する(SchedTaskArrayLoad)
+\item SchedTaskArray, SchedTaskArrayLoad\\
+TaskList から取得した Task Array を実行する
+\item SchedExit \\
+SPE の実行を終了する
+\item SchedNop, SchedTaskArrayNop, SchedNop2Ready \\
+何も行わない。パイプラインステージの待ち合わせ用
+\end{itemize}
+
+\begin{figure}[htb]
+  \begin{center}
+    \includegraphics[scale=0.7]{./images/stb-state.pdf}
+  \end{center}
+  \caption{Schedulere クラスの状態遷移(TaskArray)}
+  \label{fig:stb-state}
+\end{figure}
+
+TaskArray 実装後には 動作中にエラーが起き、処理が正常終了しないバグが発生した。これは TaskArray のスケジューリングにおいて、パイプラインの待ち合わせができていないために起こった。デバッグには、状態遷移を洗い出し、足りないパイプラインステージを明らかにし追加した。それが SchedTaskArrayNop である。これによって TaskArray のスケジューリングが正常に動作した。
+
+\section{メモリアクセスの局所性}
+本研究の際に例題として実装した WordCount では著しく処理性能が低下する減少が起こった。WordCount 対象のファイルに対して、ランダムアクセスに近いアクセス方法を取ったのが原因である。離れたメモリへのアクセスを繰り返すと頻繁なスワップが起き、処理性能の低下につながる。Task への input data の割り振りをインクリメント的にファイルへアクセスするように変更することで、この問題を解決した。その値を測定した。(\tabref{memory-access}) wc 対象のファイルサイズは約100MBである。
+
+\begin{table}[!htb]
+  \begin{center}
+    \caption{メモリアクセスの局所性を保った改良} \label{tab:memory-access}
+    \hbox to\hsize{\hfil
+      \begin{tabular}{|c|l|l|c|} \hline
+         & 改良前 & 改良後 & 性能\\ \hline
+         実行時間 & 30s   & 2.2s & 15倍向上 \\ \hline
+         dma wait & 14\% & 8\% & 1.7倍向上 \\ \hline
+      \end{tabular}\hfil}
+  \end{center}
+\end{table}
+