--- a/Slide/Slide.md	Sun Feb 16 18:20:36 2020 +0900
+++ b/Slide/Slide.md	Sun Feb 16 20:49:19 2020 +0900
@@ -1,15 +1,14 @@
-title: Perl6(Raku)のサーバーを使った高速実行
+title: Raku(Perl6)のサーバーを使った高速実行
 author: Kouki Fukuda, Shinji Kono
-profile: 琉球大学
+profile: 並列信頼研
 
 ## スクリプト言語の高速実行
  - 現在多くのスクリプト言語はインタプリタ型言語であり, 実行時にインタプリタの立ち上げ, モジュールを読み込み, スクリプトの解釈, スクリプトの実行 といったような処理を担っている.
- - これらの処理の中にはOS上で事前に行うことで, より起動時間, 及び処理時間の短縮が予想される.
  - 頻繁にコードを書き換え実行するスクリプト言語では起動時間をできるだけ短くしたい.
  - その手法として同一ホスト内で終了せずに実行を続けるサーバープロセスを立ち上げ, このサーバープロセス上で立ち上げておいたコンパイラに実行するファイル名を転送し, サーバー上でコンパイルを行う手法を提案する
  - この提案手法に沿って『Abyss サーバー』を実装した.
- - またスクリプト言語の速度改善を行うにあたり, 本研究では Raku というスクリプト言語を用いた. 
 
+## 
 <!-- 
 ## 研究概要
 - Raku の実装の一つであるRakudoは、Byte code である MoarVM と、それ上で動作する Raku のsubsetであるnqp (Not Quite Perl)上に構成されている。
@@ -19,13 +18,15 @@
 
 ## Raku と他言語の起動時間の比較
 - Raku と他言語の起動時間の比較行なった.
+
+<!--
 - 実行環境
-
 ```
 macOS Mojave version 10.14.5
 メモリ8GB
 プロセッサ2.7GHz Intel Core i5
 ```
+-->
 
 - perl5,ruby,raku,pythonでhelloworldを出力するプログラムを用いて行なった実行結果である.
 <table style="border-collapse: collapse;" border="1" width="400" height="300">
@@ -81,10 +82,12 @@
 - NQP は MoarVM や JVMの違いを吸収してAPIを提供している
 -->
 
+<!--
 ## MoarVM
 - MoarVM は Raku に特化したVM 
 - C 言語で実装されている
 - JIT コンパイルなどが現在導入されているが, 起動時間などが低速である問題がある
+-->
 
 <!--
 ## Perl6 の名称変更
@@ -100,10 +103,9 @@
 
 ## Rakuが遅い理由
 - 通常 Ruby のようなスクリプト言語ではまず YARV などのプロセスVM が起動し,その後スクリプトを Byte code に変換して実行という手順を踏む.
-- 
 - Rakudo はインタプリタの起動時間及び, 全体的な処理時間が他のスクリプト言語と比較して低速である.
 - これは Rakudo 自体が Raku と NQP で書かれているため, MoarVMを起動し, Rakudo と NQP のByte codeを読み取り, Rakudoを起動し, その後スクリプトを読み取り, スクリプトの Byte code 変換というような手順で進むためである.
-- また Raku は実行時の情報が必要であり, メソッドを実行する際に invoke が走ることも遅い原因である.
+- また Raku は実行する際に実行時の情報が必要であり, メソッドを実行する際に invoke が走ることも遅い原因である.
     - invoke はMoarVM の method 呼び出しのbyte codeです.
 
 ## Raku による Abyss Server の実装
@@ -138,13 +140,9 @@
 
 - 通常実行
     - 0.2695 sec
-    - 0.2131 sec
-    - 0.3143 sec
 
 - 提案手法
     - 0.0238 sec
-    - 0.0219 sec
-    - 0.0275 sec
 
 - 提案手法は通常実行に比べて約10倍早い実行結果になった
 
@@ -190,16 +188,14 @@
     }
 
     $listen.close;
-}}
+}
 ```
 
 ## Abyss Client側の実装
 - ユーザーは Abyss Server を起動後,ファイルパスをサーバーに送信する.
 
 ```
-use IO::Socket::Unix;
-
-my $conn = IO::Socket::INET.new( :host<localhost>,
+my $conn = IO::Socket::Unix.new( :host<localhost>,
                                  :port(3333) );
 
 $conn.print: 'Absolute file path';
@@ -215,7 +211,6 @@
 say $sock_msg;
 ```
 
-<!--
 ## Raku のEVAL
 - Raku では EVAL 関数があり文字列を Raku のソースコード自身として評価できる
 - Raku では, EVAL は通常は使用できないようになっており, MONKEY-SEE-NO-EVAL という pragma を実行することで使うことができるようになる.
@@ -227,7 +222,6 @@
 ```
 
 - EVALFILEはファイルパスを受け取ると, ファイルの中身をバイト文字列に変換し, それをEVALと同様に解釈する.
--->
 
 ## Abyss Serverの利点
 - Abyss Serverを用いて実行することで, サーバー上で事前に起動した Rakudo を再利用し, 投げられた Raku スクリプトの実行を行うため, Rakudo の起動時間を短縮できる.
@@ -239,15 +233,20 @@
 ## Abyss Serverの欠点
 - 現在 Abyss Server には 一度スクリプトを実行した後にサーバー内の環境をリセットする機能が存在しないため,スクリプトがサーバー内の環境に影響を及ぼした場合,通常実行と違う挙動をする危険性がある
 - 同時に二つ以上のタスクを与えられると実行順のスケジューリングができない
-    - 与えられた順番に処理していく
 - 異常に長いタスクが投げられた場合, 次のタスクが前のタスクが終わるまで実行ができない
 - 起動時のオプションが選択出来ない
 
 ## OS上でスクリプト言語を実行する方法の改善点
-- 
+- OS上でスクリプト言語を実行する際の最適な方法として,提案手法のように事前に起動したコンパイラを再利用する方法は有効であると考える
+- またOS上でスクリプト言語を実行する際に, OS側で用意されてあるべきAPIとしては以下のようなものが挙げられる
+    - 提案手法のように一度立ち上げられたインタプリタを立ち上げたままにする
+    - 複数回投げられたスクリプトの実行結果もしくはbasic block を保存できる
+    - 実行するスクリプトの周りにあるJsonファイルをあらかじめParseしておく
 
 ## まとめと今後の課題
-- Raku の新たな実行方法の提案,及び実装を行なった.
+- スクリプト言語 Raku の新たな実行方法の提案,及び提案手法に添って「Abyss Server」の実装を行なった.
 - Raku にUnix domain socket の実装を行なった.
-- Raku の速度改善において, 同一ホスト内でサーバープロセスを生成し,サーバープロセス内であらかじめコンパイラを立ち上げて起き, 実行するファイル名を転送し,サーバープロセス上でコンパイルを行う手法は有効であると考えられる
-- 今後は一度投げられたスクリプトをキャッシュで保存しておき,再度実行する際に,そのキャッシュを用いてコンパイル時間を省くような仕組みを入れて開発を進めたいです.
+- Raku を用いて「Abyss Server」の実装を行なった
+- また今後今後の課題としては以下のようなものが挙げられる
+    - 一度投げられたスクリプトをキャッシュで保存しておき,再度実行する際に,そのキャッシュを用いてコンパイル時間を省くような仕組み
+    - 複数タスクが投げられた場合の処理の実装