Mercurial > hg > Papers > 2020 > koo-thesis
changeset 11:c3768c16a27a
update paper
author | e165727 <e165727@ie.u-ryukyu.ac.jp> |
---|---|
date | Sat, 15 Feb 2020 06:36:16 +0900 |
parents | 242bf93dbbb5 |
children | 0320a82ac2e2 |
files | Paper/chapter1.tex Paper/chapter2.tex Paper/chapter3.tex Paper/chapter4.tex Paper/main.pdf |
diffstat | 5 files changed, 105 insertions(+), 39 deletions(-) [+] |
line wrap: on
line diff
--- a/Paper/chapter1.tex Fri Feb 14 23:29:37 2020 +0900 +++ b/Paper/chapter1.tex Sat Feb 15 06:36:16 2020 +0900 @@ -5,8 +5,8 @@ %英語発表者は,最終予稿の「はじめに」の英訳などを載せてもいいかも. \section{背景と目的} +%\section{ Perl6 の起動時間の改善} -%\section{ Perl6 の起動時間の改善} 現在開発の進んでいる言語に Perl6 がある. スクリプト言語 Perl6 は任意の VM が選択できるようになっており, 主に利用されている VM に C で書かれた MoarVM が存在する. MoarVM は JIT コンパイルなどをサポートしているが, 全体的な起動時間及び処理速度が Perl5 や Python , Ruby などの他のスクリプト言語と比較し非常に低速である. @@ -26,3 +26,6 @@ 研究をするにあたり得られた, サーバー上でscript言語を実行する場合の利点と欠点について述べ, 今後の展望について記載する. \section{論文の構成} +本論文は全 5 章で構成される。2 章では Raku の概要について紹介する。 3 章では 提案手法で述べた「Abyss Server」の具体的な実装について解説する。4 章では Abyss Server の性能評価について解説する。5 章はまとめとなっている。 +%また、本論文末尾には付録として BluePrints の簡易的な解説を掲載した。4 章に入る前 に読んでおくと実装の理解がしやすいだろう。 +
--- a/Paper/chapter2.tex Fri Feb 14 23:29:37 2020 +0900 +++ b/Paper/chapter2.tex Sat Feb 15 06:36:16 2020 +0900 @@ -23,13 +23,12 @@ \end{figure} \section{MoarVM} -MoarVM は Raku に特化した VM である. C 言語で実装されている. JIT コンパイルなどが現在導入されているが, 起動時間などが低速である問題がある. MoarVM 独自の ByteCode があり, NQP からこれを出力する機能などが存在している. +MoarVM は Rakudo, NQPのために構築された VM である. C 言語で実装されている. JIT コンパイルなどが現在導入されているが, 起動時間が低速であるなどの問題がある. MoarVM 独自の ByteCode があり, NQP からこれを出力する機能などが存在している. \section{NQP} +NQP とは Raku のサブセットである. +その為基本的な文法などは Raku に準拠しているが,変数を束縛で宣言するなどの違いが見られる. \begin{comment} -%NQP とは Raku のサブセットである. -%その為基本的な文法などは Raku に準拠しているが,変数を束縛で宣言するなどの違いが見られる. - %NQP は最終的には NQP 自身でブートストラップする言語であるが,ビルドの最初にはすでに書かれた MoarvM ByteCode を必要とする. %この MoarVMByteCode の状態を Stage0 と言う. %Raku の一部は NQP を拡張したもので書かれている為, Rakudo を動作させる為には MoarVM などの VM , VM に対応させる様にビルドした NQP がそれぞれ必要となる. @@ -39,8 +38,7 @@ Rakudo における NQP は現在 MoarVM, JVM 上で動作する. NQP は Perl6 のサブセットであるため, 主な文法などは Perl6 に準拠しているが幾つか異なる点が存在する. NQP は最終的には NQP 自身でブートストラップする言語であるが, ビルドの最初にはすでに書かれた MoarVM のバイトコードを必要とする. -この MoarVM のバイトコードの状態を Stage0 と言う. %い, バイトコードが付随するソースディレクトリ内のディレクトリ名として設定されている. -Perl6 の一部は NQP を拡張したもので書かれている為, Rakudo を動作させる為には MoarVM などの VM, VM に対応させる様にビルドした NQP がそれぞれ必要となる. +Raku の一部は NQP を拡張したもので書かれている為, Rakudo を動作させる為には MoarVM などの VM, VM に対応させる様にビルドした NQP がそれぞれ必要となる. 現在の NQP では MoarVM, JVM に対応する Stage0 はそれぞれ MoarVM のバイトコード, jarファイルが用意されている. MoarVM の ModuleLoader は Stage0 にある MoarVM のバイトコードで書かれた一連のファイルが該当する. \\ @@ -77,5 +75,43 @@ \section{なぜ Raku は遅いのか} 通常 Ruby のようなスクリプト言語ではまず YARVなどのプロセスVM が起動し,その後スクリプトを Byte code に変換して実行という手順を踏む. Rakudo はインタプリタの起動時間及び, 全体的な処理時間が他のスクリプト言語と比較して非常に低速である. -これは Rakudo 自体が Perl6 と NQP で書かれているため, MoarVMを起動し, Rakudo と NQP のByte codeを読み取り, Rakudoを起動し, その後スクリプトを読み取り, スクリプトの Byte code 変換というような手順で進むためである. +これは Rakudo 自体が Raku と NQP で書かれているため, MoarVMを起動し, Rakudo と NQP のByte codeを読み取り, Rakudoを起動し, その後スクリプトを読み取り, スクリプトの Byte code 変換というような手順で進むためである. また Perl6 は実行時の情報が必要であり, メソッドを実行する際に invoke が走ることも遅い原因である. +invoke はMoarVM の method 呼び出しの Byte code である. + +\section{Raku と他言語との起動時間の比較} +Raku と他言語の起動時間の比較行なった. +題材として perl5, ruby, raku, python で helloworld を出力するプログラムを用いて行なった実行結果である. + +実行環境 +\begin{itemize} +\item macOS Mojave version 10.14.5 +\item メモリ8GB +\item プロセッサ2.7GHz Intel Core i5 +\end{itemize} + +\begin{table}[H] + \begin{center} + \begin{tabular}{|l|l|} \hline + Language& version \\ \hline + Raku & 2019.03.1\\ + Perl5 & v5.18.4 \\ + Python & 2.7.10 \\ + Ruby & 2.3.7p456 \\ \hline + \end{tabular} + \end{center} + \caption{比較言語のバージョン} +\end{table} + +\begin{table}[H] + \begin{center} + \begin{tabular}{|l|l|} \hline + Language& Time \\ \hline + Raku & 0.249 sec \\ + Perl5 & 0.004 sec \\ + Python & 0.013 sec \\ + Ruby & 0.083 sec \\ \hline + \end{tabular} + \end{center} + \caption{起動時間の比較} +\end{table} \ No newline at end of file
--- a/Paper/chapter3.tex Fri Feb 14 23:29:37 2020 +0900 +++ b/Paper/chapter3.tex Sat Feb 15 06:36:16 2020 +0900 @@ -1,49 +1,41 @@ \chapter{Raku によるAbyss の実装} +提案手法に沿い『Abyss Server』を実装した. \section{サーバーの構成} -提案手法で実装したAbyss サーバーは Perl6 で書かれているクライアント側から投げられた Perl6 を実行するためのサーバーである. -図3は Abyss サーバーを用いたスクリプト言語実行手順である. -Abyss サーバーはユーザーが Perl6 を直接立ち上げるのではなく, まず図3右側の Abyss サーバーを起動し, ユーザーは Abyss サーバーにファイルパスをソケット通信で送り, Abyss サーバーがファイルを開き実行し, その実行結果をユーザーに返す. +Abyss サーバーは クライアント側から投げられた Rakuスクリプト を実行するためのサーバーである. +図\ref{fig:AbyssExecute}は, Abyss サーバーを用いたスクリプト言語実行手順である. +Abyss サーバーはユーザーが Raku を直接立ち上げるのではなく, まず 図\ref{fig:AbyssExecute} 右側の Abyss サーバーを起動し, ユーザーは Abyss サーバーにファイルパスをソケット通信で送り, Abyss サーバーがファイルを開き実行し, その実行結果をユーザーに返す. -この手法を用いることで, サーバー上で事前に起動した Rakudo を再利用し, 投げられた Perl6 スクリプトの実行を行うため, Rakudo の全体的な処理時間を短縮できると推測できる. +この手法を用いることで, サーバー上で事前に起動した Rakudo を再利用し, 投げられた Raku スクリプトの実行を行うため, Rakudo の起動時間を短縮できると推測できる. \begin{figure}[H] \begin{center} \includegraphics[width=80mm]{fig/abyss.pdf} \end{center} \caption{Abyssサーバーを用いたスクリプト言語実行手順} - \label{fig:perl6cbcinter} + \label{fig:AbyssExecute} \end{figure} -Code1はAbyss サーバーのソースコードである. -Abyssサーバーは起動すると, まず自身にファイルパスを転送するためのソケットを生成し, その後ファイルを受け取るための待機ループに入る. +\section{Abyss Server側の実装} +\ref{Server}はAbyss サーバーのソースコードである. +Abyssサーバーは起動すると, まず自身にファイルパスを転送するためのソケットを生成し, その後ファイルを受け取り実行して . 出力結果をソケットに書き込む + +\lstinputlisting[label=Server, caption= Abyss Server側の source code ]{code/abyss.p6} -Perl6 ではEVAL関数[\ref{code3}]があり文字列を Perl6 のソースコード自身として評価できる +\section{Abyss Client側の実装} +ユーザーは Abyss Server を起動後, Client側からファイルパスをサーバーに送信し, \ref{Client}のようにSocketに書き込まれた実行結果を読み取る. + +\lstinputlisting[label=Cient, caption=Abyss Client側の source code ]{code/client.p6} -Perl6 では, EVALは通常は使用できないようになっており, MONKEY-SEE-NO-EVAL という pragma を実行することで使うことができるようになる. + +\section{Raku の EVAL} +Raku ではEVAL関数[\ref{code3}]があり文字列を Raku のソースコード自身として評価できる + +Raku では, EVALは通常は使用できないようになっており, MONKEY-SEE-NO-EVAL という pragma を実行することで使うことができるようになる. EVALFILE はファイルパスを受け取るとファイル開き, バイト文字列に変換し読み込む, その後読み込んだバイト文字列にデコードし, ファイルパスの文字列を読み込み, ファイルの中身を EVAL と同様に解釈する. -Code1 の2行目にある MONKEY−SEE−NO−EVAL は Perl6 上で EVALFILE を使用可能にする pragma である. +\ref{code1} の2行目にある MONKEY−SEE−NO−EVAL は Perl6 上で EVALFILE を使用可能にする pragma である. -\lstinputlisting[label=code1, caption= Abyss サーバーの実装の source code ]{code/abyss.p6} -\lstinputlisting[label=code2, caption=クライアント側の source code ]{code/client.p6} \lstinputlisting[label=code3, caption=evalのサンプルコード]{code/eval.p6} %通常、自分でプロセス立ち上げてPerl6を実行する際は, -%\section{問題点} -\section{比較} -\begin{itemize} -\item{Microsoft CLR} -\\ -.NET Framework には, 共通言語ランタイム(Common Language Runtime)と呼ばれるランタイム環境がある. -.NET対応のソフトウェアは, 様々なプログラミング言語で書かれたソースコードから, いったん共通中間言語 (Common Intermediate Language)による形式に変換されて利用者のもとに配布される. -CIL 形式のプログラムを解釈し, コンピュータが直に実行可能な機械語によるプログラムに変換して実行するソフトウェアが CLR である. -現状の Abyss サーバーはプロセスとして立ち上げているが, CLR は OS に直接組み込む必要があるが, Abyss サーバーはプロセス上で実行しているため OS に手を加えず実装が容易である. -\\ -\item{PyPy} -\\ -PyPy は Python の 実装の一つであり, Cpython のサブセットである RPython で記述された 処理系である. -\\ -PyPy は JIT コンパイル を採用しており, 実行時にコードを機械語にコンパイルして効率的に実行させることができる. -PyPy は Cpython より実行速度が速いが起動速度は Cpython と比較して約3倍遅い. -Perl6 と同様, PyPyは Cpython と比較して起動時間が遅いため今回提案した手法を応用できると予測できる. -\end{itemize} \ No newline at end of file +\section{NativeCall}
--- a/Paper/chapter4.tex Fri Feb 14 23:29:37 2020 +0900 +++ b/Paper/chapter4.tex Sat Feb 15 06:36:16 2020 +0900 @@ -1,2 +1,37 @@ \chapter{Abyss Server の性能評価} -\section{利点と欠点} + +\section{比較} +\begin{itemize} +\item{Microsoft CLR} +\\ +.NET Framework には, 共通言語ランタイム(Common Language Runtime)と呼ばれるランタイム環境がある. +.NET対応のソフトウェアは, 様々なプログラミング言語で書かれたソースコードから, いったん共通中間言語 (Common Intermediate Language)による形式に変換されて利用者のもとに配布される. +CIL 形式のプログラムを解釈し, コンピュータが直に実行可能な機械語によるプログラムに変換して実行するソフトウェアが CLR である. +現状の Abyss サーバーはプロセスとして立ち上げているが, CLR は OS に直接組み込む必要があるが, Abyss サーバーはプロセス上で実行しているため OS に手を加えず実装が容易である. +\\ +\item{PyPy} +\\ +PyPy は Python の 実装の一つであり, Cpython のサブセットである RPython で記述された 処理系である. +\\ +PyPy は JIT コンパイル を採用しており, 実行時にコードを機械語にコンパイルして効率的に実行させることができる. +PyPy は Cpython より実行速度が速いが起動速度は Cpython と比較して約3倍遅い. +Perl6 と同様, PyPyは Cpython と比較して起動時間が遅いため今回提案した手法を応用できると予測できる. +\end{itemize} + +\section{Abyss Server の利点} + +\begin{itemize} +\item Abyss Serverを用いて実行することで, サーバー上で事前に起動した Rakudo を再利用し, 投げられた Raku スクリプトの実行を行うため, Rakudo の起動時間を短縮できる. +\item 一度投げられたスクリプトのバイトコード, もしくは計算結果をキャッシュで保存しておき, 再度実行する際に, そのキャッシュを用いてコンパイル時間を省くような仕組みを入れやすいと考えられる. +\item 他の起動時間遅いスクリプト言語や, モジュールの読み込みが遅い言語などにも, 応用しやすいと考えられる. +\item 普通のスクリプト言語だと実行するたびにforkして実行しインタプリタの立ち上げという処理になるが, プロセス毎回起動しなくて済む +\end{itemize} + +\section{Abyss Server の欠点} + +\begin{itemize} +\item 現在 Abyss Server には 一度スクリプトを実行した後にサーバー内の環境をリセットする機能が存在しないため,スクリプトがサーバー内の環境に影響を及ぼした場合,通常実行と違う挙動をする危険性がある +\item 同時に二つ以上のタスクを与えられると実行順のスケジューリングができない +\item 異常に長いタスクが投げられた場合, 次のタスクが前のタスクが終わるまで実行ができない +\item 起動時のオプションが選択出来ない +\end{itemize}