Mercurial > hg > Papers > 2014 > kkb-sigos
view introduction.tex @ 4:593671347b01
fix
author | Shinji KONO <kono@ie.u-ryukyu.ac.jp> |
---|---|
date | Mon, 21 Apr 2014 22:16:31 +0900 |
parents | 2921110c23aa |
children | 679859bf2fe8 |
line wrap: on
line source
\section{はじめに} GPU の普及と高性能化にともない、GPU の演算資源を画像処理以外の目的にも利用する GPGPU(GPU による汎目的計算)が注目されている。 GPU 以外にも Cell, SpursEngine, Xeon Phi など様々なプロセッサが存在する。 それぞれのプロセッサを利用するにはそれぞれ異なる API を利用する必要があり、それらの対応に多くの時間を取られてしまいプログラムの性能改善に集中することができない。 また、GPU や Cell などメモリ空間が異なるプロセッサはデータの転送がオーバーヘッドとなるので、データ転送を効率的に行えるかどうかで処理時間が大きく変わる。 当研究室で開発・改良が行われている並列プログラミングフレームワーク Cerium は様々なプロセッサを統合して扱えるフレームワークを目指している。 様々なプロセッサを統合して扱えるフレームワークとしてフランス国立情報学自動制御研究所(INRIA)が開発している StarPU がある。 StarPU は Cerium と同じタスクベースの非同期フレームワークである。 %% ちゃんと論文を引用する タスクという単位で記述することで処理とデータを分離し、より効率的に処理を行うことができる。 StarPU にはパイプラインでの実行機構は入ってなく、パイプライン処理を行いたい場合は自分で実装するしかない。 しかし、パイプライン処理を書くことは非常に煩雑で難しい。 そこで、今回 Cerium に OpenCL, CUDA を用いた Scheduler を新たに実装した。 Scheduler は自動でデータ転送をオーバーラップし、パイプラインで処理を行うように設計した。 本論文では、まず OpenCL, CUDA について説明する。 その後、既存の Cerium の実装および新たに実装した GPU 実行の機構について説明する。 最後に WordCount, FFT を例題として測定し、評価を行う。