Mercurial > hg > Papers > 2020 > koo-thesis
changeset 4:d117c68a5b33
modify thesis
| author | e165727 <e165727@ie.u-ryukyu.ac.jp> |
|---|---|
| date | Wed, 12 Feb 2020 19:19:55 +0900 |
| parents | 32bba57ef41c |
| children | d160d6c7562f |
| files | Paper/chapter2.tex Paper/chapter3.tex Paper/chapter4.tex Paper/fig/Raku.pdf Paper/fig/Rakudo.pdf Paper/fig/abyss.pdf Paper/fig/emblem-bitmap.pdf Paper/fig/tgraph.pdf |
| diffstat | 8 files changed, 148 insertions(+), 0 deletions(-) [+] |
line wrap: on
line diff
--- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/Paper/chapter2.tex Wed Feb 12 19:19:55 2020 +0900 @@ -0,0 +1,75 @@ +\chapter{Perl6} + +\section{Perl6 の概要} +Perl6 は 2002 年に LarryWall が Perl を置き換える言語として設計を開始した. Perl5 の言語的な問題点であるオブジェクト指向機能の強力なサポートなどを取り入れた言語として設計された. Perl5 は設計と実装が同一であり, Larry らによって書かれた C 実装のみだった. Perl6 は設計と実装が分離している. 言語的な特徴としては, 独自に Perl6 の文法の拡張が可能な Grammar, Perl5 と比較した場合のオブジェクト指向言語としての進化も見られる. また Perl6 は漸進的型付け言語である. 従来の Perl の様に変数に代入する対象の型や, 文脈に応じて型を変更する動的型言語としての側面を持ちつつ, 独自に定義した型を始めとする様々な型に, 静的に変数の型を設定する事が可能である. +Perl6 は言語仕様及び処理実装が Perl5 と大幅に異なっており, 言語的な互換性が存在しない. 従って現在では Perl6 と Perl5 は別言語としての開発方針になっている. Perl6 は現在有力な処理系である Rakudo から名前を取り Raku という別名がつけられている. + +Perl6 の現在の主流な実装は Rakudo である. Rakudo は MoarVM, と NQP と呼ばれる Perl6 のサブセット, NQPと Perl6 自身で記述された Perl6 という構成である. +MoarVM は NQP と Byte Code を解釈する. + +NQP とは Not Quite Perl の略で Perl6 のサブセットである. その為基本的な文法などは Perl6 に準拠しているが, 変数を束縛で宣言するなどの違いが見られる. + +この NQP で記述された Perl6 の事を Rakudo と呼ぶ. +Rakudo は MoarVM の他に JVM , Javascript を動作環境として選択可能である. + +Perl6 の起動は, MoarVM を起動, NQP をロード, Rakudo をロードもしくはコンパイルし, その後 JIT しながら実行する. + +\begin{figure}[H] + \begin{center} + \includegraphics[width=70mm]{fig/Rakudo.pdf} + \end{center} + \caption{Rakudoの構成} + \label{fig:perl6cbcinter} +\end{figure} + +\section{MoarVM} +MoarVM は Perl6 に特化した VM である. C 言語で実装されている. JIT コンパイルなどが現在導入されているが, 起動時間などが低速である問題がある. MoarVM 独自の ByteCode があり, NQP からこれを出力する機能などが存在している. + +\section{NQP} +\begin{comment} +%NQP とは Raku のサブセットである． +%その為基本的な文法などは Raku に準拠しているが，変数を束縛で宣言するなどの違いが見られる． + +%NQP は最終的には NQP 自身でブートストラップする言語であるが,ビルドの最初にはすでに書かれた MoarvM ByteCode を必要とする． +%この MoarVMByteCode の状態を Stage0 と言う． +%Raku の一部は NQP を拡張したもので書かれている為, Rakudo を動作させる為には MoarVM などの VM , VM に対応させる様にビルドした NQP がそれぞれ必要となる． +%NQP は与えられた Stage0 を使い Stage1 をビルドし, そのStage1 を利用し Stage2 をビルドする事で生成できる. +\end{comment} + +Rakudo における NQP は現在 MoarVM, JVM 上で動作する． +NQP は Perl6 のサブセットであるため, 主な文法などは Perl6 に準拠しているが幾つか異なる点が存在する． +NQP は最終的には NQP 自身でブートストラップする言語であるが, ビルドの最初にはすでに書かれた MoarVM のバイトコードを必要とする． +この MoarVM のバイトコードの状態を Stage0 と言う. %い, バイトコードが付随するソースディレクトリ内のディレクトリ名として設定されている． +Perl6 の一部は NQP を拡張したもので書かれている為, Rakudo を動作させる為には MoarVM などの VM, VM に対応させる様にビルドした NQP がそれぞれ必要となる． +現在の NQP では MoarVM, JVM に対応する Stage0 はそれぞれ MoarVM のバイトコード, jarファイルが用意されている． +MoarVM の ModuleLoader は Stage0 にある MoarVM のバイトコードで書かれた一連のファイルが該当する． +\\ +Stage0 にあるファイルを MoarVM に与えることで, NQP のインタプリタが実行される様になっている． +これは Stage0 の一連のファイルは, MoarVM のバイトコードなどで記述された NQP コンパイラのモジュールである為である． +NQP のインタプリタはセルフビルドが完了すると, nqp というシェルスクリプトとして提供される． +このシェルスクリプトは, ライブラリパスなどを設定して MoarVM の実行バイナリである moar を起動するものである． +%NQPは6modelと呼ばれるオブジェクトモデルを採用としている．%が, これを構築する為に必要なNQPCORE,正規表現系のQRegex,MoarVMのModuleLoaderなどがMoarVMBytecodeで記述されている．これらMoarVMBytecodeの拡張子は.MoarVMである． +%MoarVMに対してStage0のディレクトリにライブラリパスを設定し, nqp.MoarVMを実行させることでnqpの対話型環境が起動する． + +\begin{figure*}[ht] + \begin{center} + \includegraphics[width=140mm]{fig/tgraph.pdf} + \end{center} + \caption{NQPのビルドフロー} + \label{fig:nqpbuild} +\end{figure*} + +NQP のビルドフローを図\ref{fig:nqpbuild}に示す． +Rakudo による Perl6 処理系は NQP における nqp と同様に, moar にライブラリパスなどを設定した perl6 というシェルスクリプトである． +この perl6 を動かすためには self build した NQP コンパイラが必要となる． +その為に Stage0 を利用して Stage1 をビルドし NQP コンパイラを作成する． +Stage1 は中間的な出力であり, 生成された NQP ファイルは Stage2 と同一であるが, MoarVM のバイトコードが異なる． +Perl6 では完全なセルフコンパイルを実行した NQP が要求される為, Stage1 を利用してもう一度ビルドを行い Stage2 を作成する． +\\ +Perl6 のテストスイートであるRoastやドキュメントなどによって設計が定まっている Perl6 とは異なり NQP 自身の設計は今後も変更になる可能性が開発者から公表されている． +現在の公表されている NQP のオペコードは NQP のリポジトリに記述されているものである． +%\subsection{Rakudo Perl6} +%Rakudo実装上におけるPerl6はRakudo Perl6と呼ばれているGitリポジトリで管理されているプログラムのことである． +%前述した通りRakudo Perl6はPerl6のサブセットであるNQPを用いて記述されている． +%従ってyaccやlexと言ったPerl5の文字解析, 構文解析に利用していたプログラムは利用せず, NQP側で構文定義などを行っている． +%NQPはNQP自身でBootstrappingされている為, Rakudo Perl6のbuild時にはNQPの実行環境として要したVM, それに基づいてbuildしたNQPがそれぞれ必要となる．
--- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/Paper/chapter3.tex Wed Feb 12 19:19:55 2020 +0900 @@ -0,0 +1,72 @@ +\chapter{Abyss Server} +\section{なぜ Perl6 は遅いのか} +通常 Ruby のようなスクリプト言語ではまず YARVなどのプロセスVM が起動し,その後スクリプトを Byte code に変換して実行という手順を踏む. +Rakudo はインタプリタの起動時間及び, 全体的な処理時間が他のスクリプト言語と比較して非常に低速である. +これは Rakudo 自体が Perl6 と NQP で書かれているため, MoarVMを起動し, Rakudo と NQP のByte codeを読み取り, Rakudoを起動し, その後スクリプトを読み取り, スクリプトの Byte code 変換というような手順で進むためである. +また Perl6 は実行時の情報が必要であり, メソッドを実行する際に invoke が走ることも遅い原因である. + +\section{Perl6によるAbyssの実装} +提案手法で実装したAbyss サーバーは Perl6 で書かれているクライアント側から投げられた Perl6 を実行するためのサーバーである. +図3は Abyss サーバーを用いたスクリプト言語実行手順である. +Abyss サーバーはユーザーが Perl6 を直接立ち上げるのではなく, まず図３右側の Abyss サーバーを起動し, ユーザーは Abyss サーバーにファイルパスをソケット通信で送り, Abyss サーバーがファイルを開き実行し, その実行結果をユーザーに返す. + +この手法を用いることで, サーバー上で事前に起動した Rakudo を再利用し, 投げられた Perl6 スクリプトの実行を行うため, Rakudo の全体的な処理時間を短縮できると推測できる. + +\begin{figure}[H] + \begin{center} + \includegraphics[width=80mm]{fig/abyss.pdf} + \end{center} + \caption{Abyssサーバーを用いたスクリプト言語実行手順} + \label{fig:perl6cbcinter} +\end{figure} + +Code1はAbyss サーバーのソースコードである. +Abyssサーバーは起動すると, まず自身にファイルパスを転送するためのソケットを生成し, その後ファイルを受け取るための待機ループに入る. + +Perl6 ではEVAL関数[\ref{code3}]があり文字列を Perl6 のソースコード自身として評価できる + +Perl6 では, EVALは通常は使用できないようになっており, MONKEY-SEE-NO-EVAL という pragma を実行することで使うことができるようになる. +EVALFILE はファイルパスを受け取るとファイル開き, バイト文字列に変換し読み込む, その後読み込んだバイト文字列にデコードし, ファイルパスの文字列を読み込み, ファイルの中身を EVAL と同様に解釈する. + +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} +\section{まとめ} +本稿では実行する Perl6 ファイル名をサーバーに転送し,コンパイラサーバーでコンパイルを行い実行することで全体的に処理時間が早くなることを示した. +\\ +今後Abyssサーバーでの開発をより深く行っていくにあたって以下のような改善点が見られた \\ +\begin{itemize} +\item コンパイラの起動が遅い言語だけでなく, モジュールの読み込みが遅い言語などを, あらかじめサーバーを側でモジュールを読み込んでおき, それを利用してプログラムを実行する手法も応用できるように改良を行う. +\item 今回の実装では TCP ソケットを用いたが TCP ソケットを用いるとサーバーを立ち上げた際に外部からファイルを転送される可能性があるので, Unix domain socket の実装を行い, それを用いたクライアント・サーバーを作成することで安全性が高まると考えた. +Perl6 には現状 Unix domain socket の実装がないので, Unix domain socket を実装し, 自分以外が実行できないようにすることが今後の課題に挙げられる. +\item 今回用いた Perl6 の EVALFILE 自体にクライアント側に出力を返す実装追加することも今後の課題に挙げられる. +\item 現状の Raku の EVALFILE では, 出力がサーバー側に返っているので, クライアント側から出力を見るためにクライアント側に返す必要がある. +\item モジュールを送信する機能の追加 +\item プログラムの実行終了したらモジュールを削除する機能の追加\\ +\end{itemize} +%またscript言語をサーバー上で実行する場合の欠点については以下のようなものが見られる +%\begin{itemize} +%\item +%\end{itemize} +今後の開発を行っていくにあたって, 他の Python のような script 言語にも応用できるように開発を行っていく.