# HG changeset patch
# User Yuhi TOMARI <yuhi@cr.ie.u-ryukyu.ac.jp>
# Date 1424215788 -32400
# Node ID a63c2d9d7db9e733c4d701ba6129aec73a516073
# Parent  23baf2b3eff670c91c7c9cb11b1ababfb960628c
fix slide

diff -r 23baf2b3eff6 -r a63c2d9d7db9 slide/blank.html
--- a/slide/blank.html	Wed Feb 18 03:49:04 2015 +0900
+++ b/slide/blank.html	Wed Feb 18 08:29:48 2015 +0900
@@ -120,10 +120,10 @@
           クロックの性能を上げるのではなく、コア数を増やす事でパフォーマンスを向上させている。
         </p>
         <p>
-          マルチコア CPU や GPU といった<font color="red">マルチコアプラットフォーム</font>なアーキテクチャ上で
+          マルチコア CPU や GPU といった<font color="red">マルチプラットフォーム</font>なアーキテクチャ上で
           リソースを有効活用するには、それぞれのプラットフォームに最適な形でプログラムを並列に動作させる必要がある。
         </p>
-        <p>しかしこれらのチューニングは複雑で、コーディング時に毎回行うと複雑さや拡張性の問題がある。</p>
+        <p>しかしこれらのチューニングは複雑で、コーディング時に毎回行うと煩雑さや拡張性の問題がある。</p>
       </div>
 
 
@@ -136,12 +136,11 @@
         <ul>
           <li>パイプライニングによる Task の並列実行</li>
           <li>OpenCL、CUDA を用いた GPGPU 対応</li>
-          <li>データ並列実行</li>
-          <li>並列処理むけのI/O</li>
+          <li>データ並列実行のサポート</li>
+          <li>並列処理むけのI/Oの実装</li>
         </ul>
         <p>
-          Sort、WordCount、FFT といった例題を元に、これら Cerium の並列実行機構が
-          マルチプラットフォームにおける並列プログラミングで有効に作用することを示す。
+          Sort、WordCount、FFT といった例題を元に測定・評価を行った。
         </p>
       </div>
 
@@ -153,7 +152,10 @@
         <div align="center">
           <img src="./images/cerium_image.png" width="700">
         </div>
-        <p>Cerium を用いることでマルチコア CPU と GPU において Scheduling を含めたプログラミングを可能となる。</p>
+        <p>
+          Cerium はマルチコア CPU と GPU における Scheduling をサポートし、
+          より並列度の高いプログラミングを可能とする。
+        </p>
       </div>
 
       <div class='slide'>
@@ -172,7 +174,6 @@
 
     // create task
     HTask* multiply = manager->create_task(MULTIPLY_TASK);
-    multiply->set_cpu(spe_cpu);
 
     // set indata
     multiply->set_inData(0, i_data1, sizeof(float) * length);
@@ -238,8 +239,8 @@
           これは生成しただけで Task そのものがメモリを圧迫してしまっていることが原因となる。
         </p>
         <p>
-          そういった 例題において、Task は一定数ずつ徐々に生成/実行する必要がある。
-          ということは、Block 間で依存関係を設定する必要がある。
+          一般的な並列処理において、Task は一定数ずつ徐々に生成/実行する必要がある。
+          ということは Task 間で wait が入るため、Task の Block 間で依存関係を設定する必要がある。
           依存関係について Cerium の Bitonic Sort を例題に考える。
         </p>
       </div>
@@ -406,7 +407,7 @@
         <h2>iterate API</h2>
         <p>
           データ並列による実行を行う場合、一つの記述から複数のTaskを生成する必要がある。
-          生成した各TaskにIDとinput/output dataを割り当てる「iterate」というAPIを実装した。
+          データ並列用の Task を生成する「iterate」というAPIを実装した。
         </p>
 
         <table>
@@ -448,7 +449,7 @@
 }
         </pre>
       <p>get_param によって自分の担当する index を取得し、担当範囲のみを計算する。</p>
-      <p>データ並列実行する場合、各Task に Input/Outpu を設定するのではなく、
+      <p>データ並列実行する場合、各Task に Input/Output を設定するのではなく、
         全ての Task でデータを共有する。共有したデータの自分の担当する箇所にのみ計算を行う。
         そのため少ないコピーにおさえることができる。
       </p>
@@ -495,7 +496,7 @@
         </ul>
         <p>
            CommandQueue と呼ばれる機構を用いてこういった GPU を制御するための処理を行っていく。
-           CommandQueue に命令を起こるためのしくみで、制御は全てこの Queue を介して行われる。
+           CommandQueue は GPU に命令を送るためのしくみで、制御は全てこの Queue を介して行われる。
         </p>
         <p>これらはRead, Exec、Write に対応する。
           GPGPU 用の Scheduler でもパイプラインを構成する。</p>
@@ -570,7 +571,7 @@
         <h2>並列処理向け I/O</h2>
         <p>
           ファイルの読み込みなどの I/O を含むプログラムは、
-          読み込み時間が Task のと比較してオーバーヘッドになることが多い。
+          読み込み時間が Task と比較してオーバーヘッドになることが多い。
           プログラムの並列化を行ったとしても I/O がボトルネックになってしまうと処理は高速にならない。
         </p>
         <p>並列計算と同時に動作する、並列 I/O の実装を行った。</p>
@@ -627,7 +628,7 @@
         </p>
         <p>ファイルを分割して読み込み、
           読み込んだファイルに対して WordCount を行う一定数のTask(BlockedTask)を割り当てる。
-          Task には依存関係を設定する必要があり、図のTask n+1 はTask nを待つ必要がある。
+          Task には依存関係を設定する必要があり、図のTask n+1 はBlocked File2 の読み込みを待つ必要がある。
         </p>
         <p>まだ読み込みが終了していない領域に割り当てられた Task が起動してしまう事を防ぐためである。</p>
         <p>この wait によるロックはオーバーヘッドとなるため、なるべく発生しないことが望ましい。</p>
@@ -637,7 +638,7 @@
         <h2>I/O 専用のThread</h2>
         <p>
           BlockedRead の依存関係による wait はなるべく発生しないことが望ましい。
-          そのため、BlockedRead は連続で Task の起動を行う必要がある。
+          そのため、BlockedRead は連続で ReadTask の起動を行う必要がある。
         </p>
         <p>
           Cerium には SPE_ANY という Thread があり、この Thread で Task の実行を行うと自動で実行するコアを割り振る。
@@ -667,7 +668,7 @@
 
       <div class='slide'>
         <h2>実験環境</h2>
-        <table border="0" >
+        <table border="0" style="font-size:25px;">
           <tr bgcolor="palegreen">
             <th align="center">Model</th><th align="center">MacPro Mid 2010</th>
           </tr>
@@ -689,7 +690,7 @@
           </tr>
         </table>
         <hr>
-        <table border="0" >
+        <table border="0" style="font-size:25px;">
           <tr bgcolor="palegreen">
             <th align="center">Model</th><th align="center">MacPro Late 2013</th>
           </tr>
@@ -821,7 +822,7 @@
             <th>
               <p>
                 Cerium の従来の読み込み方式である mmap、一般的な file open である read、
-                更に今回実装した BlocledRead の測定を行った。
+                更に今回実装した BlockedRead の測定を行った。
                 BlockedRead に関しては io Thread を使用した場合(BlockedRead_io)と、
                 使用しない場合(BlockedRead_speany)の測定を行う。
               </p>