Mercurial > hg > Papers > 2012 > yutaka-master

comparison paper/chapter4.tex @ 1:5dbcea03717e draft

Find changesets by keywords (author, files, the commit message), revision number or hash, or revset expression.
fix
author Yutaka_Kinjyo <yutaka@cr.ie.u-ryukyu.ac.jp>
date Tue, 07 Feb 2012 17:38:59 +0900
parents
children b8d790bccfe7
comparison
equal deleted inserted replaced
0:6d80c2c895e4 1:5dbcea03717e
1 \chapter{Ceriumの改良}
2 本章では、Cerium に行った改良について説明する。
3 Cerium のレンダリングの例題として ball\_bound を使用し、それを元に改良の効果を示していく。まず、改良前の 計測結果を示す。
4
5 \begin{table}[!htb]
6 \begin{center}
7 \caption{Cerium 改良前 (ball bound)} \label{tab:rendering_flat}
8 \hbox to\hsize{\hfil
9 \begin{tabular}{|c|c|c|c|} \hline
10 FPS & DMA転送待ち時間 & mail待ちの割合 & SPE稼働率\\ \hline
11 30.2FPS & 1.8\% & 74.3\% & 23.7\% \\ \hline
12 \end{tabular}\hfil}
13 \end{center}
14 \end{table}
15
16 Mail の待ち時間が 約70\%あり、処理時間の大部分を占めている。この Mail の待ち時間を削減するために Task をグルーピングする TaskArray, ソフトウェアMailQueue の実装を行った。また RenderinEngine の Task 内には、明示的な DMAロードが記述されており、アーキテクチャ依存となっている。そこでアーキテクチャ依存の記述を避けるために、MemorySegment を実装した。
17
18
19 \section{TaskArray}
20 本研究では新しい Task として Task Array を実装した。 Cerium では Task と TaskList 毎に Mail を通知し、SPE の Mail の待ち時間が発生する問題があった。PPE 側で実行される Task もあるなかで、SPE側の Task を一つ一つ Task 毎に依存関係を処理しており、SPE への TaskList 要求や、次の Mail 書き込み待ちなど、Mail 通知の対応が遅れることが考えられる。Mail 通知の対応が遅れた分 SPE はアイドル状態となってしまい、稼働率が下がってしまう。この問題を解決するために、我々は Task Array を提案、実装した。 Task Array を使用することで、複数の Task をまとめる Task のグルーピングが行える。複数の Task を ひとつの Task Array として登録すると、依存関係の処理が Task Array ひとつ分で収まる。依存関係の処理には Mail 通知を行なっていたので 依存関係の処理が減少する分、 Mail 通知の回数も少なくなる。これによって、Mail 待ちによる SPE のアイドル状態の時間を減少させることができると考える。例えば TaskArray のサイズが4、TaskList のサイズが4、処理するべき Task の数が16の場合だとする。この時に TaskArray を使用すると、4つ必要だった TaskList が1つで済み、さらに16Task分の依存関係の解決が4つのTaskArray分で済む。(\figref{taskarray}) これによって Task 毎の Mail通知と TaskList 毎のMail通知の回数が合わせて 四分の一となる。このようにTaskArrayを用い Mail 自体の回数を減らし、待ち時間を削減できると考える。
21
22 \begin{figure}[htb]
23 \begin{center}
24 \includegraphics[scale=0.4]{./images/taskarray.pdf}
25 \end{center}
26 \caption{task array flow}
27 \label{fig:taskarray}
28 \end{figure}
29
30 以下に Task Array を用いた記述例を示す。このプログラムは Task Array に複数の同一 Task を
31 登録して、まとめて実行するというプログラムである。
32
33 \begin{verbatim}
34 void
35 hello_init(TaskManager *manager)
36 {
37
38 /* task id/task num/param/inData/outData の数を指定する*/ HTask *twice_main = manager->create_task_array(Hello,task_num,data_count,
39 data_count,data_count);
40 Task *t = 0;
41
42 for(int i = 0;i<task_num;i++) {
43 t = twice_main->next_task_array(Hello, t);
44 }
45 twice_main->spawn_task_array(t->next());
46 twice_main->set_cpu(SPE_ANY);
47 twice_main->spawn();
48 }
49
50 static int
51 run(SchedTask *s,void *rbuf, void *wbuf)
52 {
53 s->printf("Hello World\n");
54 return 0;
55 }
56
57 // 実行結果
58 % ./hello -task 6
59 Hello World
60 Hello World
61 Hello World
62 Hello World
63 Hello World
64 Hello World
65
66 \end{verbatim}
67
68 プログラムに用いられてる新しい API について説明する。\\
69 \begin{description}
70 \item[create\_task\_array: ] 同一の Task を複数持つことのできる Task Array を生成する。この際に、登録する Task のID, Task の数、設定する param, input data, output data の数を指定する。
71 \item[next\_task\_array: ] Task Array に Task を実行順序を定める。実行順序は next\_task\_array
72 を行った順になる。
73 \item[spawn\_task\_array: ] Task Array の中のすべての Task が書きこまれたかどうかをチェックする。TaskArray では指定された Task の数と、実際に登録された Task の数が同一か計算し、異なってた場合にはエラー文を返す。これは DMA ロードの際のサイズを合わせる為、正確に数を合わせなければならない。
74 \end{description}
75
76 この TaskArray をRenderingEngine の DrawSpanTask に適応させた。レンダリングの例題は ball bound を用いた。その効果を示す。wor(\tabref{taskarray_ballbound})。
77
78 \begin{table}[!htb]
79 \begin{center}
80 \caption{Task Arrayの効果(ball bound)} \label{tab:taskarray_ballbound}
81 \hbox to\hsize{\hfil
82 \begin{tabular}{|c|c|c|c|c|} \hline
83 TaskArray & FPS & DMA転送待ち時間 & mail待ちの割合 & SPE稼働率\\ \hline
84 未使用 & 30FPS & 1.8\% & 76.2\% & 22.0\% \\ \hline
85 使用 & 32.2FPS & 2.5\% & 66.7\% & 30.8\% \\ \hline
86 \end{tabular}\hfil}
87 \end{center}
88 \end{table}
89
90 mail の待ち時間が 約10\% 削減され、FPSの向上があり、TaskArray による効果が見られた。
91
92 \section{MailQueue}
93 Task の完了通知や、アイドル状態の SPE に Task のリストの情報を通知するために Mail を使用している。Cell の設計では、その通知に使われる SPE からの書き出しMailのQueueのサイズは1である。ハードウェアの設計として、Mailを書き出す場合、前回のMailがPPE側から読み込まれていない場合に、PPE側の読み出しでMailboxが空き状態になるまで、SPEはアイドル状態となる。するとPPE側のMail読み出し処理が追いつかない場合には、SPE側に余計な待ち時間が入ってしまう。そこで、ソフトウェアMailQueue を実装した。ハードウェアのMailboxへの書き込みができない場合には、ソフトウェアMailQueueへ書き出し、Mail の書き出し待ちをなくす。代わりに割り当てられたTaskListをすべて処理したあとに、MailQueueに残っているMailをすべて書き出す処理を行う。
94
95 MailQueueの大きさはメモリ容量の限り自動で拡張される。以下にball bound の例題での MailQueue の有無における測定結果を示す(\tabref{mailqueue})。
96
97 \begin{table}[!htb]
98 \begin{center}
99 \caption{MailQueue の効果(ball bound)} \label{tab:mailqueue}
100 \hbox to\hsize{\hfil
101 \begin{tabular}{|c|c|c|c|c|} \hline
102 MailQueue & FPS & DMA転送待ち時間 & mailの待ち時間 & SPE稼働率\\ \hline
103 なし & 32.2FPS & 2.5\% & 66.7\% & 30.8\% \\ \hline
104 あり & 41.7FPS & 3.3\% & 56.8\% & 40.0\% \\ \hline
105 \end{tabular}\hfil}
106 \end{center}
107 \end{table}
108
109 Mail の待ち時間の割合が減少し、8FPSの向上がみられた。ソフトウェア MailQueue によって Mail の書き出しタイミングを変更することで、Mail の待ち時間を削減することができた。PPE 側では、SPEからの Mail の確認は一度の ループ文で行なっている。Mail を確認しおえ、そのループ文を抜けてしまうと、次に Mail を確認するまでに PPE 側の Task 処理が挟まれる。よって、SPE 側の Mail 通知は一度に多く行った方が、PPE側の Mail 確認がスムーズに行われ、結果 SPE の稼働率向上に繋がると言える。ソフトウェアMailQueue では Mail をキューイングし一度に書き出すので、この点でも効果がある。
110
111 \section{MemorySegment}
112 CreateSpanTask 内では明示的に DMA転送命令を行なっている。これは処理するデータ構造上の理由である。しかし、DMA転送は Cell のアーキテクチャに依存した機能である。また Task に登録された input data と output data は自動的に TaskManager によってパイプライン化されるが、明示的にDMA転送を行う場合には、手動でのパイプライン処理を行う必要がある。そこで、Task 内でのデータの入出力の機能を 抽象化する MemorySegment を実装した。MemorySegment によって DAM転送は隠蔽され、アーキテクチャ依存の記述を避けることができる。またメモリ操作も抽象化される。
113
114
115 CreateSpanTask 内の明示的なDMA転送の例を示す。
116
117 \begin{verbatim}
118 create_span() {
119
120 tmp_spack = spack;
121 spack = send_spack;
122 send_spack = tmp_spack;
123
124 smanager->dma_wait(SPAN_PACK_STORE);
125 smanager->dma_store(send_spack, (memaddr)spackList[prev_index],
126 sizeof(SpanPack), SPAN_PACK_STORE);
127
128 smanager->dma_load(spack, (memaddr)spackList[index],
129 sizeof(SpanPack), SPAN_PACK_LOAD);
130
131 prev_index = index;
132 smanager->dma_wait(SPAN_PACK_LOAD);
133
134 span_calc(spack);
135
136 }
137
138 \end{verbatim}
139
140 CreateSpanTask では SpanPack というデータ構造を扱う。MainMemory から SpanPack をDMAロードし、ロードした SpanPack に span\_calc() で計算した Span を格納し また MainMemory へと書きだす。変数 tmp\_spack, spack, send\_spack はそれぞれ SpanPack へのポインタであり、それを入れ替えながらDMA転送行うことで、メモリを節約を行なっている。それぞれのAPIの説明を行う。
141
142 \begin{description}
143 \item[dma\_wait: ] 指定されたdmaタグの dma転送の完了を待つ。
144 \item[dma\_store: ] 指定された LS のアドレスから、指定された サイズ分 の領域を MainMemory に書き出す。その際にdma\_wait で用いる dma タグも指定する。例の場合では SPAN\_PACK\_STORE である。
145 \item[dma\_load: ] 指定された MainMmory のアドレスから 指定された サイズ分のデータを LS へDMAロードを行う。その際に dma\_wait で用いる dma タグも指定する。 例の場合では SPAN\_PACK\_LOAD である。
146 \end{description}
147 dma タグは、enum によって整数が定義されている。次に上記のコードを MemorySegment API に変更した例を示す。
148
149 \begin{verbatim}
150 create_span() {
151
152 smanager->wait_segment(span_put_ms);
153
154 span_put_ms = span_get_ms;
155 smanager->put_segment(span_put_ms);
156
157 span_get_ms = smanager->get_segment((memaddr)spackList[index], span_ml);
158 smanager->wait_segment(span_get_ms);
159
160 prev_index = index;
161 spack = (SpanPackPtr)span_get_ms->data;
162
163 span_calc(spack);
164
165 }
166 \end{verbatim}
167
168 変数 span\_get\_ms, span\_put\_ms はそれぞれ MemorySegment のデータ構造を指すポインタである。この MemorySegment というデータ構造で Task 内部での 必要なデータのやり取りを行う。MemorySegment のAPIの説明を行う
169
170 \begin{description}
171 \item[wait\_segment: ] 指定された MemorySegment の処理完了を待つ。それは書き出し、読み込みどちらも当てはまる。dma\_wait に相当する。
172 \item[put\_segment: ] 指定された MemorySegment を書きだす。書き出し先のアドレスは、MemorySegment の生成時に登録されている。
173 \item[get\_segment: ] 指定されたアドレス への書き出しを目的とした、MemorySegment を取得する。MemorySegment は予め MemorySegmentList によって管理されており、その List から使用可能な Segment を得ることができる。
174 \end{description}
175
176 SPE の LS は 256KB となっていて、一般的なCPUのメモリ容量と比べると小さい。LS 内部での頻繁な メモリのアロケーションなどは LS を圧迫することになる。そこで、一度確保したメモリを使いまわすことが必要である。MemorySegment は必要な構造体をはじめに List として登録する。List は LRU で管理し、指定されたメモリ容量を超えた場合には 最もアクセスされた時間が古いデータから順に開放され、新たなデータを List に加える。以下にそのコードを示す
177
178 \begin{verbatim}
179
180 ml = smanager->createMemList(sizeof(SpanPack), SPANPACK_SEGMENT_NUM);
181 smanager->global_set(GLOBAL_SPANPACK_LIST, (void *)ml);
182
183 \end{verbatim}
184
185 コード上にあるAPIの説明を行う。
186
187 \begin{description}
188 \item[createMemList: ] 指定されたサイズの、指定され数だけ メモリを確保し、そのメモリを List を生成する。
189 \item[global\_set: ] どの Task からでも 指定された アドレスを呼び出すことができる。Task 共通のメモリ空間を扱う時に用いる。
190 \end{description}
191 このように MemorySegment はメモリの List を持ち、それを抽象化した API によって LS のメモリを使い回しながら、Task 内でのデータ転送を可能にする。また 明示的なDMA転送API を隠蔽することができるので、他の分散メモリ環境などでの汎用性が期待できる。DrawSpanTask の他に、Texture cache でも使用している。
192
193 \subsection{改良のまとめと比較}
194
195 本研究で行った改良を加えた計測結果をまとめる(\tabref{result})
196
197 \begin{table}[!htb]
198 \begin{center}
199 \caption{本研究の改良効果(ball bound)} \label{tab:result}
200 \hbox to\hsize{\hfil
201 \begin{tabular}{|c|c|c|c|c|} \hline
202 & FPS & DMA転送待ち時間 & mail待ちの割合 & SPE稼働率\\ \hline
203 改良前 & 30.2FPS & 1.8\% & 74.3\% & 23.7\% \\ \hline
204 改良後 & 41.7FPS & 3.3\% & 56.8\% & 40.0\% \\ \hline
205 \end{tabular}\hfil}
206 \end{center}
207 \end{table}
208 Mail の待ち時間、DMA転送の待ち時間がともに削減され、稼働率とFPSの向上が見られた。
209
210 本研究で行った改良の加え、Cerium 開発後からの改良である、Task のパイプライン化、Texture cache の使用の効果をまとめる(\tabref{imp_result})
211
212 \begin{table}[!htb]
213 \begin{center}
214 \caption{Ceriumの改良の効果(ball bound)} \label{tab:imp_result}
215 \hbox to\hsize{\hfil
216 \begin{tabular}{|c|c|c|c|c|} \hline
217 & FPS & DMA転送待ち時間 & mail待ちの割合 & SPE稼働率\\ \hline
218 改良前 & 24.6FPS & 5.5\% & 72.4\% & 22.1\% \\ \hline
219 改良後 & 41.7FPS & 3.3\% & 56.8\% & 40.0\% \\ \hline
220 \end{tabular}\hfil}
221 \end{center}
222 \end{table}
223
224 Cerium 開発後からの改良の結果、FPS が17上昇し、稼働率が18\%向上した。
225
226 \subsubsection{OpenGLとの比較}
227
228 OpenGL (Open Graphics Library) とは、Silicon Graphics 社が開発した、3D グラフィックス
229 処理のためのプログラミングインターフェースである。
230 上記で紹介した SuperDandy を Task を用いない OpneGL 上で動作するバージョンを用意して、Cerium
231 と性能を比較してみた。OpenGL は PPE だけで動作している。Cerium は今までの改良をすべて加えたもの。
232
233 \begin{table}[!htb]
234 \begin{center}
235 \caption{シューティングゲーム「dandy」の性能比較(OpenGL, Cerium))} \label{tab:dandy-compare}
236 \hbox to \hsize{\hfil
237 \begin{tabular}{|c|l|l|c|} \hline
238 & OpenGL & Cerium & 性能差\\ \hline
239 dandy & 17.5 FPS & 49.5 FPS & 2.9 倍\\ \hline
240 \end{tabular}\hfil}
241 \end{center}
242 \end{table}
243
244 コアを１つ用いている OpenGL 版に比べて、Cerium では 2.9 倍の性能向上が見られた。
245 SPEを活用し、改良によって待ち時間の削減ができ、性能の向上ができた。