Rubiniusプロジェクト(リンク)で現在何がおこなわれているのか、Brian Ford氏にインタビューをした。Brian氏は、過去数カ月Rubiniusであった変更のいくつかをリストしている。
[..] 過去2カ月に何百ものコミットや何千ものラインの変更がありました。主要なものは、以下のとおりです。
* 動的に生成されるバイトコードインタープリターの他に、Evan氏は使用可能なJITフレームワークを追加しました。
* 多数のRubyコアライブラリクラスのパフォーマンスを修正し、改善しました。
* ブートストラッププロセスを改訂して、コアライブラリのコードの質を改善しました。
* MRIと同じだが、10倍高速な出力をする作業インスツルメントプロファイラを作成しました。
* Adam Gardiner氏は、Rubyデバッガが新たなVMで再び動作するように取り組んでいます。
*FFI実装をアップデートし、JRubyやMRI FFI gemのリリースにさらに近いものにします。
*さらに良いフォーマットで、コンパイラスペックを完全に作り替えました。
* 1.8および1.9のRubyspecsが合併し、重要機能を MSpecに追加し、1.8や1.9のスペックの実行を促進しました。 わたしの作業において、Engine Yardは引き続きRubySpecsに対する資金面での主なサポート役で、MRIが組み込まれているあらゆるRuby実装で利益を得るということを忘れてはいけません。
RubyConf'08において、Brian氏はRubySpecsについて話した(リンク)。詳しくは、http://rubyspec.org/ を参照のこと。
しばらくの期間、コンパイラバックエンドを構築するためのフレームワークであるLLVM(リンク)は、利益をもたらしている。そこでは、LLVM向けのRubyバインディングは、すでにいくつか興味深いプロジェクトを生み出している(参考記事)。Brian氏は、RubiniusおよびLLVMで何が起こっているのかを以下のように説明している。
現在LLVMは、デフォルトでは作動されません。ネイティブコード生成のあらゆるオプションを調査しているところです。Evan氏は、 C++でJITアセンブラに取り組んでいます。明らかにこれはタイムクリティカルなコンポーネントです。ネイティブコードの生成によって得られる収穫は、 実行時にコードの生成でかかる時間による相殺です。 LLVMは巨大で強い印象を与えるライブラリです。
最先端(伝統的スタイル)の最適化の方法を通じてC/C++ソースコードを取り込み、数多くのプロセッサのアーチ固有マシンコードにします。その素晴らしい能力を最も良く利用する方法を、依然として研究中です。可能性の1つとしては、コンパイル時にLLVM IRを生成して、実行時までマシンコードの生成を保留にすることです。
悟るべきもう1つのことは、最適化が最適化されるコードの量と相互に関連がある速度の利点を提供するということです。Rubyは、メソッド呼び出しが非常 に大きな役割を果たす言語です。積極的にコードをインライン化できなれけば、最適化の作業はほとんどありません。効果的なインライン化を可能にする、さら に高機能なランタイムタイプシステムを検討しているところです。
昨年は、大部分を古いVM(Cで記述された「shotgun」)を新しいC++ベースのVMに書き換えることに費やした。Brian氏は、まもなく(再び)Railsがサポートされることを説明している。
shotgunで動作したレベルではありません。新たなVMでは、コアライブラリの基礎をなしている基本が書き直されました。特に、さしあたり Rails/Merb実行の妨害であるAutoload実装で問題を抱え込んでいます。全てのこれらの問題にQ1で集中して取り組んでいます。Rails/Merbおよびramaze、camping、Sinatra、wavesなどを含むマクロおよびマイクロ Webフレームワークを実行させる予定です。
Ryan Davis氏によって記述されたRuby_parser(リンク)(InfoQがruby_parserを取り上げた)(参考記事・英語)は、Rubyで記述されたRuby解釈プログ ラムです。Brian氏は、RubiniusでRubyコードを解析する現在の計画について以下のように説明している。
ここでの私の反応は、多少物議を醸すものですが、適切に証拠を示すことでそれも収まると考えています。RubyParserを使う利点はありません。それはMRI固有の解釈プログラムとまったく同じテクノロジー(LALR(1)、大多数のプログラマには利用不可能)であり、プロジェクト開始以来、われわれはRubiniusで使用してきました。MRIと比較すると、RubyParserは著しく遅く、不要な非互換性ポイントを導入しています。
最終的に、実行やRubyコードを十分高速にして、RubyParserのようなものを使うことが想像できるようにします。しかしその時までは何のメリットもありません。構文解析はRuby実装の弱点であって、われわれにとってそれは問題ではないのです。ほとんど直接的にMRIソースを使用することができます。
Rubyの構文解析に本当に興味があれば、分解可能な文法を提供し、本当に文法を開放し、レイプログラマに構文解析するPEG(Treetopにより実装)のような便利なテクノロジーについて検討するべきでしょう。
注：Treetop(リンク)は、RubyでのPEG構文解析プログラム(リンク)の記述を可能にする。
Evan Phoenix氏は、Rubiniusの設計上の改善についてRubyConf '08で話した(参考記事)。Brian氏もまた同様に、変更について以下のようにまとめている。
今研究している大きな分野がいくつかあります。しかし、それらは基本的にコンパイラテクノロジー、GC、データ構造およびタイプシステムの向上に帰着しま す。当然、これは反復です。しかし、Rubiniusは辛うじて2年目のプロジェクトであるということを心に留めておくのがよいでしょう。Evan氏はプ ロジェクトの期間中、設計上見事な決定をし、新たなC++ VM、RubyコンパイラおよびRubyコアライブラリにおいて最高の基盤ができました。
すでにRubiniusプロジェクトはRuby空間に対し多くの改善をもたらした。昨今すべてのRuby実装で使用されているRubySpecsについてBrian氏は述べた。Rubiniusを起源とする別のライブラリは、Ruby FFIライブラリ(参考記事)である。
FIへの後押しはRubiniusによって開始されましたが、MRI gemがJRubyの功績です。それはお互いが共に得をする、Ruby実装のソリューションですが、特にMRIやRubiniusのようなRuby C-API拡張機能をこれまでサポートできないJRuby向けです。 われわれはFFIを実装することにしました。DLよりほぼ間違いなく優れたAPIがあったのと、実装にとても関連しているからです。すべての実装は、 Rubyコードに提供されるAPIに適合できますが、共有可能なFFI実装自体にはほとんど何もありません。
RubiniusのFFIおよびRuby FFIは、コールバックのサポート(リンク)の点で異なります。
現段階で、それらは優先事項ではありませんが、そうなるでしょう。Rubiniusは、Ruby CとAPIの互換性をC拡張の作成者に提供する唯一の代替実装です。すべてのことにFFIを使用する必要はありません。なぜなら、たとえばruby.hでImageMagickを再コンパイルすることができるからです。それで終わりです(われわれがまだC-APIで作業をしているから、ImageMagickが必要に応じて即座に作業をするということではなく、たとえばRubiniusで直接MRI Readline C拡張を使用するからです)。
Rubiniusについて詳しくは、InfoQでRubiniusのタグ(参考記事リンク)を参照のこと。
原文はこちらです：http://www.infoq.com/news/2009/02/ford-state-of-rubinius