Mercurial > hg > Papers > 2018 > parusu-master

changeset 89:bc7d11285a4a

Find changesets by keywords (author, files, the commit message), revision number or hash, or revset expression.
Fix slide
author Tatsuki IHA <innparusu@cr.ie.u-ryukyu.ac.jp>
date Mon, 12 Feb 2018 14:48:30 +0900
parents 3c127f675c45
children a9885c038bb6
files paper/master_paper.pdf paper/src/cg1.cbc slide/slide.html slide/slide.md
diffstat 4 files changed, 33 insertions(+), 38 deletions(-) [+]
line wrap: on
line diff
Binary file paper/master_paper.pdf has changed
--- a/paper/src/cg1.cbc	Mon Feb 12 12:07:12 2018 +0900
+++ b/paper/src/cg1.cbc	Mon Feb 12 14:48:30 2018 +0900
@@ -1,6 +1,5 @@
 __code cg0(int a, int b) {
     goto cg1(a+b);
-
 }
 
 __code cg1(int c) {
--- a/slide/slide.html	Mon Feb 12 12:07:12 2018 +0900
+++ b/slide/slide.html	Mon Feb 12 14:48:30 2018 +0900
@@ -87,18 +87,17 @@
 <!-- === begin markdown block ===
 
       generated by markdown/1.2.0 on Ruby 2.3.0 (2015-12-25) [x86_64-darwin16]
-                on 2018-02-12 04:41:22 +0900 with Markdown engine kramdown (1.13.2)
+                on 2018-02-12 14:45:13 +0900 with Markdown engine kramdown (1.13.2)
                   using options {}
   -->
 
 <!-- _S9SLIDE_ -->
-<h2 id="section">メタ計算を用いた並列処理</h2>
+<h2 id="section">並列処理の重要性</h2>
 <ul>
   <li>並列処理は現在主流のマルチコアCPU の性能を発揮するには重要なものになっている</li>
   <li>しかし、並列処理のチューニングや信頼性を保証するのは難しい
     <ul>
-      <li>スレッド間の共通資源の競合などの非決定的な実行</li>
-      <li>従来のテストやデバッグではテストしきれない部分が残ってしまう</li>
+      <li>共通資源の競合などの非決定的な実行が発生するため、従来のテストやデバッグではテストしきれない部分が残ってしまう</li>
       <li>GPU などのアーキテクチャに合わせた並列プログラミングの記述</li>
     </ul>
   </li>
@@ -115,7 +114,7 @@
   <li>計算をノーマルレベルとメタレベルに階層化、 信頼性と拡張性をメタレベルで保証する
     <ul>
       <li>並列処理の信頼性を通常の計算(ノーマルレベル) に保証</li>
-      <li>CPU、GPU などの実行環境の切り替え、データ拡張等のを提供</li>
+      <li>CPU、GPU などの実行環境の切り替え、データ拡張等を提供</li>
     </ul>
   </li>
 </ul>
@@ -134,7 +133,7 @@
 </div>
 <div class='slide '>
 <!-- _S9SLIDE_ -->
-<h2 id="code-gear-data-gear">Code Gear、 Data Gear</h2>
+<h2 id="code-geardata-gear">Code Gear/Data Gear</h2>
 <ul>
   <li>Gears OS は Code Gear、 Data Gear という単位で構成される</li>
   <li>Code Gear はプログラムの処理そのものを表す</li>
@@ -208,7 +207,6 @@
 
 <pre lang="c"><code>__code cg0(int a, int b) {
     goto cg1(a+b);
-
 }
 
 __code cg1(int c) {
@@ -226,7 +224,7 @@
   <li>従来のOS のスレッドやプロセスに対応し、以下の要素を定義している
     <ul>
       <li>独立したメモリ空間</li>
-      <li>Code Gear、 Data Gear へのポインタ</li>
+      <li>Code/Data Gear へのポインタ</li>
       <li>並列実行用の Task 情報</li>
       <li>Data Gear の型情報</li>
     </ul>
@@ -268,7 +266,7 @@
 <ul>
   <li>Data Gear にアクセスするにはContext を経由する</li>
   <li>だが、通常の Code Gear では Meta Data Gear である Context の参照は避ける必要がある</li>
-  <li>Gears OS では通常の Code Gear で必要な Data Gear を Context から取り出す stub Code Gear を用意する</li>
+  <li>Gears OS ではメタレベルで通常の Code Gear で必要な Data Gear を Context から取り出す処理を行う stub Code Gear を用意している</li>
 </ul>
 
 <pre lang="c"><code>// normal level Code Gear
@@ -297,7 +295,7 @@
   <li>しかし、 Gears OS を実装するに連れて、 stub Code Gear の記述が煩雑になる場所がでてきた
     <ul>
       <li>Data Gear は番号で指定するため、 Code Gear が どの Data Gear の番号に対応しているかを記述する必要がある</li>
-      <li>自動化するために、同じ番号の Data Gear  を使いまわす問題</li>
+      <li>stub Code Gear を自動生成するために、同じ番号の Data Gear  を使いまわす問題</li>
     </ul>
   </li>
   <li>そのため Gears OS のモジュール化する仕組みとして <strong>Interface</strong> を導入した</li>
@@ -404,7 +402,7 @@
 <h2 id="interface--code-gear-">Interface を利用した Code Gear の呼び出し</h2>
 <ul>
   <li>Interface を利用した Code Gear への継続は <code>goto interface-&gt;method</code> で行われる</li>
-  <li>ここでの <strong>interface</strong>  は Interfaceの型で包んだポインタ、 <strong>method</strong> は実装した Code Gear に対応する</li>
+  <li>ここでの <strong>interface</strong>  は Interfaceの型で包んだData Gear、 <strong>method</strong> は実装した Code Gear に対応する</li>
 </ul>
 
 <pre><code>__code code1() {
@@ -633,8 +631,8 @@
 <h2 id="section-4">並列構文</h2>
 <ul>
   <li>並列実行の Task の生成は新しく Context を生成し、実行する Code Gear、待ち合わせる Input Data Gear の数、Input/Output Data Gear への参照を設定する</li>
-  <li>この記述を直接書くと Meta Data Gear である Context を直接参照しているため、ノーマルレベルでの記述は好ましくない</li>
-  <li>Task の設定の記述は煩雑な記述であるが、並列実行されることを除けば通常の CbC の goto 文と同等である</li>
+  <li>この記述を直接書くと Meta Data Gear である Context を直接参照しているため、ノーマルレベルでの記述では好ましくない</li>
+  <li>Task の設定は煩雑な記述であるが、並列実行されることを除けば通常の CbC の goto 文と同等である</li>
   <li>そこで Context を直接参照しない並列構文、 <strong>par goto</strong> 構文を新たに考案した</li>
   <li>par goto 構文には引数として Input/Output Data Gear等を渡す
     <ul>
@@ -658,9 +656,9 @@
   <li>Gears OS は GPU での実行もサポートする</li>
   <li>GPU で性能を出すためには GPU に合わせた並列プログラミングが必要になる</li>
   <li>今回は CUDA への実行のサポートをおこなった</li>
-  <li>CUDA へ GPU を Device、 CPU を Host として定義する</li>
+  <li>CUDA は GPU を Device、 CPU を Host として定義する</li>
   <li>CUDA は処理の最小の単位を thread とし、それをまとめた block を展開し Device 上で実行されるプログラム(Kernel)を実行する</li>
-  <li>今回 CUDAWorker、CUDAExecutor、 CUDABuffer を使用して CUDA に合わせた Code Gear を提供する</li>
+  <li>今回 CUDAWorker、CUDAExecutor、 CUDABuffer を使用して CUDA に合わせた並列処理機構を提供する</li>
 </ul>
 
 
@@ -709,7 +707,7 @@
     <ul>
       <li>Device にデータ領域を確保するにはサイズの指定が必要</li>
       <li>Data Gear には Meta Data Gear でデータのサイズを持っている</li>
-      <li>だが、Data Gear の要素の中に Data Gear へのポインタがあるとポインタ分でサイズ計算してしまうため、 GPU では参照できなくなってしまう</li>
+      <li>しかし、 Data Gear の要素の中に Data Gear へのポインタがあるとポインタ分でサイズ計算してしまうため、 GPU では参照できなくなってしまう</li>
     </ul>
   </li>
   <li>CUDA Buffer ではそのマッピングを行う
@@ -729,7 +727,7 @@
 <!-- _S9SLIDE_ -->
 <h2 id="cuda--1">CUDA での呼び出し</h2>
 <ul>
-  <li>Gears OS では stub Code Gear で CUDA による実行を切り替える</li>
+  <li>Gears OS では Task で実行される Code Gear の stub Code Gear で CUDA による実行を切り替える</li>
   <li>stub Code Gear で CUDABuffer でのマッピング、 実行する kernel の読み込みを行う</li>
   <li>stub Code Gear は CUDA で実行する際は CUDAExecutor の Code Gear に継続する</li>
 </ul>
@@ -997,12 +995,12 @@
   <li>OpenMP、 Goとの比較から、 Gears OS が 1CPU での動作が遅いということがわかった。
     <ul>
       <li>par goto 文を使用する度に Context を生成するため、 ある程度の時間がかかってしまう</li>
-      <li>モデル検査で par goto の Code Gear のフローを解析し、処理がかる場合は Context を生成セずに関数呼出しを行う等の最適化が必要</li>
+      <li>モデル検査で par goto の Code Gear のフローを解析し、処理がかる場合は Context を生成せずに関数呼出しを行う等の最適化が必要</li>
     </ul>
   </li>
   <li>現在の CUDA 実装では CPU、GPU 間のデータの通信コストがかかってしまうことが例題からわかった
     <ul>
-      <li>Meta Data Gear に Data Gear が CPU、 GPU のどこで所持サれているのかを持たせ、 GPU の Data Gear が CPU で必要になったときに始めてデーの通信を行う</li>
+      <li>Meta Data Gear に Data Gear が CPU、 GPU のどこで所持されているのかを持たせ、 GPU の Data Gear が CPU で必要になったときに始めてデータの通信を行う</li>
     </ul>
   </li>
 </ul>
--- a/slide/slide.md	Mon Feb 12 12:07:12 2018 +0900
+++ b/slide/slide.md	Mon Feb 12 14:48:30 2018 +0900
@@ -4,11 +4,10 @@
 lang: Japanese
 code-engine: coderay
 
-## メタ計算を用いた並列処理
+## 並列処理の重要性
 - 並列処理は現在主流のマルチコアCPU の性能を発揮するには重要なものになっている
 - しかし、並列処理のチューニングや信頼性を保証するのは難しい
-    - スレッド間の共通資源の競合などの非決定的な実行
-    - 従来のテストやデバッグではテストしきれない部分が残ってしまう
+    - 共通資源の競合などの非決定的な実行が発生するため、従来のテストやデバッグではテストしきれない部分が残ってしまう
     - GPU などのアーキテクチャに合わせた並列プログラミングの記述
 
 ## Gears OS
@@ -16,13 +15,13 @@
 - 並列処理の Task を Code Gear と実行するときに必要な Input Data Gear と出力するための Output Data Gear の組で表現される
 - 計算をノーマルレベルとメタレベルに階層化、 信頼性と拡張性をメタレベルで保証する
     - 並列処理の信頼性を通常の計算(ノーマルレベル) に保証
-    - CPU、GPU などの実行環境の切り替え、データ拡張等のを提供
+    - CPU、GPU などの実行環境の切り替え、データ拡張等を提供
     
 ## Gears OS
 - 本研究ではGears OS の並列処理機構、並列処理構文(par goto)の実装、Gears OS を実装するにつれて必要なったモジュール化の導入を行う
 - また、並列処理を行う例題を用いて評価、 OpenMP、 Go 言語との比較を行う
 
-## Code Gear、 Data Gear
+## Code Gear/Data Gear
 - Gears OS は Code Gear、 Data Gear という単位で構成される
 - Code Gear はプログラムの処理そのものを表す
 - Data Gear はデータそのものを表す
@@ -65,7 +64,6 @@
 ``` c
 __code cg0(int a, int b) {
     goto cg1(a+b);
-
 }
 
 __code cg1(int c) {
@@ -77,7 +75,7 @@
 - Context は接続可能な Code/Data Gear の集合を表現する Meta Data Gear
 - 従来のOS のスレッドやプロセスに対応し、以下の要素を定義している
     - 独立したメモリ空間
-    - Code Gear、 Data Gear へのポインタ
+    - Code/Data Gear へのポインタ
     - 並列実行用の Task 情報
     - Data Gear の型情報
 - Gears OS ではメタ計算でこの Context を経由して Data Gear にアクセスする
@@ -106,7 +104,7 @@
 ## stub Code Gear
 - Data Gear にアクセスするにはContext を経由する
 - だが、通常の Code Gear では Meta Data Gear である Context の参照は避ける必要がある
-- Gears OS では通常の Code Gear で必要な Data Gear を Context から取り出す stub Code Gear を用意する
+- Gears OS ではメタレベルで通常の Code Gear で必要な Data Gear を Context から取り出す処理を行う stub Code Gear を用意している
 
 ``` c
 // normal level Code Gear
@@ -129,7 +127,7 @@
 - stub Code Gear は Context から Code Gear と Data Gear の全ての組合せを展開して記述する必要がある
 - しかし、 Gears OS を実装するに連れて、 stub Code Gear の記述が煩雑になる場所がでてきた
     - Data Gear は番号で指定するため、 Code Gear が どの Data Gear の番号に対応しているかを記述する必要がある
-    - 自動化するために、同じ番号の Data Gear  を使いまわす問題
+    - stub Code Gear を自動生成するために、同じ番号の Data Gear  を使いまわす問題
 - そのため Gears OS のモジュール化する仕組みとして **Interface** を導入した
 
 ## Interface
@@ -201,7 +199,7 @@
 
 ## Interface を利用した Code Gear の呼び出し
 - Interface を利用した Code Gear への継続は `goto interface->method` で行われる
-- ここでの **interface**  は Interfaceの型で包んだポインタ、 **method** は実装した Code Gear に対応する
+- ここでの **interface**  は Interfaceの型で包んだData Gear、 **method** は実装した Code Gear に対応する
 
 ```
 __code code1() {
@@ -355,8 +353,8 @@
 
 ## 並列構文
 - 並列実行の Task の生成は新しく Context を生成し、実行する Code Gear、待ち合わせる Input Data Gear の数、Input/Output Data Gear への参照を設定する
-- この記述を直接書くと Meta Data Gear である Context を直接参照しているため、ノーマルレベルでの記述は好ましくない
-- Task の設定の記述は煩雑な記述であるが、並列実行されることを除けば通常の CbC の goto 文と同等である
+- この記述を直接書くと Meta Data Gear である Context を直接参照しているため、ノーマルレベルでの記述では好ましくない
+- Task の設定は煩雑な記述であるが、並列実行されることを除けば通常の CbC の goto 文と同等である
 - そこで Context を直接参照しない並列構文、 **par goto** 構文を新たに考案した
 - par goto 構文には引数として Input/Output Data Gear等を渡す
     - スクリプトによって Code Gear の Input/Output の数を解析する
@@ -372,9 +370,9 @@
 - Gears OS は GPU での実行もサポートする
 - GPU で性能を出すためには GPU に合わせた並列プログラミングが必要になる
 - 今回は CUDA への実行のサポートをおこなった
-- CUDA へ GPU を Device、 CPU を Host として定義する
+- CUDA は GPU を Device、 CPU を Host として定義する
 - CUDA は処理の最小の単位を thread とし、それをまとめた block を展開し Device 上で実行されるプログラム(Kernel)を実行する
-- 今回 CUDAWorker、CUDAExecutor、 CUDABuffer を使用して CUDA に合わせた Code Gear を提供する
+- 今回 CUDAWorker、CUDAExecutor、 CUDABuffer を使用して CUDA に合わせた並列処理機構を提供する
 
 ## CUDAWorker
 - CUDA で実行する Task を受け取る Worker
@@ -402,7 +400,7 @@
 - Host、Device 間でデータのやり取りをする際、 Gears OS での Data Gear をDevice 用にマッピングする必要がある
     - Device にデータ領域を確保するにはサイズの指定が必要
     - Data Gear には Meta Data Gear でデータのサイズを持っている
-    - だが、Data Gear の要素の中に Data Gear へのポインタがあるとポインタ分でサイズ計算してしまうため、 GPU では参照できなくなってしまう
+    - しかし、 Data Gear の要素の中に Data Gear へのポインタがあるとポインタ分でサイズ計算してしまうため、 GPU では参照できなくなってしまう
 - CUDA Buffer ではそのマッピングを行う
     - このマッピングは Task の stub Code Gear で行われる
 
@@ -411,7 +409,7 @@
 </div>
 
 ## CUDA での呼び出し
-- Gears OS では stub Code Gear で CUDA による実行を切り替える
+- Gears OS では Task で実行される Code Gear の stub Code Gear で CUDA による実行を切り替える
 - stub Code Gear で CUDABuffer でのマッピング、 実行する kernel の読み込みを行う
 - stub Code Gear は CUDA で実行する際は CUDAExecutor の Code Gear に継続する
 
@@ -606,6 +604,6 @@
     - モデル検査は CbC で記述された モデル検査器である akasha を使用して行う。 モデル検査の方針としては Code Gear の並列実行を擬似並列で実行し、全ての組合せを列挙する方法で行う
 - OpenMP、 Goとの比較から、 Gears OS が 1CPU での動作が遅いということがわかった。 
     - par goto 文を使用する度に Context を生成するため、 ある程度の時間がかかってしまう
-    - モデル検査で par goto の Code Gear のフローを解析し、処理がかる場合は Context を生成セずに関数呼出しを行う等の最適化が必要
+    - モデル検査で par goto の Code Gear のフローを解析し、処理がかる場合は Context を生成せずに関数呼出しを行う等の最適化が必要
 - 現在の CUDA 実装では CPU、GPU 間のデータの通信コストがかかってしまうことが例題からわかった
-    - Meta Data Gear に Data Gear が CPU、 GPU のどこで所持サれているのかを持たせ、 GPU の Data Gear が CPU で必要になったときに始めてデーの通信を行う
+    - Meta Data Gear に Data Gear が CPU、 GPU のどこで所持されているのかを持たせ、 GPU の Data Gear が CPU で必要になったときに始めてデータの通信を行う