Mercurial > hg > Papers > 2014 > kkb-sigos
comparison paper/cerium_gpu.tex @ 7:18b7450b6959
add presen
author | Shohei KOKUBO <e105744@ie.u-ryukyu.ac.jp> |
---|---|
date | Mon, 12 May 2014 03:37:44 +0900 |
parents | |
children |
comparison
equal
deleted
inserted
replaced
6:8a73ff7d41b2 | 7:18b7450b6959 |
---|---|
1 \section{Cerium の GPGPU への対応} | |
2 本章では、まずはじめに GPU プログラミングの特徴および問題について述べ、Cerium への実装でどのように対応したかについて説明する。 | |
3 | |
4 \subsection{GPU プログラミングの特徴および問題} | |
5 まず Multi Core CPU に対するプログラミングと同様に性能を向上させるためには、プログラム全体を対象とした並列度を高くしなければならない。 | |
6 明示的な並列化部分はループ部分である。 | |
7 GPU は数百個のコアを有しており、ループ部分に対してデータ並列で処理を行うことで CPU より高速で演算を行うことができる。 | |
8 プログラムの大部分がループであれば、データ並列による実行だけでプログラムの性能は向上する。 | |
9 しかし、多くのプログラムはその限りではない。 | |
10 GPGPU においてネックになる部分はデータ転送である。 | |
11 GPU の Memory 空間(図:\ref{fig:gpuarch})は CPU(図:\ref{fig:cpuarch}) とは異なり、Shared Memory ではないため host と device 間でデータの共有ができない。 | |
12 データにアクセスするためには Memory 空間ごとコピーするしかない。 | |
13 これが大きなオーバーヘッドになるので、データ転送をオーバーラップする必要がある。 | |
14 今回新たに、データ転送を自動でオーバーラップするように OpenCL および CUDA を用い Scheduler を実装した。 | |
15 | |
16 \begin{figure}[htpd] | |
17 \begin{center} | |
18 \includegraphics[scale=0.35]{./images/gpu_arch.pdf} | |
19 \end{center} | |
20 \caption{Gpu Architecture} | |
21 \label{fig:gpuarch} | |
22 \end{figure} | |
23 | |
24 \begin{figure}[htpd] | |
25 \begin{center} | |
26 \includegraphics[scale=0.7]{./images/cpu_arch.pdf} | |
27 \end{center} | |
28 \caption{Cpu Architecture} | |
29 \label{fig:cpuarch} | |
30 \end{figure} | |
31 | |
32 \subsection{OpenCL および CUDA を用いた Scheduler の実装} | |
33 Scheduler と CpuThreads に対応させる形で OpenCL を用いた GpuScheduler, GpuThreads、CUDA を用いた CudaScheduler, CudaThreads を実装した。 | |
34 TaskManager から転送された TaskList の情報をもとに device 上のメモリ領域を確保する。 | |
35 その後、OpenCL ならば CommandQueue、CUDA ならば Stream に Operation を発行していく。 | |
36 Operation は発行された順序で実行されるので、host から device へのデータ転送、kernel の実行、device から host へのデータ転送の順に発行する。 | |
37 非同期 API を用いることでデータ転送や kernel の実行を並列に行うことができる。 | |
38 通常、非同期 API を用いる場合は依存関係を考慮した同期が必要になるが転送されてくる Task の依存関係は TaskManager ですべて解消されているので Scheduler 側では順番を考えず Task を実行して問題ない。 | |
39 host から device へのデータ転送は、OpenCL では clEnqueueWriteBuffer、CUDA では cuMempcyHtoDAsync を用いて行われる。 | |
40 clEnqueueWriteBuffer は第三引数に CL\_FALSE を指定することで非同期なデータ転送を行う。 | |
41 転送されてきた TaskList からデータ並列またはタスク並列で実行するか決定する。 | |
42 データ並列で実行する場合は、OpenCL では clEnqueueTaskNDRangeKernel、CUDA では cuLaunchKernel を用いる。 | |
43 タスク並列で実行する場合は、OpenCL では clEnqueueTask、CUDA では cuLaunckKernel の引数を1に設定することで実行することができる。 | |
44 device から host へのデータ転送は、OpenCL では clEnqueuReadBuffer、CUDA では cuMemcpyDtoHAsync を用いて行われる。 | |
45 clEnqueueReadBuffer も clEnqueueWriteBuffer と同様に第三引数に CL\_FALSE を指定することで非同期実行となる。 | |
46 転送されてきた Task がすべて終了すると Synchronized Queue である mail を通して TaskManager に Task の終了を通知する。 | |
47 終了が通知されると TaskManager で依存関係が解消し、再び TaskList を転送する。 | |
48 GpuScheduler および CudaScheduler は複数の CommandQueue および Stream を持っており、パイプラインで実行される。 | |
49 | |
50 kernel の記述は以下のようになる。 | |
51 \lstinputlisting[caption=multiply(OpenCL),label=test]{./source/Multi.cl} | |
52 \lstinputlisting[caption=multiply(CUDA),label=test]{./source/Multiply.cu} | |
53 | |
54 修飾子など若干の違いはあるが、ほぼ同じ記述で書くことができるが CPU, OpenCL, CUDA のどれか1つの記述から残りのコードも生成できるようにすることが望ましい。 |