Comments on: The Great Ruby Shootout (July 2010) http://programmingzen.com/2010/07/19/the-great-ruby-shootout-july-2010/ Meditations on programming, startups, and technology Wed, 01 Feb 2012 10:09:40 +0000 hourly 1 http://wordpress.org/?v= By: Antonio Cangiano http://programmingzen.com/2010/07/19/the-great-ruby-shootout-july-2010/#comment-18482 Antonio Cangiano Fri, 20 Aug 2010 07:41:52 +0000 http://programmingzen.com/?p=1233#comment-18482 Yes. Yes.

]]> By: Isaac Gouy http://programmingzen.com/2010/07/19/the-great-ruby-shootout-july-2010/#comment-18467 Isaac Gouy Fri, 20 Aug 2010 07:34:56 +0000 http://programmingzen.com/?p=1233#comment-18467 Given the timeouts, I should ask which data made it into the summary - just data from rows which had no timeout or error? Given the timeouts, I should ask which data made it into the summary – just data from rows which had no timeout or error?

]]> By: Isaac Gouy http://programmingzen.com/2010/07/19/the-great-ruby-shootout-july-2010/#comment-18452 Isaac Gouy Fri, 20 Aug 2010 01:44:38 +0000 http://programmingzen.com/?p=1233#comment-18452 Aren't you curious to see if that bogus Prime measurement pushed Ruby 1.9.2 ahead of JRuby into first place? Aren’t you curious to see if that bogus Prime measurement pushed Ruby 1.9.2 ahead of JRuby into first place?

]]> By: Antonio Cangiano http://programmingzen.com/2010/07/19/the-great-ruby-shootout-july-2010/#comment-18423 Antonio Cangiano Thu, 19 Aug 2010 20:41:28 +0000 http://programmingzen.com/?p=1233#comment-18423 As I mention in the post, prime will be excluded from future tests. As I mention in the post, prime will be excluded from future tests.

]]> By: Isaac Gouy http://programmingzen.com/2010/07/19/the-great-ruby-shootout-july-2010/#comment-18422 Isaac Gouy Thu, 19 Aug 2010 20:39:14 +0000 http://programmingzen.com/?p=1233#comment-18422 The Computer Language Benchmarks Game measurements have now been updated for Ruby 1.9.2 and it still seems that JRuby is a little ahead on both x86 and x64 - so why doesn't it look like that in "The Great Ruby Shootout (July 2010)" ? Could it really be that "The Great Ruby Shootout (July 2010)" results are that badly broken from the Ruby 1.9.2 Prime benchmarks being rewritten in C ? Please re-run the statistics with Prime excluded as a sanity check. The Computer Language Benchmarks Game measurements have now been updated for Ruby 1.9.2 and it still seems that JRuby is a little ahead on both x86 and x64 – so why doesn’t it look like that in “The Great Ruby Shootout (July 2010)” ?

Could it really be that “The Great Ruby Shootout (July 2010)” results are that badly broken from the Ruby 1.9.2 Prime benchmarks being rewritten in C ?

Please re-run the statistics with Prime excluded as a sanity check.

]]> By: roger http://programmingzen.com/2010/07/19/the-great-ruby-shootout-july-2010/#comment-15120 roger Mon, 02 Aug 2010 19:26:54 +0000 http://programmingzen.com/?p=1233#comment-15120 @my22301 yes it would be faster, but Ruby is tricky because it does runtime setup of methods, so it wouldn't be easy... @my22301 yes it would be faster, but Ruby is tricky because it does runtime setup of methods, so it wouldn’t be easy…

]]> By: my22301 http://programmingzen.com/2010/07/19/the-great-ruby-shootout-july-2010/#comment-14841 my22301 Sun, 01 Aug 2010 21:12:01 +0000 http://programmingzen.com/?p=1233#comment-14841 will it not benefit ruby's speed if we use a true compiler rather than use an interpreter ? Is there any difficulty to make a compiler? will it not benefit ruby’s speed if we use a true compiler rather than use an interpreter ?

