\chapter{デバック}
並列プログラムの特徴として、デバッグが難しいことが挙げられる。実行が非決定的 (同じ状態で実行しても結果が異なる) な場合があり、バグの状態を再現することが難しい。また、個々の Core 上のデータを調べる必要があり、デバッガが複数の Core を取り扱えることが必須である。Cell の場合、動作している複数 の SPE の一つに対してgdb で breakpoint を掛ければ、PPE や他の SPE も同時にストップするが、それら全ての CPU を手動で管理するのは時間がかかる。また、PPE と SPE ではメモリ空間が違うため、SPE から直接 PPE のデータを見ることができない。
Cerium での開発工程は、

\begin{enumerate}
\item C によるシーケンシャルな実装
\item 並列実行を考慮したデータ構造を持つ実装
\item コードを分割し、シーケンシャルに実行する実装
\item 分割したコードを並列実行する実装
\end{enumerate}

となっている。逐次的な実行で正常な動作を確認した後、並列に実行した場合に正常な動作をしない場合がある。特に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}