Mercurial > hg > Papers > 2012 > yutaka-master
diff paper/chapter4.tex @ 1:5dbcea03717e draft
fix
author | Yutaka_Kinjyo <yutaka@cr.ie.u-ryukyu.ac.jp> |
---|---|
date | Tue, 07 Feb 2012 17:38:59 +0900 |
parents | |
children | b8d790bccfe7 |
line wrap: on
line diff
--- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/paper/chapter4.tex Tue Feb 07 17:38:59 2012 +0900 @@ -0,0 +1,245 @@ +\chapter{Ceriumの改良} +本章では、Cerium に行った改良について説明する。 +Cerium のレンダリングの例題として ball\_bound を使用し、それを元に改良の効果を示していく。まず、改良前の 計測結果を示す。 + +\begin{table}[!htb] + \begin{center} + \caption{Cerium 改良前 (ball bound)} \label{tab:rendering_flat} + \hbox to\hsize{\hfil + \begin{tabular}{|c|c|c|c|} \hline + FPS & DMA転送待ち時間 & mail待ちの割合 & SPE稼働率\\ \hline + 30.2FPS & 1.8\% & 74.3\% & 23.7\% \\ \hline + \end{tabular}\hfil} + \end{center} +\end{table} + +Mail の待ち時間が 約70\%あり、処理時間の大部分を占めている。この Mail の待ち時間を削減するために Task をグルーピングする TaskArray, ソフトウェアMailQueue の実装を行った。また RenderinEngine の Task 内には、明示的な DMAロードが記述されており、アーキテクチャ依存となっている。そこでアーキテクチャ依存の記述を避けるために、MemorySegment を実装した。 + + +\section{TaskArray} +本研究では新しい 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 自体の回数を減らし、待ち時間を削減できると考える。 + +\begin{figure}[htb] + \begin{center} + \includegraphics[scale=0.4]{./images/taskarray.pdf} + \end{center} + \caption{task array flow} + \label{fig:taskarray} +\end{figure} + +以下に Task Array を用いた記述例を示す。このプログラムは Task Array に複数の同一 Task を +登録して、まとめて実行するというプログラムである。 + +\begin{verbatim} +void +hello_init(TaskManager *manager) +{ + + /* task id/task num/param/inData/outData の数を指定する*/ HTask *twice_main = manager->create_task_array(Hello,task_num,data_count, + data_count,data_count); + Task *t = 0; + + for(int i = 0;i<task_num;i++) { + t = twice_main->next_task_array(Hello, t); + } + twice_main->spawn_task_array(t->next()); + twice_main->set_cpu(SPE_ANY); + twice_main->spawn(); +} + +static int +run(SchedTask *s,void *rbuf, void *wbuf) +{ + s->printf("Hello World\n"); + return 0; +} + +// 実行結果 +% ./hello -task 6 +Hello World +Hello World +Hello World +Hello World +Hello World +Hello World + +\end{verbatim} + +プログラムに用いられてる新しい API について説明する。\\ +\begin{description} +\item[create\_task\_array: ] 同一の Task を複数持つことのできる Task Array を生成する。この際に、登録する Task のID, Task の数、設定する param, input data, output data の数を指定する。 +\item[next\_task\_array: ] Task Array に Task を実行順序を定める。実行順序は next\_task\_array +を行った順になる。 +\item[spawn\_task\_array: ] Task Array の中のすべての Task が書きこまれたかどうかをチェックする。TaskArray では指定された Task の数と、実際に登録された Task の数が同一か計算し、異なってた場合にはエラー文を返す。これは DMA ロードの際のサイズを合わせる為、正確に数を合わせなければならない。 +\end{description} + +この TaskArray をRenderingEngine の DrawSpanTask に適応させた。レンダリングの例題は ball bound を用いた。その効果を示す。wor(\tabref{taskarray_ballbound})。 + +\begin{table}[!htb] + \begin{center} + \caption{Task Arrayの効果(ball bound)} \label{tab:taskarray_ballbound} + \hbox to\hsize{\hfil + \begin{tabular}{|c|c|c|c|c|} \hline + TaskArray & FPS & DMA転送待ち時間 & mail待ちの割合 & SPE稼働率\\ \hline + 未使用 & 30FPS & 1.8\% & 76.2\% & 22.0\% \\ \hline + 使用 & 32.2FPS & 2.5\% & 66.7\% & 30.8\% \\ \hline + \end{tabular}\hfil} + \end{center} +\end{table} + +mail の待ち時間が 約10\% 削減され、FPSの向上があり、TaskArray による効果が見られた。 + +\section{MailQueue} +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をすべて書き出す処理を行う。 + +MailQueueの大きさはメモリ容量の限り自動で拡張される。以下にball bound の例題での MailQueue の有無における測定結果を示す(\tabref{mailqueue})。 + +\begin{table}[!htb] + \begin{center} + \caption{MailQueue の効果(ball bound)} \label{tab:mailqueue} + \hbox to\hsize{\hfil + \begin{tabular}{|c|c|c|c|c|} \hline + MailQueue & FPS & DMA転送待ち時間 & mailの待ち時間 & SPE稼働率\\ \hline + なし & 32.2FPS & 2.5\% & 66.7\% & 30.8\% \\ \hline + あり & 41.7FPS & 3.3\% & 56.8\% & 40.0\% \\ \hline + \end{tabular}\hfil} + \end{center} +\end{table} + +Mail の待ち時間の割合が減少し、8FPSの向上がみられた。ソフトウェア MailQueue によって Mail の書き出しタイミングを変更することで、Mail の待ち時間を削減することができた。PPE 側では、SPEからの Mail の確認は一度の ループ文で行なっている。Mail を確認しおえ、そのループ文を抜けてしまうと、次に Mail を確認するまでに PPE 側の Task 処理が挟まれる。よって、SPE 側の Mail 通知は一度に多く行った方が、PPE側の Mail 確認がスムーズに行われ、結果 SPE の稼働率向上に繋がると言える。ソフトウェアMailQueue では Mail をキューイングし一度に書き出すので、この点でも効果がある。 + +\section{MemorySegment} +CreateSpanTask 内では明示的に DMA転送命令を行なっている。これは処理するデータ構造上の理由である。しかし、DMA転送は Cell のアーキテクチャに依存した機能である。また Task に登録された input data と output data は自動的に TaskManager によってパイプライン化されるが、明示的にDMA転送を行う場合には、手動でのパイプライン処理を行う必要がある。そこで、Task 内でのデータの入出力の機能を 抽象化する MemorySegment を実装した。MemorySegment によって DAM転送は隠蔽され、アーキテクチャ依存の記述を避けることができる。またメモリ操作も抽象化される。 + + +CreateSpanTask 内の明示的なDMA転送の例を示す。 + +\begin{verbatim} +create_span() { + + tmp_spack = spack; + spack = send_spack; + send_spack = tmp_spack; + + smanager->dma_wait(SPAN_PACK_STORE); + smanager->dma_store(send_spack, (memaddr)spackList[prev_index], + sizeof(SpanPack), SPAN_PACK_STORE); + + smanager->dma_load(spack, (memaddr)spackList[index], + sizeof(SpanPack), SPAN_PACK_LOAD); + + prev_index = index; + smanager->dma_wait(SPAN_PACK_LOAD); + + span_calc(spack); + +} + +\end{verbatim} + +CreateSpanTask では SpanPack というデータ構造を扱う。MainMemory から SpanPack をDMAロードし、ロードした SpanPack に span\_calc() で計算した Span を格納し また MainMemory へと書きだす。変数 tmp\_spack, spack, send\_spack はそれぞれ SpanPack へのポインタであり、それを入れ替えながらDMA転送行うことで、メモリを節約を行なっている。それぞれのAPIの説明を行う。 + +\begin{description} +\item[dma\_wait: ] 指定されたdmaタグの dma転送の完了を待つ。 +\item[dma\_store: ] 指定された LS のアドレスから、指定された サイズ分 の領域を MainMemory に書き出す。その際にdma\_wait で用いる dma タグも指定する。例の場合では SPAN\_PACK\_STORE である。 +\item[dma\_load: ] 指定された MainMmory のアドレスから 指定された サイズ分のデータを LS へDMAロードを行う。その際に dma\_wait で用いる dma タグも指定する。 例の場合では SPAN\_PACK\_LOAD である。 +\end{description} +dma タグは、enum によって整数が定義されている。次に上記のコードを MemorySegment API に変更した例を示す。 + +\begin{verbatim} +create_span() { + + smanager->wait_segment(span_put_ms); + + span_put_ms = span_get_ms; + smanager->put_segment(span_put_ms); + + span_get_ms = smanager->get_segment((memaddr)spackList[index], span_ml); + smanager->wait_segment(span_get_ms); + + prev_index = index; + spack = (SpanPackPtr)span_get_ms->data; + + span_calc(spack); + +} +\end{verbatim} + +変数 span\_get\_ms, span\_put\_ms はそれぞれ MemorySegment のデータ構造を指すポインタである。この MemorySegment というデータ構造で Task 内部での 必要なデータのやり取りを行う。MemorySegment のAPIの説明を行う + +\begin{description} +\item[wait\_segment: ] 指定された MemorySegment の処理完了を待つ。それは書き出し、読み込みどちらも当てはまる。dma\_wait に相当する。 +\item[put\_segment: ] 指定された MemorySegment を書きだす。書き出し先のアドレスは、MemorySegment の生成時に登録されている。 +\item[get\_segment: ] 指定されたアドレス への書き出しを目的とした、MemorySegment を取得する。MemorySegment は予め MemorySegmentList によって管理されており、その List から使用可能な Segment を得ることができる。 +\end{description} + +SPE の LS は 256KB となっていて、一般的なCPUのメモリ容量と比べると小さい。LS 内部での頻繁な メモリのアロケーションなどは LS を圧迫することになる。そこで、一度確保したメモリを使いまわすことが必要である。MemorySegment は必要な構造体をはじめに List として登録する。List は LRU で管理し、指定されたメモリ容量を超えた場合には 最もアクセスされた時間が古いデータから順に開放され、新たなデータを List に加える。以下にそのコードを示す + +\begin{verbatim} + + ml = smanager->createMemList(sizeof(SpanPack), SPANPACK_SEGMENT_NUM); + smanager->global_set(GLOBAL_SPANPACK_LIST, (void *)ml); + +\end{verbatim} + +コード上にあるAPIの説明を行う。 + +\begin{description} +\item[createMemList: ] 指定されたサイズの、指定され数だけ メモリを確保し、そのメモリを List を生成する。 +\item[global\_set: ] どの Task からでも 指定された アドレスを呼び出すことができる。Task 共通のメモリ空間を扱う時に用いる。 +\end{description} +このように MemorySegment はメモリの List を持ち、それを抽象化した API によって LS のメモリを使い回しながら、Task 内でのデータ転送を可能にする。また 明示的なDMA転送API を隠蔽することができるので、他の分散メモリ環境などでの汎用性が期待できる。DrawSpanTask の他に、Texture cache でも使用している。 + +\subsection{改良のまとめと比較} + +本研究で行った改良を加えた計測結果をまとめる(\tabref{result}) + +\begin{table}[!htb] + \begin{center} + \caption{本研究の改良効果(ball bound)} \label{tab:result} + \hbox to\hsize{\hfil + \begin{tabular}{|c|c|c|c|c|} \hline + & FPS & DMA転送待ち時間 & mail待ちの割合 & SPE稼働率\\ \hline + 改良前 & 30.2FPS & 1.8\% & 74.3\% & 23.7\% \\ \hline + 改良後 & 41.7FPS & 3.3\% & 56.8\% & 40.0\% \\ \hline + \end{tabular}\hfil} + \end{center} +\end{table} +Mail の待ち時間、DMA転送の待ち時間がともに削減され、稼働率とFPSの向上が見られた。 + +本研究で行った改良の加え、Cerium 開発後からの改良である、Task のパイプライン化、Texture cache の使用の効果をまとめる(\tabref{imp_result}) + +\begin{table}[!htb] + \begin{center} + \caption{Ceriumの改良の効果(ball bound)} \label{tab:imp_result} + \hbox to\hsize{\hfil + \begin{tabular}{|c|c|c|c|c|} \hline + & FPS & DMA転送待ち時間 & mail待ちの割合 & SPE稼働率\\ \hline + 改良前 & 24.6FPS & 5.5\% & 72.4\% & 22.1\% \\ \hline + 改良後 & 41.7FPS & 3.3\% & 56.8\% & 40.0\% \\ \hline + \end{tabular}\hfil} + \end{center} +\end{table} + +Cerium 開発後からの改良の結果、FPS が17上昇し、稼働率が18\%向上した。 + +\subsubsection{OpenGLとの比較} + +OpenGL (Open Graphics Library) とは、Silicon Graphics 社が開発した、3D グラフィックス +処理のためのプログラミングインターフェースである。 +上記で紹介した SuperDandy を Task を用いない OpneGL 上で動作するバージョンを用意して、Cerium +と性能を比較してみた。OpenGL は PPE だけで動作している。Cerium は今までの改良をすべて加えたもの。 + +\begin{table}[!htb] + \begin{center} + \caption{シューティングゲーム「dandy」の性能比較(OpenGL, Cerium))} \label{tab:dandy-compare} + \hbox to \hsize{\hfil + \begin{tabular}{|c|l|l|c|} \hline + & OpenGL & Cerium & 性能差\\ \hline + dandy & 17.5 FPS & 49.5 FPS & 2.9 倍\\ \hline + \end{tabular}\hfil} + \end{center} +\end{table} + +コアを1つ用いている OpenGL 版に比べて、Cerium では 2.9 倍の性能向上が見られた。 +SPEを活用し、改良によって待ち時間の削減ができ、性能の向上ができた。