--- a/paper/abstract.tex	Tue Feb 17 14:13:45 2015 +0900
+++ b/paper/abstract.tex	Tue Feb 17 14:14:22 2015 +0900
@@ -5,12 +5,7 @@
 
 マルチコア CPU は SynchronizedQueue 、 GPU は OpenCL と CUDA により実装した。
 データ並列実行をサポートすることで GPGPU を行う際に高い並列度を維持することを可能にした。
-
-また、Cerium ではファイル読み込みを mmap で実装していたが、 Blocked Read による並列処理向けの I/O の実装を行った。
-
-計算部分だけでなく、I/O 部分も Cerium を用いて並列に処理することでオーバーヘッドの改善が見込める。
-
-Sort、WordCount 、FFT の例題を元に測定を行い、
-追加した機能がマルチプラットフォームにおける並列プログラミングで有効に作用することを示した。
+また、Cerium ではファイル読み込みを mmap  及び専用スレッドを用いる方法で十分な性能が出ることを示した。
+Sort、WordCount 、FFT の例題を元に測定評価を行った。
 
 \end{abstract}

--- a/paper/abstract_eng.tex	Tue Feb 17 14:13:45 2015 +0900
+++ b/paper/abstract_eng.tex	Tue Feb 17 14:14:22 2015 +0900
@@ -1,16 +1,7 @@
 \begin{abstract_eng}
-Cerium is a parallel programming framework.
-Cerium was programming framework for Cell Broad band Engine.
-We supported Multi-platform, it was more improved to the general purpose framework.
-
-To achieve Multi-core CPU support using SyncronizedQueue, and GPGPU support using OpenCL and CUDA.
-Cerium was improved parallelism by supporting data parallel execution.
-
-Cerium's file read was implemented by mmap.
-We have implemented the I/O of parallel processing by BlockedRead.
-In addition, not only the calculation part, 
-We expected an improvement in overhead by parallel processing in the I/O part using Cerium.
-
-We evaluate example Sort, Word count, and FFT,
-and indicates that the added functions is effective in parallel programming on Multi-platform.
+Cerium is a parallel programming framework, which originally designed to work on Cell Broad band engine.
+We add Multi-platform supports which includes  Many core, GPGPU.
+GPGPU part uses OpenCL or CUDA and it support multi dimensional computation i.e. data parallel computation on GPGPU.
+We also improve I/O for parallel processing using a separate I/O thread.
+We evaluate Cerium by Sort, Word count, and FFT.
 \end{abstract_eng}

--- a/paper/chapter1.tex	Tue Feb 17 14:13:45 2015 +0900
+++ b/paper/chapter1.tex	Tue Feb 17 14:14:22 2015 +0900
@@ -1,4 +1,4 @@
-\chapter{既存のマルチプラットフォームフレームワーク}
+\chapter{既存のマルチプラットフォーム\\フレームワーク}
 マルチプラットフォームでプログラムを動作させる場合、そのアーキテクチャを意識する必要がある。
 マルチプラットフォームにはマルチコア CPU 、 GPU や Cell といったヘテロジニアスマルチコアのような
 様々な構成がある。

--- a/paper/chapter2.tex	Tue Feb 17 14:13:45 2015 +0900
+++ b/paper/chapter2.tex	Tue Feb 17 14:14:22 2015 +0900
@@ -1,9 +1,9 @@
-\chapter{並列プログラミングフレームワーク Cerium}
+\chapter{並列プログラミング\\フレームワーク Cerium}
 Cerium は、当初 Cell 用の Fine-Grain TaskManager として当研究室で開発された。
 本章では Cerium の実装について説明する。
 
 \section{Cerium の概要}
-Cerium は当初 Cell 用であったが、現在では Linux、 MaxOS X上で動作する。
+Cerium は当初 Cell 用であったが、現在では Linux、 MacOS X上で動作する。
 GPGPU の Data Parallel を含めて同じ形式で記述できる。
 
 CeriumはTaskManager、 SceneGraph、Rendering Engine の3つの要素から構成される。

--- a/paper/chapter6.tex	Tue Feb 17 14:13:45 2015 +0900
+++ b/paper/chapter6.tex	Tue Feb 17 14:14:22 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]

--- a/paper/conclusion.tex	Tue Feb 17 14:13:45 2015 +0900
+++ b/paper/conclusion.tex	Tue Feb 17 14:14:22 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 を操作する事で実現できる。
+可読性を向上させることはパイプライン部分のデバッグの行いやすさにも繋がる。

--- a/paper/figures/io/firefly/mmap	Tue Feb 17 14:13:45 2015 +0900
+++ b/paper/figures/io/firefly/mmap	Tue Feb 17 14:14:22 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

--- a/paper/figures/io/firefly/read	Tue Feb 17 14:13:45 2015 +0900
+++ b/paper/figures/io/firefly/read	Tue Feb 17 14:14:22 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

--- a/paper/introduciton.tex	Tue Feb 17 14:13:45 2015 +0900
+++ b/paper/introduciton.tex	Tue Feb 17 14:14:22 2015 +0900
@@ -1,10 +1,10 @@
-\chapter{マルチプラットフォームなフレームワークにおける並列プログラミング}
+\chapter{マルチプラットフォームな\\フレームワークにおける\\並列プログラミング}
 \pagenumbering{arabic} 
 % 動画の編集や再生、ゲームといったPCやタブレット等の端末でできる事・やりたい事が増えてきている。
 
 % PCやタブレットの一般的な利用方法として動画の編集や再生、ゲームといったアプリケーションの利用が挙げられる。
 % Rednering や物理演算といった処理から
-プログラムが PC に要求するの処理性能は上がってきているが、
+プログラムが PC に要求する処理性能は上がってきているが、
 %-ゲームや動画再生といったアプリケーションが高水準(？)になるにつれて
 %-高水準:高解像度だったり、ぬるぬる動いたり
 消費電力・発熱・クロックの限界から、 CPU の性能を上げることによる処理性能の向上は難しい。

Binary file paper/master_paper.pdf has changed

--- a/paper/master_paper.toc	Tue Feb 17 14:13:45 2015 +0900
+++ b/paper/master_paper.toc	Tue Feb 17 14:14:22 2015 +0900
@@ -1,11 +1,11 @@
-\contentsline {chapter}{\numberline {第1章}マルチプラットフォームなフレームワークにおける並列プログラミング}{1}
-\contentsline {chapter}{\numberline {第2章}既存のマルチプラットフォームフレームワーク}{3}
+\contentsline {chapter}{\numberline {第1章}マルチプラットフォームな\\フレームワークにおける\\並列プログラミング}{1}
+\contentsline {chapter}{\numberline {第2章}既存のマルチプラットフォーム\\フレームワーク}{3}
 \contentsline {section}{\numberline {2.1}GPU/Cell の Architecture}{3}
 \contentsline {section}{\numberline {2.2}OpenCL}{5}
 \contentsline {section}{\numberline {2.3}CUDA}{6}
 \contentsline {section}{\numberline {2.4}StarPU}{6}
 \contentsline {section}{\numberline {2.5}Cell Broadband Engine}{7}
-\contentsline {chapter}{\numberline {第3章}並列プログラミングフレームワーク Cerium}{8}
+\contentsline {chapter}{\numberline {第3章}並列プログラミング\\フレームワーク Cerium}{8}
 \contentsline {section}{\numberline {3.1}Cerium の概要}{8}
 \contentsline {section}{\numberline {3.2}Cerium TaskManager}{8}
 \contentsline {section}{\numberline {3.3}Cerium における Task}{10}