Rubiniusの話題総まとめ

Rubiniusは大部分がRubyで実装されているRubyのVMだ。ローレベルな部分に関しては多少C言語で実装されているが、いずれそれらもRubyで書き換えられる予定だ。Rubiniusの詳細に関しては、InfoQのEvan Phoenix(記事・英語)とのインタビュー記事を参照して欲しい。この1年くらいの間、Rubiniusは関心を集め(source)、開発者を獲得してきた。そして少しずつだが未実装の機能を実装したり、互換性を保つよう律儀に対応してきた。JRuby開発チームの一員であるOla Bini氏は、つい最近Rubiniusに関する自身の考えをRubiniusは重要だというタイトルの記事に書いた。

実際のところ私はJava基盤がもたらすものを必要としていない人々にとって、RubiniusがRuby周辺技術の中で最も重要なプロジェクトであると確信を深めています。そのこと以上に、RubiniusはMRIを正しく実装したVMです。Ruby 1.9.1の現在のスケジュールとプランに大きな変更がなければ、今後６ヶ月以内にRubiniusがC言語で実装したRubyの選択肢として浮上するであろうと予測しています。

彼は自分の意見の論拠を箇条書きにして付け加えている。

• Rubiniusはバイトコードベースです。このことはパフォーマンスを取り扱うことがより簡単であることを意味します。
• Rubiniusはプラグイン可能な非常に奇麗なアーキテクチャであり、そのことは例えば別のアルゴリズムを使うためにガベージコレクション又はオブジェクトのメモリを無効に出来ることを意味します。
• Rubiniusは実際はまだ実現してないが、スレッドセーフ且つMulti-VMが可能であるように設計されています。
• Rubiniusは既存のMRIエクステンションと共に動作します。
• Rubiniusのコードの大部分はRubyで書かれています。
• あなたが書いたRubyコード(MethodコンテキストまたはBlockコンテキストのようなコード)から直接Rubiniusへアクセス出来ます。
• プロジェクトはValgrindを使用し、Rubinius 内に存在するCのコードが非常に信頼性が高いコードであることを保証しています。

他に改善された点はパフォーマンスである。Evan Phoenix氏はRubiniusとRuby 1.8.x通称Matz Rubyを比較したベンチマークの結果(source)を最近発表した。結果を見ると、多くのテストでRubiniusがMatz Rubyよりリードしていることが分かる。以下はEvan Phoenix氏の分析である。

私が指摘したい傾向が幾つかデータの中にあります。

• エラーまたはタイムアウトにならなかったテストのうち、rubiniusは31項目中24項目でMatz Rubyより速かったです。前回のテストのときよりもパフォーマンスが大きく向上した。
• bm_soの最も遅いセクションを見てみると、Rubiniusは11のテストの内Matz Rubyより速かったのは2件のみで、実際にエラーまたはタイムアウトが起きたテストは4件ありました。
  ベンチマークを見ると、それらは基本的にコアなメソッドに関するテストであることが分かるでしょう。主にString関連のテストです。
  従って、現段階で、コアなメソッドのスピードが遅いのは当然で、何故ならそれらを未だ調整していないからです。
•  一つの大きい傾向は、VMのアーキテクチャにただストレスを与えたテストが、より速くなったということです。bm_vm1_swapとbm_vm1_simplereturnという例が二つあります。最初の例は、a,b = b, aを使用して二つのローカル変数を数百万回交換します。これはバイトコードVMがMRIのTree walkerよりずっと速いということを示す良いサンプルです。次に、bm_vm1_simplereturnは、Rubiniusがメソッドコンテキストを早く作成でき、呼び出し元へ早く返せることを示しています。私はこの数字に興奮します。なぜならRubiniusのメソッドコンテキストが、たとえ最高であったとしても、それらがプログラミングの力を失うこと無く3倍速いからです。

Rubiniusがバイトコードインタプリタを使用している点に注目することは重要である。JITコンパイラのような最適化、バイトコードをネイティブなコードへ実行時に変換することなどは、将来実現が予定されているものである。従って、よりいっそうパフォーマンスが改善されるだろう。高度な設定が可能なガベージコレクション戦略のような最適化は、より一層パフォーマンスアップアップに貢献するだろう。

Rubiniusは様々な形で支援されている。Evan Phoenix氏は、Rubiniusに取り組むためにEngineYardに雇われた(記事・英語)。最近では、Sunがスポンサーとなり、Rubinius開発者のWilson Bilkovich氏(source)やBrian Ford氏(source)に Rubinius sprint.への旅費を支払った。またJRuby開発者のCharles Nutter氏をRubinius sprintへ送った。改善リストから判断すると、それは生産的な会議であったに違いない。

• Evan氏は、我々のとてもクールなRuby C APIと互換性のあるコンポーネントを使用してYAMLパーサのSyckを組み立てました。
• Wilson氏は二時間で沢山のStringIOの仕様を案出しました。
• Evan氏は、すぐにその仕様を満たすRubyのStringIOを書き始めました。
• Charles氏は、たくさんのdefとcaseの仕様を取り出し、コンパイルをたくさん行った。
• Wilson氏は、パックトレース上で決定的な失敗や重大なポイントを拾い上げることが出来るようなバックトレースを追加しました。
• Wilson氏はコンパイラで無くなってしまった機能の残りを実装しました。   
•  Charles氏は基本的なObjectSpaceのサポートを追加しました。
• 私は再編成を完了し多くの修正を我々のRubyコアライブラリにチェックインしました。2800の仕様の内、３分の２を終えました。依然として約50%のコアライブラリの仕様が残っており、それらを完了させなくてはいけない。
•  Evan氏は我々のスレッドサポートを修正し、いくつか回避策を加えた。
• I RubyからCのintegerとdoubleに対して読み書きをサポートするために、Evan氏からの多大な援助を受けそしてx86マシン語を取り扱っている大変まじめなgdbのセッションから学び、我々の外部機能のインタフェースに対してクールなものを私は追加しました。 (doubleのサポートはEvan氏から魔法的なタッチを依然として必要としています。)それを使用して私はMathメソッドのサポートとMathの仕様の実装の残りを終えることが出来ました。
• Wilson氏はevalのコンパイルをサポートするために必要とされている機能を沢山実装しました。 このことが、どれほどすごいことで且つ痛みを伴ったことか分からないのであれば、私を責めないで下さい。
• Dir.globに備えてFile.fnmatchの実装に着手し、fnmatchの仕様を完了させました。

またRubiniusは、Rubinius GemstoneのOODBがJRubyとRubiniusをサポートという最近のインタビュー記事(記事)で言及されているように、GemstoneのOODBでRuby計画のために役割を果たすようである。

原文はこちらです：http://www.infoq.com/jp/news/2007/09/gemstone-ruby