InfoQ

InfoQ

News

マイブックマーク

ブックマークするためにログイン または 会員登録 する

ブックマークされました!

ブックマークがエラーになりました。もう一度お願いします。

Rubinius 1.0 は MRI 1.8 との互換性と同等の速度をもたらす

作者 Mirko Stocker , 翻訳者 鰈崎 義之 - CSKシステムズ 投稿日 2009年12月6日

セクション
デベロップメント
トピック
ランタイム ,
Ruby on Rails ,
Ruby
タグ
RubySpec ,
仮想マシン ,
Rubinius

原文(投稿日:2009/12/03)へのリンク

"Ruby プログラマのための Ruby" Rubinus は、ようやく 1.0 のリリースを迎えようとしている。実環境のアプリケーションを実行するための互換性、MRI 1.8 と同等の性能、コードの品質に、1.0 リリースは焦点を当てている

Rubinius リード開発者の Evan Phoenix は、このリリースがこんなにも重要な理由と何を含んでいるかについて、InfoQ に語った。

1.0 は、私たちが Rubinius を始めて以来取り組んできた、本当のリリースです。私たちは 1.8 との互換性と同等の速度に近づくことを目指しています。既に互換性は非常に高く、RubySpec を使うことで指導力としています。

速度面では、既に Rubinius は多くの点で 1.8 よりも何倍も速いです。一押しは、1.8 実装を構成している C コードと同等の速度で動作するコアクラスを実装する、全ての Ruby コードを獲得していることです。

既に私たちは、実環境でのそのままのコードが Rubinius 上で数倍速くなっているという、いくつかの外部報告を得ています。確かにそれらの結果は、1.0 のすべてのコードに対して拡大できるわけではないでしょうが、私たちが本当に近づきつつあることを示しています。

Rubinius は、Low Level Virtual Machine (LLVM) コンパイラ基盤をネイティブコードの生成に使うことができます。ここで留意するべきは、LLVM が現在 RC1 においてデフォルトで有効になっていないことです。

LLVM の仕事は偉大です。1.0-rc1 において、LLVM が組み込まれた Rubinius を手に入れるためには、 configure に --enable-llvm オプションを渡す必要があります。rc2 においては、デフォルトで LLVM を有効にして作成するようにし、もし使いたくないなら無効にできるように、私たちはおそらく変更するでしょう。

もし LLVM が組み込まれていれば、デフォルトで JIT は有効になり、何度も実行されるメソッドを自動的にコンパイルします。私たちは、LLVM から素晴らしい成果を、特にプロファイリングのような作業で使うことで、得ています。これは、どのメソッドが共通に呼ばれていて、それらをインライン化して、性能を向上できるかを示すことができます。

初期の Rubinius においては、焦点は網羅性の向上であり、それは RubySpec へと繋がりました。今では基準は、性能を支持するように移りました。あるいはまだ網羅性のままでしょうか?

私たちは、どちらにも焦点を当てています。以前は、焦点は主に網羅性でした。しかし昨年の間に、私たちは性能に多く焦点を当てるようになりました。LLVM の仕事は、その直接の結果です。そして多くの時間を費やしています。

性能としては、素晴らしくなってきました。マイクロベンチマークにおいて、私たちは、1.8 よりもかなり速く(何百倍とまではいきませんが)なっています。しかし知ってのとおり、マイクロベンチマークの結果は、実環境のコードにそのまま当てはまるわけではありません。この点において、私たちはあちこちの結果を見ているところです。何人かのユーザは、数倍の速さだと報告しています。何人かは同様の性能を報告しています。かなり性能が遅くなったという報告もあります。

すぐに私たちは、性能が低下するそれらの領域に真剣に取り組んでいます。私たちは、性能の課題を分離し修正することを支援する、内臓プロファイラのような多くの素晴らしいツールを自分自身で作りました。

