Rubyパフォーマンス：Shootoutの成果およびバイナリMRI対ソースコンパイル済みMRIに関する発見

作者 Werner Schuster , 翻訳者 編集部 投稿日 2008年12月18日

セクション

デベロップメント,

設計/アーキテクチャ

トピック

.NET ,

ランタイム ,

動的言語 ,

Ruby ,

Java ,

JRuby ,

パフォーマンス&スケーラビリティ

タグ

Ruby1.9 ,

仮想マシン ,

MagLev ,

IronRuby ,

JRuby ,

Rubinius

Rubyの実装間で競争がある。特にパフォーマンスの事柄についてである。1年前、Antonio Cangiano氏(リンク)がGreat Ruby Shootout(リンク)を実行した。1.8.6、1.9.0、JRuby、Rubiniusおよび今は中止となったRuby.NETの実装に匹敵するものだ。

Antonio氏はGreat Ruby Shootout 2008(リンク)を公開した。1.8.6、1.9.1、JRuby、Rubinius、Ruby Enterprise Edition(参考記事)、IronRubyおよび最新の追加であるMagLevに匹敵する。

つねに忘れずに基準に従って評価をすることは重要である。Antonio氏が最初の実行で問題を発見し、更新バージョンを公開した(リンク)とき、それにより結果が多少変更されたが、そのことが再び示された。発見した問題の1つは、Debianのパッケージ管理システムを通じて、利用可能なRubyバージョンである。

apt-getを通じ、Rubyをインストールする場合、本当に大きな明滅警告が起こる。これらのテストによると、ソースからのコンパイルでは、スピード が倍になる。100%ではなく、10か20%の増加を期待した。その要旨は、プリパッケージされたRubyはオプション --enable-pthreadsを使用してコンパイルされ、共用対静的ライブラリのあらゆる問題があるということだ。

以前、Prashant Srinivasan氏は --enable-ptreadの問題について言及し(リンク)、システムを低減させる理由を説明している。ベンチマークは、WindowsでのRuby 1.8.xは、Linuxでの1.8.7(ソースからコンパイル)のおよそ半分の速度で実行することを示している。

最速に関しては、一般に利用可能なRuby実装がRuby 1.9.1であり、JRuby 1.1.6RC1が続く。これらのベンチマークによると、JRubyは現在、Ruby 1.8.xコードを実行する最速の方法である。

もう一方のRuby実装、RubiniusおよびIronRubyは、たいていMRIより遅い。Ruby 1.9に基づいているMacRuby 0.3も、わずかに遅かったが、実働の準備が出来ているとみなされていない。次期リリースで整うと思われる(MacRuby 0.4は今年の終わりにリリース予定)。

MagLev(参考記事リンク)の成果が示すのは、多くのベンチマークがMRIよりも大幅に高速実行され、それより遅いものはわずかだろうということである。冷静にこれを判断すると、MagLevはまだ非常に若いプロジェクトであり、今年始めに開始されたばかりである。

最後に、重要な点である。Great Ruby Shootoutで使用されるベンチマークコードは、多くのマイクロベンチマークで構成され、RubyおよびRubyランチムの個別の機能をテストする。Antonio氏は、以下のように説明する。

テスト済みのVMがRuby on Railsのデプロイメントスタックにもたらすような改善に、多くの人びとが関心を抱いている。VM AがVM Bより3倍も高速であるなら、Railsが1分あたり3倍もの多くの要求を処理すると期待してはいけない。そうはいかない。そうは言っても、高速VMは良いニュースであり、実働においてRailsアプリケーションに確実に良い影響を与える。

InfoQとのインタビューで、Antonio氏はより現実世界のベンチマークの必要性を説明し(参考記事)、この目的のために立ち上げたRuby Benchmark Suiteプロジェクト(リンク)を指摘している。

 

原文はこちらです：http://www.infoq.com/news/2008/12/ruby-performance-shootout

• 次へ >