JRubyプロジェクトは、Rubyの多くにおいて、サポートや互換性が大変良くなった。加えて、パフォーマンスの点において多くの改良がなされ、JRubyの処理速度改善をもたらしている。
しかし、XRubyに関する最近の情報によれば、ベンチマークプログラムの多くにおいて、XRuby0.1.3がRuby 1.8.5よりも高速であるという結果が出ている。その結果は、JRubyと比べて多少速度が速いものもあるが、メソッドの呼び出しやArrayの生成においては大きな差が出る結果となった。XRubyのブログによれば、次のように書かれている。
実際、以前までは、XRubyの開発者が、パフォーマンスに関して何もしてこなかったということにふれるべきなのかもしれません。そして、我々は、コードを複雑なものにするかもしれないので、可能な限り最適化を避けてきたように思います。
XRubyは、RubyのソースファイルをJavaのバイトコード(.jarファイルを含む、.classファイル)に変換するコンパイラである。これは、Rubyインタープリタとして動作する(即ち、jruby foo.rbというふうに、ソースコードを実行できるということ)JRubyとは違ったアプローチである。
XRubyプロジェクトのXue Yong Zhi氏は、全てのRuby実装が避けて通れない、重要で急を要する問題に対する回答を始めた。それは、いつRailsに対応するか？という問題に対する答えである。
Railsに関して言えば、私たちは、年末までにはXRuby上で動作するようにしたいと思っています。しかし、メンバー全てがパートタイマーなので予測は困難です。ただ、Ruby実装の代替となるもの全ての中では、私たちは、最も少ないリソースとおそらく最も野心のない集団です。そのプロジェクトは、まさに私たちにとって調査と研究のツールとも言えるものであり、私たちは、rubyからjavaのバイトコードにコンパイルするという草分け的な作業を楽しんでいます。
RubyのVM実装の代わりとなるもの全てに言える大きな問題として、標準ライブラリへのアクセスという問題がある。JRubyチームでは、SSLサポートといったライブラリ作成までに多くの時間を費やした(JRubyのチームメンバーであるOla Bini氏による多大な努力によって取り込まれた)。問題は、これらのライブラリの多くが、Cで実装されているということである。故に、他のRuby実装の中でも、使い勝手は良くないのだ。
ビルトインライブラリは、私たちにとって大きな問題となっています。パーサ、コンパイラ、ランタイム、・・・といった部分に関しては、とても良いものとなっています。しかし、ビルトインの実装は遅れています。私たちは、それがどれだけ重要であるかを理解しているものの、コンパイラの作成に比べると、チャレンジ精神旺盛かつクールになれないというのが理由の一つにあるのかもしれません。
もし、私たちにとって、他のプロジェクトからのコードの再利用が簡単にできるのであれば、それは、とてもすばらしいことです。そして、個人的には、ビルトインライブラリのほとんどをピュアRubyで実装しているrubiniusのアプローチの方が好きです。今年の夏に、Googleは、RSpecセットの実装作業のために2人の研究者を派遣する予定であり、rubiniusや他のプロジェクトを支援できることを期待しています。
Rubiniusは、Evan Phoenix氏をトップとするプロジェクトで、Rubyで完全なRuby実装を書くことを目的としている。詳細な考え方は、Squeak(Squeakで実装されたSmalltalk)をもとにしている。このアプローチの優位性は、明確である。それは、もし、標準ライブラリの各々がRubyで書かれていたならば、同じコードを、Rubyの実装で利用することができるからである。現在、JRubyやXRuby、若しくはRuby.NETといったその他のRuby実装は、Rubyの振る舞いや実装言語における実装をじっくりと理解してゆく必要がある。
例を挙げると、Rubyは、PCREと呼ばれる正規表現のライブラリを利用している。最近になって、JRubyは、java.util.regexが利用され、Rubyの正規表現としてJavaを標準装備している。しかしながら、Java java.util.regexとPCREの間には、大きな違いがあることは明らかである。なぜならば、Rubyの正規表現として使われている新しいJavaライブラリは、Ola Biniがもとになっているからである。これは、不幸なことだ。つまり、Rubyで正規表現の実装をするには、より良いソリューションだと思うからである。以上により、Rubyのランタイム実装部分は全て、同じコードを利用することができ、その処理を注意深く、繰り返しリバースエンジニアリングする必要がなくなるだろう。
もちろん、次のような問題もある。現在のRubyランタイムがかなり遅いように、Rubyでライブラリを実装することは、パフォーマンスの低下につながる。しかし、JRubyとXRubyの両方を使うというアイデアがある。もし、XRubyで、Rubyのコードを高速なJavaのバイトコードに変換することが継続的に可能であるならば、クリティカルなコードのパフォーマンスに対する加速剤として利用することができる。
少なくとも、JRubyがランタイムとして使用されるときには、XRubyは、このようなケースを解決する可能性を秘めている。クリティカルなコードのパフォーマンスは、XRubyでJavaのバイトコードにコンパイルし、非常に高速なコードになるという結果が期待できる。Javaのバイトコードに変換したものは、JRubyとして使用することができ、JRubyから、既存のJavaコードにアクセスすることがとても簡単になる(結局、Javaの標準ライブラリ全ては、JRubyから使用可能ということである)。これは、次のような大きなメリットがある。
- Rubyのコードを再実装する必要性が無くなり、ロジックに対して唯一のコードとなります
- デプロイの際には、より高速なパフォーマンスを持つXRubyでコンパイルしたコードを利用することができます
- 開発の際には、Rubyの優位性が残ります(コードを実行時に変更することで、Rubyでより高水準なコーディングができる、など)
これは、単に、システムライブラリに対する問題ではない。かつて、David Heinemeier Hansson氏は、実行速度の悪い箇所をいくつか書き直し、クリティカルな部分に関してはCで書いたという記事を投稿している。結局、いくつかのRubyのコードがアプリケーションのボトルネックとなっていることが分かった。その解決策として、Cでアルゴリズムを再構築し、結果として得られるライブラリを使用するためにRubyの独自拡張システムを使用した。これは、Cで書かれた正規表現ライブラリが持っている問題に似ている。
Rubyの正規表現ライブラリと同時に、これは、厄介な問題である。つまり、Rubyのコードをやめると、その後はCベースで再実装しなければならないということである。もちろんのこと、Rubyのバージョンは今なお更新され、Cのコードも同期をとり続けている(逆もまたしかり)。しかし、これは無駄な努力であり、実装の中に難解なバグを埋め込む可能性があることを意味している。当然、Cのコードにより移植性が制限されるという大きな問題もある。急に、コードの一部をJRubyや他のシステムに利用できないのだ。しかし、前記のソリューションがここでも役に立つ。
実際、その問題を解決するには、XRubyチームの開発状況次第なのだが、どちらにしろ、JRubyの作業は続けることができる。しかし、良い機会が与えられたとも言える。JRubyのCharles O. Nutter氏は次のように言っている。
(中略) 2つのランタイムは、全く違います。JRubyは、常にインタープリターモードのようなものなので、コンパイルとは違ったアプローチをとることができると思っています。コンパイルの計画を立てている時に、別の作業をすることもできるのです。
残された問題として、2つのRubyシステムベースのJVMによってもたらされる問題があるす。両方が、それぞれのランタイム実装で処理されるが、その中身は全く異なっている。問題は、根底にある。つまり、XRubyでは、Rubyオブジェクトはcom.xruby.runtime.lang.RubyObjectのJavaクラスとなるが、JRubyでは、org.jruby.RubyObjectとなる。これは、JRubyのコードで、XRubyでコンパイルされたメソッドを参照したいときに、問題が発生するだろう。そして、これは、ほんの一例に過ぎないのである。少なくとも現時点で、多くの問題により、JRubyとXRubyの間のシームレスなインタラクションが阻害されていると言える。
しかしながら、XRubyは、他の部分でJRubyをサポートする可能性を秘めている。XRubyの何よりすばらしい特徴として、Rubyパーサ(構文解析器)の実装に、ANTLRパーサジェネレータを使用していることがあげられる。もちろん、JRubyにもパーサがあるが、いくつか問題がある。Ola Bini氏は、次のように言っている。
大きな問題として、メンテナンスの点があげられます。コードが複雑で、特に、レクサ(字句解析器)においては、理解することが容易ではありません。さらに、ソースの正しい位置を把握するための処理が十分でない部分がいくつかあります。そのような観点からすると、十分な機能を持ったANTLRパーサの方が、若干パフォーマンスが悪いとは言え、多分望ましいと思われます。私たちは、これらの顛末を詳しく調べてゆく予定ですが、それは、バージョン1.0がリリースされた後になるでしょう。同じく、Charles O. Nutter氏も、次のように考えている。
Ola氏は、実際はパフォーマンスについて考慮していないと言っていますが、将来的には、ANTLRが同等レベルになる可能性があります。Ruby 2.0に対応し、外部ツール(パーサジェネレータのJay)の依存をなくすことが、より簡単にできるのであれば、それは価値のあることです。さらに私たちは、さほど労せずに、全く異なったパースの結果を入れ替えることができるコンパイラを設計しました。おそらく、バージョン1.0の後で、それらをお見せできるでしょう。XRubyプロジェクトのXue Yong Zhi氏は、さらに面白いニュースを提供している。
現在のXRubyは、ANTLR 2.7.xベースで十分高速です。ANTLR 3.0に移行することで、処理速度はさらに高速になります。Googleは、この作業のために、SOCアプリケーションの研究者としてHaofei氏を採用しました。さらに、Femtowin氏もメンバーとして参加する予定です。全てが順調に行けば、RubyでANTLR 3.0をバックエンドとしたRubyパーサを作れるかもしれません。ANTLRベースのパーサという大きなアドバンテージで、メンテナンスコストを削減できます。
RubyでのRubyパーサをRubyのツールセットに追加することは、非常に歓迎すべきことだと思う。何故なら、今までは、Rubyで書かれたRubyパーサが無かったからである。このことは、Rubyのツールにとって大きな障壁となっている。何故なら、現在、抽象的なシンタックスツリー(ソースコードを構文解析するAST)を取得するためのRubyランタイム独自の方法が無いからである。Ruby 1.8.5では、独自の拡張が必要である。JRubyの仕様では、ASTが採用されるが、JRuby仕様のコードが必要になることは明らかである。(詳細は、Google Summer of Code (SoC)プロジェクトに書かれている)
最後に、2つのプロジェクトは、ものすごいスピードで進歩している。XRubyは、今なお多くの点をキャッチアップする必要があるが、それは、将来、大きな影響を与えると思われる。これらは、間違いなく注目のプロジェクトである。
（原文は2007年4月16日にリリースされた記事です）