|
1
|
1 \section{benchmark}\label{section:benchmark}
|
|
|
2 \subsection{ベンチマーク}
|
|
|
3 Bitonic Sortの例題を用いて計測した。入力として100,000要素の配列をsortする例題である。
|
|
|
4 これをGPUの比較対象としてマルチコアCPUで同様の例題の計測を行った。
|
|
|
5
|
|
|
6 実験環境
|
|
|
7 \begin{itemize}
|
|
|
8 \item OS : MacOS 10.8.2
|
|
|
9 \item CPU : 2*2.66GHz 6-CoreIntel Xeon
|
|
|
10 \item Memory : 16GB
|
|
|
11 \item Compiler : Apple clang version 4.1 (based on LLVM 3.1svn)
|
|
|
12 \item GPU : AMD ATI Radeon HD 5870 1024MB
|
|
|
13 \end{itemize}
|
|
|
14 この環境で実行したところ、CPUと比べてGPUの実行時間が100倍程かかることがわかった。
|
|
|
15 Bitonic sortはdataを分割してそれぞれに対して並列にsort(ここではQuick Sort)をかけて統合を繰り返すsortである。
|
|
|
16 (他に、Word count と FFT の例題を使用している)。
|
|
|
17
|
|
|
18 遅い理由としては OpenCL での build 時間が含まれていることが考えられる。また、ND range を実装してないので、
|
|
|
19 並列度が足りてないのも原因の一つだと思われる。
|
|
|
20
|
|
|
21 % 通常CPUに この結果はdataのinputに起因していると考えられる。
|
|
|
22 % GPUはメモリ空間がCPUと異なるため、host側で設定した値をkernelがそのまま読み込むことはできない。
|
|
|
23 % OpenCLが提供しているAPIでmemory Bufferを作成し、そこに値を書き込むことでkernelとhostで値を共有している。
|
|
|
24 メモリバッファによるコピーも要因の一つである。
|
|
|
25 そこで、一回に送信するdata 数(BLOCK SIZE)を増やしてベンチマークを行った。
|
|
|
26 表\ref{table:benchmark}が結果である。
|
|
|
27 \begin{table}[h]
|
|
|
28 \begin{center}
|
|
|
29 \caption{sortによるBenchmarkの結果}
|
|
|
30 \label{table:benchmark}
|
|
|
31 \small
|
|
|
32 \begin{tabular*}{60mm}[t]{c|r}
|
|
|
33 \hline
|
|
|
34 length& 100,000 \\
|
|
|
35 \hline\hline
|
|
|
36 1 CPU & 796 ms \\
|
|
|
37 \hline
|
|
|
38 2 CPU & 439 ms \\
|
|
|
39 \hline
|
|
|
40 6 CPU & 153 ms \\
|
|
|
41 \hline
|
|
|
42 12 CPU& 96 ms \\
|
|
|
43 \hline
|
|
|
44 24 CPU& 89 ms \\
|
|
|
45 \hline
|
|
|
46 \hline
|
|
|
47 GPU(改良前)& 330752 ms \\
|
|
|
48 \hline
|
|
|
49 GPU(改良後)& 5306 ms\\
|
|
|
50 \hline
|
|
|
51 \end{tabular*}
|
|
|
52 \end{center}
|
|
|
53 \end{table}
|
|
|
54
|
|
|
55 まだCPUとの性能差は開いているが、10倍程速度が向上した。
|
|
|
56 Task並列ではなく、GPU側でもデータ並列の実行をサポートし、
|
|
|
57 BufferへのRead/Writeのパイプラインが上手く動作するように同期機構の見直しを行う事が今後の課題となる。
|
