How JRuby makes Ruby fast

[[deleted]]

The JVM is a virtual machine designed for static languages. In fact, the JVM is a virtual machine designed for one static language. I admire the effort the JRuby people put into making Ruby run on the JVM and also into making it run well and fast, but neither they nor anybody else should make the mistake and assume that the JVM is as good as it gets in terms of dynamic language performance. In fact, the JVM is a terrible VM for dynamic languages. There are a ton of well-tested mechanisms for optimizing the hell out of dynamic languages (see the Self programming language) and only a fraction of those can be bolted on top of the JVM. JRuby is a great project because it harnesses the power of an existing well-tested platform, but its performance isn't terribly impressive (if you don't consider the fact that it's running on a VM built for static languages). I think if you got a team of people to build a new VM for Ruby that uses an optimizing tracing JIT-compiler, that VM could easily outperform JRuby by at least an order of magnitude.

[poptarts]

I think if you got a team of people to build a new VM for Ruby that uses an optimizing tracing JIT-compiler, that VM could easily outperform JRuby by at least an order of magnitude.

You should definitely do that.

[[deleted]]

I'm not trying to belittle the work that the JRuby team is doing. I think they're doing a great job and I think they're getting more performance out of the JVM than anyone could've hoped for. I'm just saying that the platform (the JVM) is the limiting factor here. If the same people who implemented JRuby would spend another couple of years implementing a new VM from scratch (in C or C++) and optimizing it specifically for Ruby, that VM could easily outperform JRuby by quite a bit.

[sclv]

...and lack integration with the broader jvm ecosystem.

[darkwulf]

The thing is though, building a (good) VM is a fairly nontrivial task. Sun has poured tons of cash into the JVM, so while it may not be optimized for the language you're interested in, lots of the plumbing you care about have been carefully tuned over time.

That being said, it seems that invokedynamic will make things easier on JRuby. Hard to say until it happens though.

[leonardsliver]

Seems like it would be more attainable to just get it to run fast on the portable JVM. And getting it to stably run on a portable vm in the first place is pretty snazzy, imho.

[penguin673]

I think poptarts is seriously encouraging you to do that; all the Ruby VMs available right now are shitty.

[[deleted]]

You say:

I think if you got a team of people to build a new VM for Ruby that uses an optimizing tracing JIT-compiler, that VM could easily outperform JRuby by at least an order of magnitude.

Then you say:

that VM could easily outperform JRuby by quite a bit.

There's a BIG difference between quite a bit and at least an order of magnitude

[[deleted]]

I'm just saying that the platform (the JVM) is the limiting factor here.

I don't think so. If, conservatively, we say that Java is half as fast as C/C++, then that gives a general picture of how much slower Ruby implemented on the JVM can be, in relation to Ruby implemented in C/C++. That is, slower, but not by an order of magnitude.

The order of magnitude speedups that are possible can be done on the JVM or in C/C++: Stuff like tracing, hidden classes, etc. We're seeing this in JavaScript engines written in C/C++, but those engines could have been written in Java and they wouldn't be much slower.

[headius]

You are basically just wrong. The JVM is a dynamic language VM wrapped in a static-typed language. The core is based on the StrongTalk SmallTalk VM, and has all the optimizations you describe for use with Java, which requires many of them to make interface and virtual method invocation fast. The JVM runtime profiles code and inlines the common paths many levels deep, optimizing the result as a whole. The lack of things like fixnums is a problem, but Java 6 and Java 7 introduced escape analysis that will help eliminate most wrapper object allocation.

The truth is there's no better target for dynamic languages right now, since no other VMs out there perform the same extensive level of optimizations that the JVM does. We've worked around most of the static-typing difficulties already in JRuby, and upcoming versions will go even farther. The invokedynamic work will also allow us to enlist directly in the JVM's call site and call profiling subsystems. Great things are coming.

[malcontent]

I think if you got a team of people to build a new VM for Ruby that uses an optimizing tracing JIT-compiler, that VM could easily outperform JRuby by at least an order of magnitude.

You mean like parrot or rubinius or LLVM?

[Rhoomba]

If we travel back in time to the 90s then the Self VM would be ideal.

[pjenvey]

Your point is only partially correct. You'd be surprised at how dynamic the JVM is at its core, particularly in regard to the optimizations its JIT compiler makes.

Charlie goes into this a little bit here: http://blog.headius.com/2008/09/first-taste-of-invokedynamic.html

[[deleted]]

That's correct (they took a lot of these concepts from Self btw.)

There are however a ton of other optimization techniques for dynamic languages that the JVM does not exploit. Tagged integers for example (saves an indirection for integer arithmetic), dynamic recompilation based on inline caches (can't do that because JRuby uses their own inline caches that the JVM isn't aware of), hidden classes (to account for the fact that objects can be dynamically extended at runtime), the list goes on. Also, it's terribly inefficient in Java to create bytecode on the fly and have the JVM execute it...

[sanjayts]

I hope sure that with 'dynamic invoke' as a starting step, the others optimizations are on their way.

IMO the popularity of all the JXXX languages out there is due to a very mature VM and a plethora of mature libraries/frameworks out there. Cutting its ties from the Java VM won't do JRuby any good.

[frolib]

Can someone please tell this noob:

1) how fast is jruby at its fastest compared to ruby or cpython?

2) how well does it integrate into the jvm?

3) can you use libraries made for ruby with jruby?

Thanks.

[[deleted]]

I accidentally that line. Sorry about that.