I obviously have, but I have a lot of respect for the MRI folks and usually don't publish those results. You're free to try it out yourself. In general, JRuby should be significantly faster than MRI 1.9.2 or 1.9.3 for running Ruby code, and usually faster inside the core classes (String, Array, etc). If it's not, I consider it a bug, and encourage bug reports to that effect.
Until recently I dismissed JRuby, but then I needed to run some stress testing code against an Oracle DB. With MRI Ruby and the OCI8 library, the Ruby overhead stopped me being able to push the database hard enough. I switched to JRuby and JDBC and the results were amazing, so I am converted. The only niggle I have is the startup overhead, which I know is a JVM thing. Not a problem for my benchmarking, but a little bit of an annoyance for a command line ruby tool I use.
As an aside, I did run across a bug, not performance related, but a case around popen where JRuby doesn't behave the same as MRI - I raised a ticket (JRUBY-6225) but it doesn't seem to be getting any traction. I understand there are probably plenty of tickets to be prioritized, but this one is a bit of a show stopper for me. If anyone from the JRuby team is see this and has time to have a look at it I would be grateful.
There seem to be a few bug reports all around the same phenomenon. See also JRUBY-6162. I started digging into it a bit last week, but I was in the middle of a release and didn't have time to get very far. My working hypothesis is that the external process is getting killed off by JRuby before it has time to finish executing. The (hacky) workaround is to make your code wait a bit so the process has time to complete. Faster JRuby execution might only make the problem worse :-), but I'm looking forward to playing with it!
6162 does sound very like my issue. I must try sticking a sleep inside the block passed to popen and see if that gets past my problem. It's not a solution as such, as the process I am calling could take anywhere from a second to many minutes to execute, but it will be interesting to try. If you manage to solve these bugs it will be a great help to me, so good luck!
Recently we've been working more on JRuby master, on new features and performance. With JRuby 1.6.6 coming soon and 1.7 starting to stabilize, we'll be circling back to these bugs.
I'd love to help, but my Java skills are almost none existent! If I thought I could make any headway into that bug I'd jump in - maybe over the holidays I will try and have a look.
Why would respect for the MRI devs stop you from publishing benchmarks? It's not an insult to say that something else is faster. I'd imagine the competition might drive them to improve if at all possible.
I feel like the MRI devs get beat on a bit too much, and they're doing the best job possible with very few paid developers. I'm more interested in showing how JRuby is improving over time than rubbing salt in the wounds.
Speaking of very few paid MRI developers, does anyone know if the Ruby project takes donations to hire full-time paid developers? If yes, could you please point us to the donations page?
After matz announced he was hired by Heroku I spoke with him on how he plans to hire developers. He doesn't want one company to have all the MRI developers, so the best way to create a new paid MRI committer is to hire one specifically to do so.
Really glad that @headius is getting some recognition for his dogged work in this space. I know he's been up against a sometimes quite hostile Ruby crowd but has remained a gentleman throughout.
I'm not really familiar with the ruby development process and community and haven't used the language much, but I could imagine the MRI developers spend considerable time advancing the actual design of the language (syntax, standard APIs, etc.) whereas the other Ruby implementations "only" need to implement that design and thus can maybe focus more on performance. If MRI were to die, that design work would still need to be done in order to push the language forward. As such it could be seen as a symbiotic relationship, not competition.
Yes, I'd say that's at least partially true. The innovation on JRuby's side is in new ways to integrate with the JVM, rather than in API or language design. MRI folks need to innovate both in how they design the language and APIs and in how they implement them.
