Comments on: IronRuby vs JRuby vs MRI. Performance Mini-Shootout.

By: Recent Links Tagged With "jruby" - JabberTags

Recent Links Tagged With "jruby" - JabberTags — Tue, 30 Dec 2008 02:49:39 +0000

[…] 19-12-2008 JRuby access to C libraries using FFI Saved by flyingkaratechop on Fri 19-12-2008 IronRuby vs JRuby vs MRI. Performance Mini-Shootout. Saved by jimmyandsammy on Mon 15-12-2008 ruby-plsql gem now supports JRuby and Oracle JDBC driver […]

By: roger

roger — Thu, 04 Dec 2008 15:39:21 +0000

you should try kri
http://groups.google.com/group/ruby-benchmark-suite/browse_thread/thread/9560082a39adf6f0

By: John Lam

John Lam — Tue, 02 Sep 2008 14:21:16 +0000

Thanks for doing the investigation. The only perf-related stuff that we’re looking at right now is startup time and straight-line code throughput. In the short term, we’re going to write an interpreter to speed up startup. In the medium-long term, we’re going to look at cached precompilation.

By: Charles Oliver Nutter

Charles Oliver Nutter — Fri, 29 Aug 2008 16:50:57 +0000

Nothing published, but all the past JRuby versions are available out there.

By: Michael

Michael — Thu, 28 Aug 2008 14:16:09 +0000

Thanks for the clarification Charles. I would be curious if there’s any historical JRuby performance data just as way of comparison.

By: Charles Oliver Nutter

Charles Oliver Nutter — Thu, 28 Aug 2008 08:00:36 +0000

A bit more perspective: JRuby’s probably been completely rewritten a half-dozen times. The current core runtime shares little in common with the code from 2002. We’ve also only had full-timers on it since late 2006, shortly before John Lam went to Microsoft; before then it was a pure spare-time OSS project. Since most of JRuby core has been rewritten in the intervening two years (and we’ll give it another 6 months, since we really ramped up efforts a little before Tom and I were hired by Sun) it’s probably safer to compare IronRuby’s 1.5 years with the 2.5 years JRuby’s been under intensive work. Anything we gained before those 2.5 years would be akin to what IronRuby gained from work on Ruby.NET, IronPython, and DLR. And it’s safe to say that the runtime portions of the DLR are not just enabling technologies, they’re absolutely essential technologies for implementing dynamic languages on the CLR, since it does not do the same sorts of dynamic optimizations the JVM does. DLR, then, simply gives dynlangs on CLR a fighting change to compare performance-wise with the JVM as-is.

What am I trying to say? I guess that IronRuby is about on schedule in comparison to JRuby, all tings considered. And neither the DLR (great though it may be) nor the IronRuby developers (skilled though they are) make it any easier to implement Ruby on the CLR than on the JVM. And I doubt the current IronRuby team would claim any differently. Ruby is hard.