Should don-developers be using this list too?
philip_rhoades
I want to convert a C/C++ population genetics simulation program to
Ruby/Rubinius - is this list the right place to ask questions and get
advice?
Thanks,
Phil.
Chuck Remes
It is best to ask on the rubinius irc channel (#rubinius on irc.freenode.net) if you want fast feedback. You may also ask here though this list is very quiet.
Ask in both places and see what happens. :)
cr
Chuck Remes
On Sep 24, 2010, at 8:40 PM, Philip Rhoades wrote:
> Chuck,
> I did ask on the irc channel and got some good info but my time zone suits email I think. Arising from the info I went looking for comparisons and found this:
>
> http://programmingzen.com/2007/02/19/ruby-implementations-shootout-ruby-vs-yarv-vs-jruby-vs-gardens-point-ruby-net-vs-rubinius-vs-cardinal/
>
> - although it is a few years old now. Have things changed? - Rubinius looks the slowest . . are the VMs predicted to be faster as they mature?
Phil, that link is from 2007. Several of those Ruby runtimes haven't been touched in years (like Cardinal).
Take a look at the shootout done in July of this year. It's a bit more representative.
http://programmingzen.com/2010/07/19/the-great-ruby-shootout-july-2010/
Of course, the *best* benchmark is to run your own code. Most of the benchmarks used in these shootouts don't actually test what their names imply... many times a test of numerical crunching speed really turns into a test of how fast the runtime can build a string, append to an array, garbage collect some objects, etc. Well written benchmarks are hard to come by so therefore it is always best to use your own real-life code.
In my daily life, I use JRuby for nearly all of my work. However, it does *very* poorly when running the mongo-ruby-driver so for certain situations I use MRI 1.9.2 with the mongo C extension to get performance several orders of magnitude better than JRuby can currently provide. I also wrote some small patches for that driver to vastly improve its performance under Rubinius to the point where it is within spitting distance of MRI's performance.
When I run all of my project specs using MRI 1.9.2, JRuby 1.5.1 and Rubinius 1.1 I see that they result in the following execution times (for about 1800 rspec examples):
MRI => 1.7 seconds
JRuby => 13 seconds
Rubinius => 10 seconds
So now I see that Rubinius has overtaken JRuby for *my* particular workload. This can and will likely change in the next 3 months as JRuby and Rubinius undergo another release cycle. Each of the runtimes *always* gets faster from release to release, so to answer one of your questions, yes the VMs are predicted to get faster as they mature.
JRuby uses native threads with no Global Interpreter Lock (GIL), so it is possible to scale it across all of the cores in your computer if you are using threads or some other concurrency mechanism. Rubinius has the "hydra" branch which removes the GIL and will also provide linear scaling across cores; this is on the roadmap for post 1.1. MRI 1.9.2 uses native threads, but the GIL will be around until *at least* the release of 2.0 which is several years away.
So while MRI may have the best "straight line" performance right now, JRuby today and Rubinius (soon) will kick its ass on workloads that require high concurrency.
Sorry for the long email. Too much time on my hands on this beautiful Saturday morning... :)
In summary, run your code under all of the runtimes and see how they perform. Use ruby-prof on MRI, jruby-prof on JRuby, and pass -Xprofile to Rubinius to get call tree profiling information to help you optimize your code. You aren't going to get C-equivalent performance out of any of them, but it should be pretty good. Ask for help on the various irc channels and we'll all try to lend a hand with code improvement and/or fixing bottlenecks that you have identified via your profiling.
Have a nice weekend.
cr