# HG changeset patch # User Shohei KOKUBO # Date 1383668202 -32400 # Node ID b7c8a956c10b96859268f147466cb84df54c1020 # Parent f4b3de4461132d92934de53312bfb3e48ab0b9fe write benchmark and conclusion diff -r f4b3de446113 -r b7c8a956c10b paper/cerium.tex --- a/paper/cerium.tex Tue Nov 05 23:59:45 2013 +0900 +++ b/paper/cerium.tex Wed Nov 06 01:16:42 2013 +0900 @@ -1,11 +1,11 @@ \section{Cerium における Task の生成}\label{section:cerium} Cerium では，user が createtask を行い、input data や依存関係の設定し spawn を行うと TaskManager で Task が生成される。 -spawn の代わりに新たに用意した iterate を利用することで，Data 並列処理を行う Task として登録される。 +spawn の代わりに新たに用意した iterate を利用することで，Data 並列実行を行う Task として登録される。 Task 毎に依存関係を表す wait\_i と wait\_me というリストがあり、依存関係が解消されて実行可能になった Task は ActiveTaskList に移される。さらに、Scheduler に転送しやすい TaskList に変換してから各 Scheduler に 転送される。 -以下に Data 並列処理を行う Task を生成する例題を示す。 +以下に Data 並列実行を行う Task を生成する例題を示す。 input data を二つ用意し、 input 同士を乗算し、 output に格納する multiply という例題となる。 \begin{Verbatim}[fontsize=\footnotesize,xleftmargin=1cm] void @@ -42,7 +42,7 @@ \hline set\_cpu & Task を実行するデバイスの設定 \\ \hline - iterate&Data 並列処理を行う Task として ActiveTaskList に登録 \\ + iterate&Data 並列実行を行う Task として ActiveTaskList に登録 \\ \hline \end{tabular} \end{center} diff -r f4b3de446113 -r b7c8a956c10b paper/conclusion.tex --- a/paper/conclusion.tex Tue Nov 05 23:59:45 2013 +0900 +++ b/paper/conclusion.tex Wed Nov 06 01:16:42 2013 +0900 @@ -1,11 +1,5 @@ \section{まとめ} -本研究では Cerium Task Manager をデータ並列による実行に対応させ、更にベンチマークも行った。 -これにより、大量のデータに対して同一の処理を繰り返し行うというGPUが得意とする処理が可能となった。 -しかし、 GPU 実行の場合は充分な性能が出ているが、 Multi Core の場合は並列度が充分に出ているとは言えない。 -データの転送や測定の見直し等、チューニングが必要である。 - -更に複数あるTaskをCPUとGPU、両方のアーキテクチャで実行できるように実装した。 -しかし、CPUとGPUは同じ性能が出るわけではない。 -更に GPU はデータの転送がネックになりやすいので、各Taskの計算量と実行時間が比例しない場合がある。 -そういった場合にCPUとGPUに均等にTaskを割り振ってしまうと、並列度が出ない。 -そこでCPUとGPUに対して最適にTaskを割り振るSchedulingの手法を提案した。 +本研究では Cerium Task Manager を Data 並列による実行に対応させ，更に benchmark も行った。 +これにより，大量の Data に対して同一の処理を繰り返し行う Task を簡単に記述できるようになった。 +しかし，実行時に並列度が充分に出ているとは言えない。 +index の割り当てや例題の選定等、チューニングが必要である。 diff -r f4b3de446113 -r b7c8a956c10b paper/data_parallel.tex --- a/paper/data_parallel.tex Tue Nov 05 23:59:45 2013 +0900 +++ b/paper/data_parallel.tex Wed Nov 06 01:16:42 2013 +0900 @@ -1,12 +1,10 @@ \section{Cerium における Data 並列}\label{data_parallel} -データ並列で実行する場合はspawn APIではなく、iterate APIでTaskを生成すればよい。 -Scheduler内で引数分のTaskを生成し、それぞれに自分が担当するindexをパラメタとして設定していく。 -iterateにはlengthを引数として渡し、lengthの値と渡したlengthの個数で次元数や -ワークアイテムのサイズをSchedulerが計算する。 -CPU実行時のkernelは以下のように記述する。 +Cerium では，iterate に length を引数として渡し，length の値と渡した引数の個数を次元数として Task 数を Scheduler が計算する。 +それぞれの CPU が担当する index は SchedTask に格納してある。 +実行時の Task は以下のように記述する。 \begin{Verbatim}[fontsize=\footnotesize,xleftmargin=1cm] -static int // kernel +static int // Task run(SchedTask *s,void *rbuf, void *wbuf) { float *indata1,*indata2,*outdata; @@ -15,30 +13,26 @@ indata2 = (float*)s->get_input(rbuf, 1); outdata = (float*)s->get_output(wbuf, 0); - long i = (long)s->get_param(0); + uisigned long i = s->x; outdata[i]=indata1[i]*indata2[i]; return 0; } \end{Verbatim} -\subsection{データ並列におけるindex割り当ての実装} -Taskを生成するとき、dimensionとワークアイテムのサイズをもとに各Taskが担当するindexを計算し、set\_paramする。 -kernelはget\_paramでそのindexを取得してデータ並列で実行する。 -get\_param APIがOpenCLのget\_global\_id APIに相当する。 +\subsection{Data 並列における index 割り当ての実装} +4 CPU で，一次元で10個の Data に対して Data 並列実行を行った場合， +各 CPU が担当する index は表:\ref{table:data_parallel_index}のようになる。 -例として、cpu数4、一次元で10個のdataにたいしてデータ並列実行を行った場合、 -各CPUが担当するindexは表:\ref{table:data_parallel_index}のようになる。 - -この例だと各CPUに対するindexの割り当ては、 -CPU0はindex0、4、8、 -CPU1はindex1、5、9、 -CPU2はindex2、6、 -CPU3はindex3、7となっている。 +この例だと各 CPU に対するindexの割り当ては， +CPU0 は index 0,4,8 +CPU1 は index 1,5,9, +CPU2 は index 2,6, +CPU3 は index 3,7 となっている。 \begin{tiny} \begin{table}[h] \begin{center} - \caption{data並列実行時のindexの割り当て} + \caption{Data 並列実行時の index の割り当て} \label{table:data_parallel_index} \small \begin{tabular}[t]{c||c|c|c|c} @@ -56,11 +50,6 @@ \end{table} \end{tiny} -この実装により、Ceriumでデータ並列の実行が可能になった。 -並列プログラミングだと、並列化するTaskが全部同一であるという事は少なくない。 -その際、Taskを生成する部分をループで回すことなく、簡単なsyntaxで記述できる。 - -データ並列で実行する場合は、inputとoutputを各Taskで共有するため、少ないコピーですむ。 -CPUならメモリ領域がTaskとmanagerで同じなので、dataのコピーで大きいオーバーヘッドにはならない。 -しかしCellとGPUはメモリ領域が異なるため、dataコピーのオーバーヘッドが大きく、 -データ並列による高速化が見込める。 +この実装により，Cerium で Data 並列実行が可能になった。 +並列プログラミングだと，並列化する Task が全部同一であるという事は少なくない。 +iterate を使用することで，Task を生成する部分をループで回すことなく，簡単な syntax で記述できる。 diff -r f4b3de446113 -r b7c8a956c10b paper/fft_benchmark.tex --- a/paper/fft_benchmark.tex Tue Nov 05 23:59:45 2013 +0900 +++ b/paper/fft_benchmark.tex Wed Nov 06 01:16:42 2013 +0900 @@ -1,6 +1,6 @@ \section{Benchmark}\label{fft_benchmark} -続いて、フーリエ変換と周波数フィルタによる画像処理を行う例題を用いてベンチマークを行った。 -512*512の画像を High Pass Filter で変換する例題である。 +続いて，フーリエ変換と周波数フィルタによる画像処理を行う例題を用いて benchmark を行った。 +512*512 の画像を High Pass Filter で変換する例題である。 実験環境 \begin{itemize} @@ -11,7 +11,6 @@ \item GPU : AMD ATI Radeon HD 5870 1024MB \end{itemize} -\subsection{Run Time} \begin{tiny} \begin{table}[h] \begin{center} @@ -30,43 +29,13 @@ \hline 8 CPU&117 ms \\ \hline - GPU&94 ms \\ - \hline \end{tabular} \end{center} \end{table} \end{tiny} -表\ref{table:fft_runtime}は CPU,GPU 上，及び CPU + GPU 上で同時実行して比較を行った。 -1 CPU を利用した場合と比較して，2 CPU では約 1.7 倍，GPU では約 4.8 倍の速度向上が見られる。しかしながら，8 CPU を利用した場合，4 CPU を利用した場合と比較して速度はあがっているが速度上昇率は約 1.5 倍に落ちている。これはアムダールの法則から，並列化率が低いために速度向上が頭打ちになっていると考えられる。 - -\subsection{Busy Time} -次に，RDTSC 命令を用い Busy Time の測定を行った。 - -\begin{tiny} - \begin{table}[h] - \begin{center} - \caption{Busy Time} - \label{table:fft_busytime} - \small - \begin{tabular}[t]{c||r|r} - \hline - &Time Stamp&Busy Time \\ - \hline - 1 CPU&1202282702&451 ms \\ - \hline - 2 CPU&687813186&258 ms \\ - \hline - 4 CPU&421398464&158 ms \\ - \hline - 8 CPU&265192153&99 ms \\ - \hline - GPU&3532807&1.3 ms \\ - \hline - \end{tabular} - \end{center} - \end{table} -\end{tiny} - -CPU を利用した場合，表\ref{table:fft_runtime}とほぼ同様の結果が得られた。 -しかしながら，GPU を利用した場合，Busy Time が 1.3 ms なのに対し，表\ref{table:fft_runtime}の Run Time は 94 ms となっている。この結果から，GPU 上で実行する場合，データの転送がネックになっていることがわかる。 +表\ref{table:fft_runtime}は使用する CPU のコア数を変更し比較を行った。 +1 CPU を利用した場合と比較して，2 CPU では約 1.7 倍，GPU では約 4.8 倍の速度向上が見られる。 +しかしながら，8 CPU を利用した場合，4 CPU を利用した場合と比較して速度はあがっているが速度上昇率は約 1.5 倍に落ちている。 +これはアムダールの法則から，並列化率が低いために速度向上が頭打ちになっていると考えられる。 +並列化率が低いのは，iterate で登録された Task が終了されるまで次の Task を実行することが出来ず，表\ref{table:data_parallel_index}のような index 割り当てだと Task の終了時間にばらつきが出て CPU の Utilization が低くなってることが考えられる。 diff -r f4b3de446113 -r b7c8a956c10b paper/introduction.tex --- a/paper/introduction.tex Tue Nov 05 23:59:45 2013 +0900 +++ b/paper/introduction.tex Wed Nov 06 01:16:42 2013 +0900 @@ -1,6 +1,6 @@ \section{研究の目的} -当研究室では Cell および Linux 、Mac OS X 上で動く並列プログラミングフレームワーク、Cerium Task Manager \cite{gongo:2008a}の開発・改良を行っている。 -いままで Ceruim Task Mnager では，関数やサブルーチンを一つの Task として Queue に登録し並列処理を行ってきた。 +当研究室では Cell および Linux，Mac OS X 上で動く並列プログラミングフレームワーク Cerium Task Manager \cite{gongo:2008a}の開発・改良を行っている。 +いままで Ceruim Task Mnager では，関数やサブルーチンを一つの Task として Queue に登録し並列実行を行ってきた。 しかし，この方法では大量の Data を処理するために，渡す Data を変更しながら同一の Task をループで何度も生成する必要がある。 また，一度に大量の Task を生成すると Memory が足りなくなり Swap が起こるという問題があった。 -当研究では，これらの問題を解決するため Data 並列処理のための API を実装し，fft について実行速度を測定し考察を行う。 +当研究では，これらの問題を解決するため Data 並列実行のための API を実装し，fft について実行速度を測定し考察を行う。 diff -r f4b3de446113 -r b7c8a956c10b paper/ipsj.tex --- a/paper/ipsj.tex Tue Nov 05 23:59:45 2013 +0900 +++ b/paper/ipsj.tex Wed Nov 06 01:16:42 2013 +0900 @@ -11,7 +11,7 @@ \begin{document} % 和文表題 -\title{Cerium Task Manager における Data 並列処理の実装} +\title{Cerium Task Manager における Data 並列実行} % 和文著者名 \author{ @@ -21,8 +21,8 @@ % 和文概要 \begin{abstract} Cerium Task Managerは並列プログラミングフレームワークである。 - 今回、MultiCore CPU での Data 並列処理を行うために iterate という API を用意した。 - この API を用いて fft を実装し，benchmark を取り、結果から iterate の性能と問題について考察を行った。 + 今回，MultiCore CPU での Data 並列実行を行うために iterate という API を用意した。 + この API を用いて fft を実装し，benchmark を取り，結果から iterate の性能と問題について考察を行った。 \end{abstract} % 表題などの出力 @@ -34,8 +34,6 @@ \input{cerium} % Cerium \input{data_parallel} \input{fft_benchmark} -%\input{benchmark1} -\input{scheduling} \input{conclusion} % まとめ %\input{manycore} % many core system %\input{osmesa} % OSMesa