Is there any difficulty to make a compiler?

]]> By: Miguel de Icaza http://programmingzen.com/2010/07/19/the-great-ruby-shootout-july-2010/#comment-14401 Miguel de Icaza Sat, 31 Jul 2010 03:23:54 +0000 http://programmingzen.com/?p=1233#comment-14401 Hello folks, I am late to this fascinating discussion. A bug in Mono's runtime caused IronRuby to enter a code path that calls Debug.Log too often which slows down the code by an order of magnitude. We did not find out about these errors until recently, due to a mistake on my side. The Microsoft IronRuby team reached out to us months before they released the latest IronRuby, but I never noticed their email until it was too late where they raised a number of bug reports and pointed out some of our limitations. I only looked at this about two weeks ago while clearing my mail queue and we were able to fix these problems quickly. We have gained the performance back and these fixes will be in our upcoming Mono 2.8, or are available today from GitHub's Mono (http://github.com/mono/mono). The Microsoft guys were kind enough to file the bugs that they identified in Mono and we have fixed almost all of them now. There are a couple of them that we are still working on. That being said, with Mono 2.8, you can expect the IronRuby test suite to run 10 times faster (not sure about this benchmark, but if someone emails me the instructions, we can look at testing it as well). There is also a nice performance boost from using our new GC (also available on github, and on the upcoming 2.8 release) depending on the test we get a 10% to 40% performance increase (this is from an email from Paolo who tried some of the tests on this page). We still have a few unoptimized code paths in Mono that will likely impact IronRuby performance on Linux, but they should be fixed eventually. Our goal is to match the .NET performance on equivalent hardware. Miguel. Hello folks,

I am late to this fascinating discussion.

A bug in Mono’s runtime caused IronRuby to enter a code path that calls Debug.Log too often which slows down the code by an order of magnitude.

We did not find out about these errors until recently, due to a mistake on my side. The Microsoft IronRuby team reached out to us months before they released the latest IronRuby, but I never noticed their email until it was too late where they raised a number of bug reports and pointed out some of our limitations.

I only looked at this about two weeks ago while clearing my mail queue and we were able to fix these problems quickly. We have gained the performance back and these fixes will be in our upcoming Mono 2.8, or are available today from GitHub’s Mono (http://github.com/mono/mono).

The Microsoft guys were kind enough to file the bugs that they identified in Mono and we have fixed almost all of them now. There are a couple of them that we are still working on.

That being said, with Mono 2.8, you can expect the IronRuby test suite to run 10 times faster (not sure about this benchmark, but if someone emails me the instructions, we can look at testing it as well).

There is also a nice performance boost from using our new GC (also available on github, and on the upcoming 2.8 release) depending on the test we get a 10% to 40% performance increase (this is from an email from Paolo who tried some of the tests on this page).

We still have a few unoptimized code paths in Mono that will likely impact IronRuby performance on Linux, but they should be fixed eventually. Our goal is to match the .NET performance on equivalent hardware.

Miguel.

]]> By: roger http://programmingzen.com/2010/07/19/the-great-ruby-shootout-july-2010/#comment-14302 roger Fri, 30 Jul 2010 17:07:59 +0000 http://programmingzen.com/?p=1233#comment-14302 A couple of notes: 1) even though jruby uses tons of RAM, it manages that RAM efficiently, and avoids slowdown for larger apps. I think I'll add a benchmark to show this fact a bit better. 2) jruby can start quickly--for me on windows it only takes about 1s if I use the faster_rubygems gem. Thanks for the nice shootout. -r A couple of notes:
1) even though jruby uses tons of RAM, it manages that RAM efficiently, and avoids slowdown for larger apps. I think I’ll add a benchmark to show this fact a bit better.

2) jruby can start quickly–for me on windows it only takes about 1s if I use the faster_rubygems gem.

Thanks for the nice shootout.
-r

]]> By: roger http://programmingzen.com/2010/07/19/the-great-ruby-shootout-july-2010/#comment-14266 roger Fri, 30 Jul 2010 10:02:29 +0000 http://programmingzen.com/?p=1233#comment-14266 No rdoc benchmark? :) No rdoc benchmark? :)

]]>