性能の改善では、私たちは最初に ruby コード自体の改善を作ることを調査します。これは、アルゴリズムに関する改善や非効率なコードの修正という長い道のりを行くことになります。

性能改善するための、もう一つの主なツールは JIT の改善です。ruby コードをより効率的なマシンコードへとコンパイルする方法を JIT に教えることは、大きな利益供与となり、私たちはいつもこれに取り組んでいます。

性能と互換性の改善に加えて、Rubinius は、end の閉じ忘れの際のエラーメッセージのように、他の領域でも進歩していますね。

そしておそらくもっとも興味深い質問、Rubinius 1.0 は Rails を実行できますか?

もちろん! rc2 では、rails 2.3.5 と rails 3 の両方を実行できるようになるでしょう。

1.0-rc2 は、12月末にリリースします。皆さんが年末年始休暇中に遊ぶのにちょうど良いように!

最初のリリース候補を Rubinius の Web サイトからダウンロードすることができる。さぁ、あなたの 1.8.6 におけるコードをテストして、見つけたすべての不具合を報告しよう。

特集コンテンツ一覧

GAE開発の落とし穴

Googleのクラウド環境をつかったGoogle App Engineによる開発するにあたり、初めての試みで苦悩する開発者達の経験をもとに、各開発フェーズにあわせて問題点やどう解決したかをご紹介します

イベントレポート:「Coqチュートリアル#1」

去る1月12日、定理証明支援系ツールCoqの初心者向けチュートリアルが開催さ れた(http://kokucheese.com/event/index/23667/)。今後も2月2日 (http://kokucheese.com/event/index/23744/)、2月9日、2月16日と引き続き開 催されていく予定である。本記事では、開催の様子をレポートする。

Javaの未来についてのNeal Gafter氏とのディスカッション

Choosing Options

Neal Gafter氏はOracleによるJava買収の影響に関する議論、Javaにセグメンテッドスタックやメタオブジェクトプロトコルを追加することについての主張、そしてJavaとC#との比較について話をしてくれた。

Google Dartのエッセンス:アプリケーションの構築、スナップショット、Isolate

GoogleはVMをともなう新しい言語であり、JSコンパイラでもあるDartをプレビューした。 InfoQはDartのアプリの構築に貢献する文法の裏側を探った:スナップショット、Isolate、モジュール方式

CSPベースのモデル検査ツール「Process Analysis Toolkit」

本記事ではCSPベースの「マルチドメイン・モデル検査ツール」である、PAT(Process Analysis Toolkit)について紹介する。モデル検査は、形式手法(Formal Method)という方法論を基礎とする技術であり、複雑さが増大しながらも安全性を求められる、現在のソフトウェア開発の状況に対する処方箋の1つとして注目されている手法である。

Jenkinsによる継続的インテグレーションのススメ(4) ~CloudBeesでJenkinsをサービスとして使う~

前回まで、Jenkinsの幾つかの側面に注目して解説をしてきました。シリーズ最後の今回は、Jenkinsをサービスとして使う方法を紹介します。

書籍『抽象によるソフトウェア設計-Alloyではじめる形式手法-』の紹介

Alloyは、MITにて開発された仕様記述言語であり、ツールによる自動解析を使い、インクリメンタルに形式仕様が書けることが特長である。筆者らはAlloy開発者による、Alloyを使った形式手法入門書を翻訳、今夏にオーム社より刊行した。本記事では、Alloyの簡単な概要と、翻訳書『抽象によるソフトウェア設計』(「Alloy本」)を紹介する。

Windows デバイスで開発するタッチユーザーインターフェイス

スマートフォンを中心としたマルチデバイスにおけるタッチユーザーインターフェイスへの対応は、既に必須の項目となりつつある。本記事では、Windows デバイスにおける UX のベースとなっている「メトロ」というデザイン言語を掘り下げながら、既存環境を意識しつつもどのようにタッチユーザーインターフェイス開発に取り組んでいくべきであるかについて解説していく。