続・Perl6は何処にいった その２

３月中旬にParrot1.0がリリースされた。

但し、1.0は中間コードコンパイラ作成者に

向けたベータ版的なリリースで安定板は

2010年７月リリース予定の2.0までお預け。

LLVMとParrotは似て非なるもの、Parrotが

動的言語をターゲットにバイトコードを設計

しているのに対し、LLVMはC・C++等の

静的言語を主なターゲットにしておりLLVM

用の中間コードはParrotのものよりもずっと

機械語(アセンブリ)に近く、静的言語を様々な

タイミングにて最適化できるように作られている。

Parrotをバイトコードインタープリタとして捉えた

場合、最適化の方向性に疑問が残る。

OO言語と手続き型言語を同じバイトコード

インタープリタで扱うのは効率が良いとは

思えない。

CLR、RubyVM、Java、JavaScript用VMの何れに

ついてもOO言語に最適化する方向でバイトコードを

設計している。

OO言語と手続き型言語を同じバイトコードで

扱おうとした場合、手続き型言語かOO言語の

どちらかにあわせてバイトコードを設計する

ことになる。

手続き型言語に合わせた場合、OO言語を内部的

に手続き型言語に変換してからバイトコードに

落とし込む事になる、一旦バイトコードに変換

してからは高速に動作するもののバイト

コードに落とし込む際のオーバーヘッドが

馬鹿にならない。

OO言語に合わせた場合は手続き型言語を内部的に

OO言語のように扱いバイトコードに落とし込む

ことになる、OO言語は手続き型言語の特徴を内包

するのでバイトコードへの変換時のオーバーヘッド

はそれほどないものの、手続き型言語に合わせて

バイトコードを設計した場合に比べると実行時の

オーバーヘッドがそれなりにある。

OO言語と手続き型言語を両方とも上手く

扱うためにはバイトコードの設計が重要であり、

どちらかに特化した場合よりも複雑になると

思われる。

OO言語と手続き型言語の両方に上手く最適化された

動的言語用VMは今のところ、存在しない。Parrotが

初のそんなVMになるとは考えにくい。

RubyVM、Java、JavaScript用VMの何れにしても

特定の言語に特化させる形でバイトコードを設計

し、処理速度面で成果を上げている。

CLRは汎用性を追求する形でバイトコードを設計

しているため、それぞれの言語についてはその

言語へ特化した場合よりも処理速度面で劣ると

思われる。

汎用性を持たせてバイトコードを設計するよりも

個々の言語に合わせてバイトコードを設計する方

が動的言語では性能的に有利ではないかと思う。

現にParrot上に実装されたメジャーな言語の実行

環境はどれも現状では各々の言語に特化して実装

された実行環境と同等の性能を達成していない。

PythonのParrot正式採用の可能性が報じられていた

時期もあったが、今やその可能性は著しく低いという

か、ないに等しい。 unladen-swallow というPython

実装の高速化プロジェクトでは既にCPythonをベース

にLLVM利用型VMの開発を開始している。

Ruby界隈ではAppleによるRuby1.9互換(?)実装MacRuby

の開発チームが次期リリース(0.5)に向けてCRubyを

ベースにLLVM利用型VMの開発を開始している。

日本国内では有志によりYARV中間コードをLLVM中間コード

に変換するJIT(?)コンパイラyarv2llvmの開発も行われている。

LLVMは静的言語をターゲットにしてきているが、

動的言語をどのようにサポートするかもプロジェクト内で

議論されている模様。

Parrotは開発に時間が掛かりすぎている感がある。

Parrot開発開始当初には影も形もないに等しかった

LLVMに先を越された感がいなめない。

Parrotがその安定版の開発に1年以上の時間を掛ける間に

LLVM利用型の動的言語実行環境の実現に道筋が出来上がる

だろう。

つづく...推敲中