Binary file Paper/anatofuz.pdf has changed

--- a/Paper/anatofuz.tex	Tue Nov 27 15:22:57 2018 +0900
+++ b/Paper/anatofuz.tex	Tue Nov 27 16:12:50 2018 +0900
@@ -256,7 +256,7 @@
 今回はファイルを231Kと3GBの二種類用意し, どの様な違いが出るのか測定した．
 
 測定した環境は次の通りである．
-今回は現在広く使用されているスクリプト言語であるPython, Perl5
+今回は現在広く使用されているスクリプト言語であるPerl5を計測対象に追加した．
 またRakudoの処理系による処理時間の差を計測する為にMoarVM, JVMに構築したPerl6の処理速度を計測を行った．
 JVM自体の処理時間とRakudoを構築したJVMの速度の差を見るために, 同様のプログラムをJava10でも行った.
 
@@ -272,9 +272,9 @@
 
 \begin{table}[htb]
 \begin{tabular}{|l|c|c|c|c|c|} \hline
-   FileSize & MoarVM & Perl6 on JVM & Python3 & Java & Perl5\\  \hline
-   231K & 0.86 & 21.48 & 0.06 & 0.27 & 0.04 \\ 
-   3G &  2331.08 & 1665.56 & 101.16 & 48.85 & 41.35\\ \hline
+   FileSize & MoarVM & Perl6 on JVM &  Java & Perl5\\  \hline
+   231K & 0.86 & 21.48  & 0.27 & 0.04 \\ 
+   3G &  2331.08 & 1665.56 &  48.85 & 41.35\\ \hline
 \end{tabular}
 \end{table}
 
@@ -425,6 +425,14 @@
 これはJavaのinterface, Haskellの型クラスに該当する概念であり, 次のCodeGearにInterface経由で継続する事が可能である．
 Interfaceは現在のCbCMoarVMの実装には用いていないが, 今後ThreadedCodeの実装を行うにあたり命令コードディスパッチ箇所に導入を検討している．
 
+\subsection{他手法との比較}
+本稿ではPerl6処理系の改良としてCbCを用い, 初期の実装を行った．
+CbCを用い無い場合のMoarVMの改良方法としては, 命令コードに対応する処理をCの関数として記述し, この関数のポインタを利用する方法が考えられる．
+関数ポインタの配列を作成し, 次の命令コードに対応する関数をポインタ経由で実行する．
+Cの関数ポインタを利用した場合, CbCと同様に処理のモジュール化は可能である．
+しかし, CbCとは違い軽量継続ではなく関数呼び出しで処理をする為, Cのスタックフレームが非常に巨大になる．
+Cの関数呼び出しのコストから, 通常のcase文やラベルジャンプを利用した場合と速度差的に優位にならない．
+
 \section{MoarVMのデバッグ}
 
 MoarVM自体のデバッグはMoarVMのリポジトリにテストコードが付随していない為単体では実行不可能である．
@@ -493,13 +501,6 @@
 また現在はclang上に実装したCbCコンパイラではCodeGear内部のtaill call除去のエラーが発生してしまう為コンパイルする事が出来ない．
 その為現在はgcc上に実装したcbcコンパイラを利用しgdbを利用しデバッグを行う．
 
-\subsection{他手法との比較}
-本稿ではPerl6処理系の改良としてCbCを用い, 初期の実装を行った．
-CbCを用い無い場合のMoarVMの改良方法としては, 命令コードに対応する処理をCの関数として記述し, この関数のポインタを利用する方法が考えられる．
-関数ポインタの配列を作成し, 次の命令コードに対応する関数をポインタ経由で実行する．
-Cの関数ポインタを利用した場合, CbCと同様に処理のモジュール化は可能である．
-しかし, CbCとは違い軽量継続ではなく関数呼び出しで処理をする為, Cのスタックフレームが非常に巨大になる．
-Cの関数呼び出しのコストから, 通常のcase文やラベルジャンプを利用した場合と速度差的に優位にならない．