ruby-1.9.3-p125のベンチマークセットを使用しました。 すべてのテストが実行されました：
OS：OSX Lion 10.7.3
プロセッサー：2.3 GHz i5
メモリ：8GB 1333 MHz DDR3
SSD：OCZ Vertex 3 Max IOPS SATA III 2.5 "120GB
実装：
-ruby 1.8.7p249（システムruby）
-ルビー1.9.3p125
-ruby 2.0.0dev（2012-02-25トランク34796）
-MacRuby 0.12（ruby 1.9.2）（夜間ビルド）
-磁気浮上1.0.0（ルビー1.8.7）
-rubinius 1.2.4（1.8.7リリース2011-07-05 JI）
-rubinius 2.0.0dev（1.9.3 e22ed173 JI）
-jruby 1.7.0.dev（ruby-1.9.3-p28）（Java HotSpot（TM）64-Bit Server VM 1.7.0_04-ea）
-jruby 1.6.7（ruby-1.8.7-p357）（Java HotSpot（TM）64-Bit Server VM 1.7.0_04-ea）
JRubyは、フラグ--server -Xinvokedynamic.constants = trueで開始しました
コンパイラーが重要
パッチを使用してルビーのパフォーマンスを向上させることについての記事を時々見ますが、さらに進んで最新のコンパイラでコンパイルしてパフォーマンスを向上させようとしたらどうでしょうか？ 確認することにしました。
コンパイラのリストは次のとおりです。
-gccバージョン4.2.1（ビルド5658）（LLVMビルド2336.9.00）
-Apple Clangバージョン3.1（タグ/ Apple / clang-318.0.45）（LLVM 3.1svnに基づく）
-gccバージョン4.2.1（Apple Inc.ビルド5666）
-gccバージョン4.7.0 20120218（実験的）（GCC）
#!/bin/bash compilers=( gcc gcc-4.2 gcc-4.7 clang ) for i in "${compilers[@]}"; do CC=$i ./configure --disable-install-doc --prefix ~/Projects/benches/mri/1.9.3-p125-$i time make -j4 make install done $ ruby driver.rb -v -o ~/Projects/benches/compilers-bench.txt \ --executables='~/Projects/benches/mri/1.9.3-p125-gcc/bin/ruby; ~/Projects/benches/mri/1.9.3-p125-gcc-4.2/bin/ruby; ~/Projects/benches/mri/1.9.3-p125-gcc-4.7/bin/ruby; ~/Projects/benches/mri/1.9.3-p125-clang/bin/ruby'
結果：
デフォルトで使用されるllvm-gccと合成テストでのgcc-4.7の差の20％（ベンチマークは数回実行され、最良の結果を選択しました）。 悪くない、私には思える。
gcc-4.7で問題が発生しないことを確認してください。
PASS all 943 tests KNOWNBUGS.rb . PASS all 1 tests
自分で確かめたい
homebrewがインストールされている場合、これは簡単に実行できます。
$ brew install https://raw.github.com/etehtsea/formulary/009735e66ccabc5867331f64a406073d1623c683/Formula/gcc.rb --enable-cxx --enable-profiled-build --use-gcc
... 1時間後：
$ CC=gcc-4.7 ruby-build 1.9.3-p125 ~/.rbenv/versions/1.9.3-p125
ご注意 perev。 ruby-build
hereについて。
また、他のruby％実装はどうですか？
私はやめることができず、私の好奇心に取り組み、他の一般的なルビーの実装とMRIバージョンのベンチマークを開始しました。 ここには完全なログはありません。興味深い点のみを取り上げます。
デフォルトでインストールされたルビーを使用しないでください
これはキャッチです！
bm_vm_thread_mutex3.rb # 1000 , 1 require 'thread' m = Mutex.new r = 0 max = 2000 (1..max).map{ Thread.new{ i=0 while i<max i+=1 m.synchronize{ r += 1 } end } }.each{|e| e.join } raise r.to_s if r != max * max
$ time ~/.rbenv/versions/1.8.7-p357/bin/ruby bm_vm_thread_mutex3.rb real 0m3.093s user 0m3.078s sys 0m0.013s $ /usr/bin/ruby -v ruby 1.8.7 (2011-12-28 patchlevel 357) [i686-darwin11.3.0] $ time /usr/bin/ruby bm_vm_thread_mutex3.rb ^Cbm_vm_thread_mutex3.rb:18:in `join': Interrupt from bm_vm_thread_mutex3.rb:18 from bm_vm_thread_mutex3.rb:7:in `each' from bm_vm_thread_mutex3.rb:7 real 3m54.930s user 3m54.122s sys 0m0.918s
スレッドを使用しない場合でも、このテストなしの結果は次のとおりです。
ルビー1.8.7（2010-01-10）-572.863秒
ルビー1.9.3p125（2012-02-16）-211.655秒
1.8失敗したテスト：
-bm_app_factorial.rb
-bm_so_ackermann.rb
Rubinius 1.2.4 vs 2.0.0-dev
2.0.0-devにはGILなどがないことを読みました。 など。ただし、この次期バージョンは著しく低速です。
最も顕著なスローダウンは、まだ同じbm_vm_thread_mutext3.rbテストにあります：
-rubinius 1.2.4（1.8.7リリース2011-07-05 JI）-3.260秒
-rubinius 2.0.0dev（1.9.3 e22ed173 yyyy-mm-dd JI）-207.711秒
違いが最も顕著になるテストは次のとおりです。
そして、これらのテストなしの結果は次のとおりです。
1.2.4-518.861秒
2.0.0dev-606.811秒
ルビニウスは決して高速ではありませんでしたが、さらに15％遅くなりました。
テストが失敗しました：
-5kではなく階乗4k
-bm_loop_generator.rb
-bm_so_ackermann.rb
-bm_vm_thread_pass_flood.rb（テストは実行タイムアウトを超えました）
MacRuby 0.12（夜間）
MacRubyは、OS X用のデスクトップアプリケーションを作成する場合、またはOS X APIを使用する場合に必要なものですが、パフォーマンスの観点からは使用する意味がありません。
まず、MacRuby（bm_vm2_eval.rb）のevalはかなり遅いです：
ルビー1.9.3p125（2012-02-16）-29.681秒
MacRuby 0.12（Ruby 1.9.2）-232.257秒
bm_vm2_eval.rb i=0 while i<6_000_000 i+=1 eval("1") end
したがって、erb解析および作成クラスインスタンスとして：
bm_app_erb.rb # # Create many HTML strings with ERB. # require 'erb' data = DATA.read max = 15_000 title = "hello world!" content = "hello world!\n" * 10 max.times{ ERB.new(data).result(binding) } __END__ <html> <head> <%= title %> </head> <body> <h1> <%= title %> </h1> <p> <%= content %> </p> </body> </html>
1.9.3p125-1.817秒
MacRuby-81.808秒
bm_vm3_clearmethodcache.rb i=0 while i<200_000 i+=1 Class.new{ def m; end } end
1.9.3p125-0.748秒
MacRuby-86.573秒
失敗したテスト：
-bm_loop_generator.rb
-bm_so_count_words.rb
-bm_so_nsieve_bits.rb（タイムアウト）
-bm_vm_thread_create_join.rb（タイムアウト）
磁気浮上1.0
興味深いことに、MagLevにも同様の問題があります。
bm_vm2_eval.rb-754.028秒
bm_vm3_clearmethodcache.rb-33.785秒
JRuby 1.6と1.7.0-dev
JRuby 1.7.0-devのパフォーマンスは1.6.6と同様ですが、bm_vm_thread_mutex3.rbテストがわずかに改善されています。
1.7.0-dev-14.381秒
1.6.6-202.552秒
全体的な結果は次のとおりです。
1.7.0-dev-257.584秒
1.6.6-229.502秒
失敗したテスト：
-bm_io_select.rb
MRI 2.0.0-devと1.9.3-p125
同じ状況がMRIのdevブランチにもあります。 bm_vm_thread_create_join.rbテストのみの改善：
ruby 2.0.0dev（2012-02-25トランク34796）-2.806秒
ルビー1.9.3p125（2012-02-16）-9.239秒
総合順位
要約グラフ：
なしのグラフ：
-bm_vm_thread_mutex3.rb
-bm_vm2_eval.rb
-bm_vm3_clearmethodcache.rb
すでにそれほど悪くないでしょう？
PS。 翻訳者から ：ロシア語を話す著者が記事を翻訳するのはかなり珍しいことでした。