Mercurial > hg > Papers > 2011 > yutaka-sigos

changeset 4:2c915c8ae5e5

Find changesets by keywords (author, files, the commit message), revision number or hash, or revset expression.
fix
author Yutaka_Kinjyo
date Sun, 13 Mar 2011 04:16:49 +0900
parents 9d45d91eb5b1
children ff9b8938199f
files paper/ARC195OS117-32.tex
diffstat 1 files changed, 88 insertions(+), 67 deletions(-) [+]
line wrap: on
line diff
--- a/paper/ARC195OS117-32.tex	Sun Mar 13 03:15:22 2011 +0900
+++ b/paper/ARC195OS117-32.tex	Sun Mar 13 04:16:49 2011 +0900
@@ -151,31 +151,87 @@
 \section{Cerium の改良}\label{sec:Enum}\label{sec:item}
 
 Cerium TaskManager では PPE で Task を定義し、PPE から SPE に Task を割り振る。
-SPE は DMA転送（\ref{sec:dma}）によって、Taskと、Taskで用いるデータを受け取る。
+SPE は DMA転送（\ref{sec:dma}節）によって、Taskと、Taskで用いるデータを受け取る。
 DMA転送を用いる場合、待ち時間が発生し、その間SPEの処理が止まる。
 そのため、転送をパイプライン化し、DMA転送の待ち
 を隠す必要がある。Cerium では SPE にスケジューラを持ち Task とデータ の 読み込み、実行、書き出し
