Mercurial > hg > Papers > 2015 > yuhi-master

changeset 44:edf3a38f96d8

Find changesets by keywords (author, files, the commit message), revision number or hash, or revset expression.
fix introduction
author Yuhi TOMARI <yuhi@cr.ie.u-ryukyu.ac.jp>
date Mon, 16 Feb 2015 19:15:37 +0900
parents 20d5ad074628
children 7ad011a9b010
files paper/chapter6.tex paper/conclusion.tex paper/introduciton.tex
diffstat 3 files changed, 9 insertions(+), 8 deletions(-) [+]
line wrap: on
line diff
--- a/paper/chapter6.tex	Mon Feb 16 18:51:39 2015 +0900
+++ b/paper/chapter6.tex	Mon Feb 16 19:15:37 2015 +0900
@@ -86,7 +86,7 @@
 Cerium において、 WordCount で必要な Task を全て生成してしまうと、
 その Task のデータ構造自体がメモリを消費してしまう。
 そこである程度の量の Task を起動し、それが終了してから(正確には終了する前に)次の Task を生成するようになっている。
-それらの機能を持った関数が6行目にあたる run\_tasks である。
+それらの機能を持った関数が6行目にあたる runTask である。
 run\_tasks に wait\_for による ReadTask との待ち合わせの処理を入れれば良い。
 
 BlockedRead の Task をいかに示す。
--- a/paper/conclusion.tex	Mon Feb 16 18:51:39 2015 +0900
+++ b/paper/conclusion.tex	Mon Feb 16 19:15:37 2015 +0900
@@ -48,8 +48,9 @@
 Task を CPU で動かす場合と GPU で動かす場合では、
 プラットフォームの得意とする計算が異なる事からも実行速度に差が生じるのは自明である。
 CPU と GPU の両方の資源を活用して Task を実行することで、高い並列度が期待できる。
+
 しかし Task をどの程度どのプラットフォームに振り分ければ良いかというのはあまり自明でない。
-プラットフォームに対する Task の振り分けるは、Cerium が自動で Scheduling するのが望ましい。
+プラットフォームに対する Task の振り分けは、Cerium が自動で Scheduling するのが望ましい。
 基本的には GPU の方がコア数が多いため、優先して Task を振ることになる。
 データの転送がオーバーヘッドとなる際に CPU 側に Task を振ることで並列度の向上が見込める。
 依存関係のある Task を CPU と GPU に分けて振ってしまうとデバイス間の転送が起こり、
@@ -61,7 +62,7 @@
 
 GPGPU : 同時実行の話をいれる？同時実行時のschedulingを課題にする？
 
-io : キャッシュの話。読み込みサイズが一定以上になるとキャッシュが無効になる。なんで？みたいな流れ
+io : キャッシュの話。読み込みサイズが一定以上になるとキャッシュが無効になってしまう
 
 新設計：入れるにしてもなにから書こう。CS、DSから？
 
--- a/paper/introduciton.tex	Mon Feb 16 18:51:39 2015 +0900
+++ b/paper/introduciton.tex	Mon Feb 16 19:15:37 2015 +0900
@@ -24,11 +24,10 @@
 Cerium の開発を行った。
 
 Cerium では Task という単位で処理を記述し、それらは並列に実行される。
-プログラマは Task 間の依存関係を設定するだけでパイプラインが構成され、高い並列度を維持した実行が可能となる。
+プログラマが Task 間の依存関係を設定するとパイプラインが構成され、高い並列度で実行される。
 プログラマが生成した Task は TaskManager に送信され、設定した依存関係の解決を行った後、 Scheduler に送信される。
-Scheduler がパイプラインの機構を持っており、Task はパイプラインに沿って実行されている。
+Scheduler がパイプラインの機構を持っており、Task はそのパイプラインに沿って実行される。
 Scheduler が受信した Task は既に TaskManager が依存関係を解決しているため、実行順序は任意で良い。
-そのため、パイプラインによる実行が可能となっている。
 
 計算機において並列処理を行うための設計様式として、1つの命令を同時に複数のデータに適用し、並列に処理する方式がある。
 これをSIMD と呼ぶ。
@@ -37,8 +36,9 @@
 
 Cerium においてプログラマは Task を記述し、Input データを用意した後はデータ並列用の API で Task を spawn するだけで
 データ並列実行することができる。
-TaskManager はプログラマが記述した単一の Task を複数生成し、受け取ったデータ(Input)に対しその Task を割り当てる。
-生成した Task を並列実行する事でデータ並列実行を実現した。
+TaskManager はプログラマが記述した単一の Task を複数生成し、
+受け取ったデータ(Input/Output)に対しその Task を割り当てる。
+生成した復数の Task を並列実行する事でデータ並列実行を実現した。
 
 Sort 、Word Count 、FFT の例題を元に、
 Cerium の持つ並列実行機構がマルチプラットフォームにおける並列プログラミングで有効に作用する事を示す。