# HG changeset patch
# User Yuhi TOMARI <yuhi@cr.ie.u-ryukyu.ac.jp>
# Date 1424124620 -32400
# Node ID e2790efcd3066f86385f8088f60022bfa6e8b226
# Parent  d4be7f4b9a73123060244b4d5ba22d772d54fa37
fix

diff -r d4be7f4b9a73 -r e2790efcd306 paper/chapter6.tex
--- a/paper/chapter6.tex	Tue Feb 17 05:07:25 2015 +0900
+++ b/paper/chapter6.tex	Tue Feb 17 07:10:20 2015 +0900
@@ -114,7 +114,7 @@
 Cerium Task Manager では、各種 Task にデバイスを設定することができる。
  SPE\_ANY 設定を使用すると、 Task Manager で CPU の割り振りを自動的に行う。
 BlockedRead は連続で読み込まれなければならないが、
-SPE\_ANY 設定で実行すると BlockedRead 間に別の Task を割り込んでしまう場合がある。
+SPE\_ANY 設定で実行すると BlockedRead 間に別の Task が割り込んでしまう場合がある。
 (図:\ref{fig:spe_any_blockedread})
 
 \begin{figure}[htpb]
diff -r d4be7f4b9a73 -r e2790efcd306 paper/conclusion.tex
--- a/paper/conclusion.tex	Tue Feb 17 05:07:25 2015 +0900
+++ b/paper/conclusion.tex	Tue Feb 17 07:10:20 2015 +0900
@@ -17,7 +17,7 @@
 また、より高い性能を持つ計算機で測定したところ、速度の向上を確認できた。
 
 OpenCL と CUDA を用いて GPGPU への対応を行った。
-WordCount による測定を行ったが、データ並列実行をサポートすることで飛躍的な性能を確認できた。
+WordCount による測定を行い、データ並列実行をサポートすることで OpenCL や CUDA と同等な性能を確認できた。
 SIMD 型であることやループ命令を苦手とするといった理由から、
 GPU における演算はデータ並列による実行をサポートしなければ性能が出ない事がわかった。
 Cerium においてプログラマは Task を記述し、
@@ -33,6 +33,13 @@
 どのような状況でより性能を発揮できるのか考察を行った。
 
 \section{今後の課題}
+Sort、WordCount、FFT と様々なベンチマークを行ったが、それぞれ Task 生成部分の記述が煩雑になるという問題が発生した。
+例題によって Task を大量に生成する事があるが、生成と実行を一括で行ってしまうとデータがメモリを圧迫してしまい、
+性能低下に繋がる。そこで Task をある一定の分割数で区切り、徐々に実行していく必要がある。
+これを Task 間の依存関係で記述するのだが、この記述が原因でコードの量が増えてしまっている。
+OpenCL では、MemoryBuffer の依存関係により暗黙的に Task 間で依存関係を設定することで Data Dependency を実現している。
+Cerium でも Data Dependency を導入することにより、プログラマへの負担を減らすことができると考えられる。
+
 Cerium による GPGPU に関して、さらなる性能向上が見込める。
 今回のベンチマークで、 Cerium による GPGPU と OpenCL 単体による GPGPU で、
 Cerium の実行時間が OpenCL の1.01倍と、ほぼ同じ結果になった。
@@ -41,27 +48,9 @@
 パイプラインが適切に機能していないか、別のオーバーヘッドの存在が考えられる。
 FFT 以外にも例題を作成し、オーバーヘッド部分の特定を行う必要がある。
 