-をパイプライン化している。
+をパイプライン化している。(\figref{fig:scheduler}）Task は一つずづ転送されるのではく、ある程度の
+数を集めて、TaskList として転送される。
+
+\begin{figure}[tb]
+  \begin{center}
+    \includegraphics[scale=0.5]{./images/scheduler.pdf}
+  \end{center}
+  \caption{スケジューラ}
+  \label{fig:scheduler}
+\end{figure}
 
 
 \subsection{MailQueue} 
 Task には依存関係が設定でき、PPE 側で解決する。実行完了した Task の情報を SPE 側から PPE 側に 通知するために CellのMailbox機能を使用した（\ref{sec:mail-box}）。
-SPEスケジューラは Task が処理完了になる毎に、Mailを Outbound Mailbox に書きこむので、PPE側でMailの読み込みが間に合わないと、待ちが入り、SPEの処理が
-止まってしまう。
+SPEスケジューラは Task が処理完了になる毎に、Mailを Outbound Mailbox に書きこむので、PPE側でMailの読み込みが間に合わないと、待ちが入り、SPEの処理が止まってしまう。
 
 
-これを解消するためにMailQueueを導入した。MailQueueは、SPEから書き込みきれないMailを一時的に退避させるものである。
+これを解消するためにMailQueueを導入した。MailQueueは、SPEから書き込みきれないMailを一時的にキューに退避させるものである。
 TaskListを書きだす時に溜まったQueueの中身をすべて書き出す。
 Task完了を知らせる Mail書き出しの待ちは、Task毎から、TaskList毎になる。MailQueueを有効にしたときの実行速度は以下にようになる
 
-32.442749 FPS なし
 
-41.350211 FPS　あり
+\begin{table}[!htb]
+  \begin{center}
+    \caption{１秒辺りの Rendering Engine 全体の処理回数(Frame Per Second)} 
+    \ecaption {hogehoge} \label{tab:FPS}
+    \hbox to\hsize{\hfil
+      \begin{tabular}{|c|l|l|c|} \hline
+         & 改良前 & 改良後 & 性能\\ \hline
+         dandy & 32.4 FPS & 41.3 FPS & \%向上 \\ \hline
+      \end{tabular}\hfil}
+  \end{center}
+\end{table}
 
 
 これは、PPE側のMailチェックのやり方に関係している。
 PPE では mail をチェックするAPIを用いて、mail の有無を確認し、
 
+\subsection{TaskArray}
+
+Task の依存関係を解決するために、SPEから Mail によってPPEへと処理が完了したTaskの情報が通知される。
+その際に、同じ種類のTaskは一つのMailでよい場合がある。
+そこで、我々は Task Array を提案、実装した。
+Task Array は、複数の Task をまとめて扱うことが出来る。Task Array に登録した順番で
+依存関係を設定しているので、PPE で解決する Task の数が減り、 SPE からの TaskList 要求に応答しやすくなる。
+また、一度に多くの Task を TaskList に登録できるため、 SPE 側からの TaskList 要求の回数が減り、待ち時間が
+生じる可能性が減る。
+
+Rendering Engine の中で、最も数が多く生成される DrawSpanTask を Task Array 化した。
+地球と月を表示する例題を対象に効果を測った。 FPS(Frame Per Second) は、一秒間に
+表示できる Frame 数のことである。
+
+\begin{table}[htb]
+  \begin{center}
+    \caption{Rendering Engine の Task Array 化による比較}
+    \label{tab:rendering-taskarray-compare}
+    \begin{tabular}{|c|c|c|c|}
+      \hline
+      & Task & Task Array & 向上率\\
+      \hline
+      FPS & 16.4 & 18.5 \% & 34\%\\
+      \hline
+      dma wait & 3.34\% & 1.88\% & 2.34\%\\
+      \hline
+      mail wait & 84\% & 69\% & 15\% \\
+      \hline
+    \end{tabular}
+  \end{center}
+\end{table}
+
+結果から DrawSpanTask を Task Array 化すると、FPS が上昇し、mail の wait 時間が減ったことが分かる。
+Rendering Engine では、 PPE 側でも処理をするべき Task があり、常に PPE が稼動している状態になって
+いる。そのため mail を処理する時間が遅れ、SPE のmail 待ちが発生していると考えられる。 Task Array 化
+で Task をまとめることで SPE が一つの TaskList で多くの Task を実行できるようになったため、 TaskList
+を要求する回数が減って、待ち時間が発生する回数も減少した。また、それは SPE からの mail の数が減った
+ということなので、PPE 側の mail 処理の時間短縮になったと考えられる。
+
 \subsection{PipeLine化}
 
 Cerium では RenderinEngine を実装している。RenderinEngine は大きく分けて、
@@ -236,51 +292,6 @@
 SPEの待ち時間が発生することへ対処しないといけない。
 その対処の一つとしてそれにパイプライン化は有効である。
 
-\subsection{Memory Access}
-
-WordCount を Cerium を用いて実装した。 Task 
-
-ちゃんとデータ配分しないとまずい
-
-\subsection{TaskArray}
-
-Task の依存関係を解決するために、SPEから Mail によってPPEへと処理が完了したTaskの情報が通知される。
-その際に、同じ種類のTaskは一つのMailでよい場合がある。
-そこで、我々は Task Array を提案、実装した。
-Task Array は、複数の Task をまとめて扱うことが出来る。Task Array に登録した順番で
-依存関係を設定しているので、PPE で解決する Task の数が減り、 SPE からの TaskList 要求に応答しやすくなる。
-また、一度に多くの Task を TaskList に登録できるため、 SPE 側からの TaskList 要求の回数が減り、待ち時間が
-生じる可能性が減る。
-
-Rendering Engine の中で、最も数が多く生成される DrawSpanTask を Task Array 化した。
-地球と月を表示する例題を対象に効果を測った。 FPS(Frame Per Second) は、一秒間に
-表示できる Frame 数のことである。
-
-\begin{table}[htb]
-  \begin{center}
-    \caption{Rendering Engine の Task Array 化による比較}
-    \label{tab:rendering-taskarray-compare}
-    \begin{tabular}{|c|c|c|c|}
-      \hline
-      & Task & Task Array & 向上率\\
-      \hline
-      FPS & 16.4 & 18.5 \% & 34\%\\
-      \hline
-      dma wait & 3.34\% & 1.88\% & 2.34\%\\
-      \hline
-      mail wait & 84\% & 69\% & 15\% \\
-      \hline
-    \end{tabular}
-  \end{center}
-\end{table}
-
-結果から DrawSpanTask を Task Array 化すると、FPS が上昇し、mail の wait 時間が減ったことが分かる。
-Rendering Engine では、 PPE 側でも処理をするべき Task があり、常に PPE が稼動している状態になって
-いる。そのため mail を処理する時間が遅れ、SPE のmail 待ちが発生していると考えられる。 Task Array 化
-で Task をまとめることで SPE が一つの TaskList で多くの Task を実行できるようになったため、 TaskList
-を要求する回数が減って、待ち時間が発生する回数も減少した。また、それは SPE からの mail の数が減った
-ということなので、PPE 側の mail 処理の時間短縮になったと考えられる。
-
 \subsection{SPEでのキャッシュ効果}
 
 \subsubsection{テクスチャの管理}
@@ -299,8 +310,26 @@
 の正方形にするように改良した。この改良によってテクスチャの最大縮小率を正確に求めることが出来るよう
 になった。
 
+\subsubsection{ハッシュの管理}
 
-この時に、頻繁にテクスチャを読み込む場合にはその読み込みがオーバヘッドが大きいになる。そこでキャッシュを実装した
+この時に、頻繁にテクスチャを読み込む場合にはその読み込みがボトルネックとなる。そこでキャッシュを実装した。
+キャッシュは MemorySegment と呼ばれるデータ構造単位でハッシュで管理する。MemorySegment はある一定の
+大きさに決め打った連続したメモリ領域のことである。キャッシュ実装の効果を示す。
+速度比較の対象には、使用するテクスチャ表示範囲が狭いball_bound と、画面すべてにテクスチャを表示するpanelを用いる。
+
+\begin{table}[!htb]
+  \begin{center}
+    \caption{１秒辺りの Rendering Engine 全体の処理回数(Frame Per Second)} 
+    \ecaption {hogehoge} \label{tab:cache}
+    \hbox to\hsize{\hfil
+      \begin{tabular}{|c|l|l|c|} \hline
+         & 改良前 & 改良後 & 性能\\ \hline
+         ball_boud & 6 FPS & 49.5 FPS & 68\%向上 \\ \hline
+         panel & 29.4 FPS & 49.5 FPS & 68\%向上 \\ \hline
+      \end{tabular}\hfil}
+  \end{center}
+\end{table}
+
 ところ、読み込み回数を抑え、ボトルネックを解消することができた。
 
 
@@ -310,6 +339,12 @@
 
 はやーくなったね。
 
+\subsection{Memory Access}
+
+WordCount を Cerium を用いて実装した。 Task 
+
+ちゃんとデータ配分しないとまずい
+
 
 %}{
 
@@ -328,20 +363,6 @@
 
 %}{
 
-\subsection{一般的な注意事項}
-
-会議の予稿集などとは違い，論文誌の体裁には伝統的かつ「堅い」約束事が数多くあ
-る．そのためスタイルファイルも「堅い」ものとなっており，{\LaTeX} の特徴の一
-つであるカスタマイズ機能は大幅に制限される．例えば \|\textheight| などのいわ
-ゆる style parameter を変更するのは当然やめていただきたい．どのようなカスタ
-マイズが許されるのかを示すのは難しいが，一つの基準として「スタイルファイルを
-読んでみて大丈夫だと確信が持てる」こと以外はしないことを強く勧める．
-
-なお，これらの変更やこのガイドで述べている「やめて欲しいこと」を行なっても，
-{\bf エラーになったりせず単に結果が変になる}ことに注意していただきたい．
-
-%}{
-
 \subsection{論文の構成}\label{sec:config}
 
 ファイルは次の形式で作る．なお下線部は投稿時にはなくてもよい．またトランザク