Binary file paper/ARC195OS117-32.pdf has changed

--- a/paper/ARC195OS117-32.tex	Tue Mar 15 18:56:51 2011 +0900
+++ b/paper/ARC195OS117-32.tex	Wed Mar 16 17:54:57 2011 +0900
@@ -314,6 +314,7 @@
 SPEの待ち時間が発生することへ対処しないといけない。
 その対処の一つとしてそれにパイプライン化は有効である。
 
+
 \subsection{SPEでのキャッシュ効果}
 
 \subsubsection{テクスチャの管理}
@@ -386,12 +387,29 @@
 PrintTaskはWordCountTaskを待ちTaskと設定し、WordCountがすべて終わらないと、
 実行されない。
 
-このWordCountTaskにデータを渡す際には、メインメモリへのアクセスが局所性を保ちながら
-処理されるようにした方が良い。WC対象のデータを各SPEがバラバラな領域から取得する場合と
-ある程度まとまった領域から取得するようにした場合とで比較をした。取得のバラつきはTaskArray
-のTaskの設定である程度操作できる。TaskArrayのサイズは64, Taskのinputデータの大きさは16kbyte,
-wc対象のデータの大きさは約135MB。
+%このWordCountTaskにデータを渡す際には、メインメモリへのアクセスが局所性を保ちながら
+%処理されるようにした方が良い。WC対象のデータを各SPEがバラバラな領域から取得する場合と
+%ある程度まとまった領域から取得するようにした場合とで比較をした。取得のバラつきはTaskArray
+%のTaskの設定である程度操作できる。
+
+
+WordCountにはTaskArrayを用いた。TaskArrayを用いる場合に注意すべき点がある。
+TaskArrayを使わず、Taskを用いる場合、Taskは生成された順番にそって各SPEに割り振られていく。
+ファイルをmmapし、その領域を上から順番にTaskに設定しているので各SPEは同時に近くのメモリ領域
+にアクセスすることになる。TaskArrayを用いた場合に生成された順にTaskArrayに設定するのはまずい。
+TaskArray一つは、一つのSPEのみで実行され、分割されない。
+TaskArrayに連続した領域を指すTaskばかりを格納すると、
+それによって、一つのSPEが連続領域を順番にアクセスして行く形になる。別のSPEは、16kB x TaskArrayのサイズ分離れた
+領域からメモリアクセスを開始するので、
+離れたメモリ領域を各コアが同時にアクセスすることになる。
+なので、先に複数のTaskArrayを用意し、Taskが生成された順番にそって各TaskArrayに割り振るように改良した。
+
+TaskArrayのサイズは64, Taskのinputデータの大きさは16KB,
+wc対象のデータの大きさは約135MB。Taskの数は約8000。
 dma wait は処理全体にかかった時間のdma転送待ちの割合。
+改良前は各SPEが同時に離れた領域(各SPE間は 16KB x 64 離れる)にアクセスする。
+改良後は近くのメモリ領域(各SPE間はだいたい16KB 離れる)にアクセスする。
+
 
 \begin{table}[!htb]
   \begin{center}
@@ -406,10 +424,12 @@
   \end{center}
 \end{table}
 
-メモリアクセスの局所性を保った場合に処理性能の向上が見られた。ページングや、スワッピングを
+
+メモリアクセスの局所性を保った場合に処理性能の向上が見られた（\tabref{tab:memory-access}）。ページングや、スワッピングを
 抑えることができたと考えられる。それに伴ってdma wait 時間も減少し、SPEの待ち時間が処理性能
 の向上に繋がっていると考える。
 
+
 \subsection{OpenGLとの比較}
 
 OpenGL (Open Graphics Library) とは、Silicon Graphics 社が開発した、3D グラフィックス
@@ -499,7 +519,6 @@
 
 このことから、恒常的に並列度を維持する必要があることが分かる。
 
-
 \section{今後の課題}
 
 \subsection{依存関係の設定}
@@ -525,6 +544,27 @@
 現在は描画を行う Task にMemorySegment という形でデータの入れ替えのためのデータ構造
 を用いている。
 
+\subsubsection{Taskの粒度}
+Taskの粒度が大きい場合に、SPE間で、Taskの消化時間にバラつきがでやすい。
+それは特にバリア同期をしている場合に、待ち時間へ直結する。Taskを粒度が
+小さい場合にはPPEとの通信時間がかさむ事になる。粒度が大きい場合には、
+他のTaskを投入することで解決できる。その方法がパイプラインである。
+実は粒度が小さい場合にも次のTaskを予想してdma転送などパイプライン化し
+転送待ち時間を解消する対処法がある。
+しかし、CeriumのようにPPEへのMail通知で
+同期ポイントがある場合にパイプライン化では対処できなかった。
+そこで今回、MailQueue,TaskArrayなど同期するタイミングの回数を
+減らすことで、ある程度の改良を行った。TaskArrayはTaskの粒度が
+大きくなる影響があり、また巨大なデータを分割アクセスする場合には
+メモリアクセスの局所性に注意しながらのTaskの配分が必要である。
+キャッシュ、Task配分によるメモリアクセス、
+Taskスケジューリングのパイプライン化による必要なデータの先読み
+など共通している項目はメモリの扱いに関係するものである。このさまざまな
+データ構造を統一し管理しやすくするために、Taskも含め、すべてのデータの扱いはMemorySegment
+で統一したほうが良いと考える。
+これらの一度に扱うデータのサイズ、Taskの粒度の大きさなど、最適な大きさはわかっていない。
+なるべく非同期にTaksを設定し、パイプライン化を行うにあたって、それらの項目も考慮していく。
+
 %}{