長く待たれた Rubinius 1.0 がやっとリリースされた。開発期間が３年半以上かかったが、Rubyで書かれたRubyの実装がやっとでき、いくつもの有望なフィーチャが提供されている。
Rubinius 1.0は、Ruby開発者に多くのフィーチャを宣伝している。その中には:
- 大量のRubyコードと人気のあるCの拡張ライブラリをサポート:
- Rails 3 と 2.3.5
- Sinatra
- sqlite3, mysql, nokogiri, yajl-ruby
- もっと、もっと!
- Rubyコードの実行を加速するためのJITコンパイラ
- 世代別ガベージコレクション
- 統合されたプロファイラ
過去、InfoQは、当時のプロジェクトの状況を説明している RubyConf 2009での Evan Phoenix氏とのインタビュ を含めて、 Rubiniusを取り上げてきた。我々はまた、 Brian Ford氏によるRubiniusと標準との関係を説明した話を含んだRuby標準の おもしろい見解 についても書いた。今日まで話を進めて、Brian Ford とEvan Phoenix Rubiniusの両氏に追いつき、 1.0 とその将来について話を聞いた。
やっと、Rubinius 1.0 がリリースされましたが、このリリースは、実装とその将来にとって何を意味するのかを聞かせてください:
1.0は、この約４年近くの開発の頂点です。我々は、動的言語を高速にする多くの最新の研究を使った1.8.7互換のRubyの実行環境を開発しました。この中には、世代別ガベージコレクションや統合されたJITコンパイラなどがあります。
我々のアプローチは、できるだけRubyで書くことだったので、現時点で欠けているのは、いくつかのメソッドにおけるパフォーマンスです。これは、 Rubiniusがメソッドの実装にRubyを走らせているのに対して、MRIは、Cを走らせているためです。我々は、メソッドとシステム全体のパフォーマンスを改善したので、パフォーマンスでRubyのコードがCのコードと張り合えるのがわかると思います。
既存のRubyのフレームワークとの互換性に関しては:
完全に互換です。ある方法で、Sinatra アプリを走らせると、予測不能なバグがありましたが、1.0ですでに対処しました。 Rubiniusの下で、これらのフレームワークを走らせていて、バグに出くわしたら、我々は、バグのすぐそばにいるので、次のバグ修正のリリースには、修正します。
既存の Ruby gemをどの程度 Rubiniusは、サポートできるのかを聞いたら
もしRubyが純粋のRubyなら問題ありません。我々は、また Nokogiri, Mongrelや他の多くのCによる拡張ライブラリを持った非常に多くのgemもサポートします。サポートできないものもあります。我々は、Cの拡張エンジニアと協働で、我々のサポートできるAPIを支持し、サポートできないAPIを廃止するようにしてきました。。我々がいくつかのものをサポートできない理由は、MRIがクラスを実装するのに使っている内部構造体のメモリを直接APIがむき出しにするものです。例えば、RHASH() は、MRI がHashを実装するのに使っている生のC構造体である 'st' 構造体のポインタに直接アクセスすることを許してしまいます。我々は、ハッシュの実装にstを使ってませんから、これを提供する方法はありません。その代わり、実装できる方法で、同じ機能を提供するAPIを書きました。
我々は、 Rubiniusでは、string（文字列オブジェクト）が遅くなる傾向にあると聞いた、そして大抵のRubyのアプリにおいて、stringは、大きな部分を占めるので、現在、Rubiniusを使ってどの程度期待できで、将来、この問題は、どのように処理されるのかを知りたかった:
全てのstringが1.8.xより遅い、と言うのは正確でありません。Stringメソッドの多くは、1.8と同じか速いです。現在のところ、僅かなものだけが、遅い、例えば、tr, gsub, unpackなどです。我々はこれらをより高速にするために鋭意開発中です。
パフォーマンスの話題は、いつでも面白い、他のRuby実装、例えば、 MRI 1.8.x/1.9.x や MacRubyに対して Rubiniusは、どうなのか質問すると:
Rubinius は、Rubyコードを実行時には非常に速い、もしベンチマークが純粋のRubyアルゴリズムを使っているなら、Rubinius は、一番です。我々のJIT技術のために、 MacRubyより速いパフォーマンスを提供できます。より速いマシンコードを生成するために、プロファイルの情報を利用できるのも効いています。
ユーザがRubinius がより遅いと感じるのは、いくつかのコアクラスのメソッドを呼び出した場合です。遅い問題を 我々の問題トラッカーで ユーザに公開します。#rubiniusで調べてください。各リリースで、溝を小さくし、最後には、1.8と比べてパフォーマンスの点で、全てのコアメソッドにおいて Rubiniusが勝てるようにしたいです。
Rubiniusは、オープンソース プロジェクトで、オープンソースプロジェクトが成功し、成長するかは、コミュニティにかかっている。いかにコミュニティがこのプロジェクトを最大限に助けることができるか、聞いた:
我々は、コードベースをアプローチしやすくして、強化したりハックするのが簡単にできるようにしたのを誇りに思っています。我々は、多くのシステムを実装するのにRuby自身を使ったので、機能を早く書き、デバッグできるので、ユーザに新しい機能やバグ修正を早く提供できます。
コミュニティが今できる最大のことは、 Rubiniusで自分たちのコードを走らせて、成功と失敗を報告することです。こうすることが、我々が成長し、今ある欠陥に対処するのを助けることになります。
短期と長期の両方で、我々が次に何を期待できるかについては:
我々は、既に次のバグ修正とフィーチャリリースを計画しています。1.0.1は、おそらく来週（5/24の週）にリリースされ、その後も新しいユーザによって1.0で見つかったバグを修正し続けていきます。
最初のフィーチャ リリース、1.1で優先度の高いものの１つは、デバッガーです。私は、この開発を積極的に行っていて、順調にいってます。ユーザは、本当に、デバッガーとシステム全体が密接に統合されたのを実感できる、と思います。
Rubiniusは、Googleに rubinius-devリスト を持ち、開発者が参加して、質問することができる。
Rubinius webサイトにRubinius 1.0 についてもっと詳しい情報があり、ソースコードは、プロジェクトのGithubリポジトリからダウンロードできる。