-更に、GPGPU の改善案として CPU と GPU の同時実行が考えられる。
-Cerium では Task を CPU と GPU の両方に振り分けることができる。
-Task を CPU で動かす場合と GPU で動かす場合では、
-プラットフォームの得意とする計算が異なる事からも実行速度に差が生じるのは自明である。
-CPU と GPU の両方の資源を活用して Task を実行することで、高い並列度が期待できる。
-
-しかし Task をどの程度どのプラットフォームに振り分ければ良いかというのはあまり自明でない。
-プラットフォームに対する Task の振り分けは、Cerium が自動で Scheduling するのが望ましい。
-基本的には GPU の方がコア数が多いため、優先して Task を振ることになる。
-データの転送がオーバーヘッドとなる際に CPU 側に Task を振ることで並列度の向上が見込める。
-依存関係のある Task を CPU と GPU に分けて振ってしまうとデバイス間の転送が起こり、
-ロックが起きてしまうので注意する必要がある。
-
-【メモ】
-
-マルチコア CPU ：特に無い？
-
-GPGPU : 同時実行の話をいれる？同時実行時のschedulingを課題にする？
-
-io : キャッシュの話。読み込みサイズが一定以上になるとキャッシュが無効になってしまう
-
-新設計：入れるにしてもなにから書こう。CS、DSから？
-
-全体：Cerium を使用したアプリケションも何か欲しい
+マルチコア CPU と GPU において、異なる形式でパイプラインを構築している。
+マルチコア CPU では SchedTask を用いてパイプラインの構築を行ったが、
+GPU 側では CommandQueue を2つ用意し、それを大きいループで回すことで構築した。
+可読性の観点から、GPU 側もマルチコア CPU のように SchedTask によるパイプライニングを行うことが望ましい。
+GPU 用の SchedTask を用意し、read() や write() 部分で OpenCL と CUDA の API を操作する事で実現できる。
+可読性を向上させることはパイプライン部分のデバッグの行いやすさにも繋がる。
diff -r d4be7f4b9a73 -r e2790efcd306 paper/figures/io/firefly/mmap
--- a/paper/figures/io/firefly/mmap	Tue Feb 17 05:07:25 2015 +0900
+++ b/paper/figures/io/firefly/mmap	Tue Feb 17 07:10:20 2015 +0900
@@ -1,16 +1,16 @@
-1  72.0210
-2  38.2868
-3  26.2531
-4  20.1625
-5  16.8262
-6  14.4043
-7  13.3340
-8  10.9571
-9  10.7331
-10  9.7699
-11  8.7039
-12  8.8112
-13  8.4029
-14  8.5982
-15  8.5911
-16  8.1581
+1  71.9002
+2  37.0623
+3  28.7038
+4  19.8610
+5  19.6765
+6  19.5441
+7  19.2140
+8  10.9434
+9  10.7695
+10 10.8514
+11 10.9520
+12 10.7901
+13 10.7404
+14 10.7332
+15 10.7831
+16 10.7639
\ No newline at end of file
diff -r d4be7f4b9a73 -r e2790efcd306 paper/figures/io/firefly/read
--- a/paper/figures/io/firefly/read	Tue Feb 17 05:07:25 2015 +0900
+++ b/paper/figures/io/firefly/read	Tue Feb 17 07:10:20 2015 +0900
@@ -1,16 +1,16 @@
-1  76.0076
-2  42.5188
-3  32.0098
-4  25.9325
-5  23.0371
-6  20.7820
-7  19.4251
-8  17.6166
-9  17.4071
-10 16.7358
-11 15.5244
-12 15.9437
-13 15.6554
-14 15.5874
-15 15.5278
-16 15.2264
+1  75.2987
+2  42.9328
+3  33.8644
+4  26.2916
+5  25.7228
+6  25.7939
+7  25.7141
+8  18.0785
+9  17.8626
+10 18.1409
+11 17.8217
+12 17.9483
+13 17.6048
+14 18.1548
+15 18.2842
+16 17.8321
\ No newline at end of file
diff -r d4be7f4b9a73 -r e2790efcd306 paper/introduciton.tex
--- a/paper/introduciton.tex	Tue Feb 17 05:07:25 2015 +0900
+++ b/paper/introduciton.tex	Tue Feb 17 07:10:20 2015 +0900
@@ -4,7 +4,7 @@
 
 % PCやタブレットの一般的な利用方法として動画の編集や再生、ゲームといったアプリケーションの利用が挙げられる。
 % Rednering や物理演算といった処理から
-プログラムが PC に要求するの処理性能は上がってきているが、
+プログラムが PC に要求する処理性能は上がってきているが、
 %-ゲームや動画再生といったアプリケーションが高水準(？)になるにつれて
 %-高水準:高解像度だったり、ぬるぬる動いたり
 消費電力・発熱・クロックの限界から、 CPU の性能を上げることによる処理性能の向上は難しい。
diff -r d4be7f4b9a73 -r e2790efcd306 paper/master_paper.pdf
Binary file paper/master_paper.pdf has changed