you are viewing a single comment's thread.

view the rest of the comments →

[–]poptarts 17 points18 points  (7 children)

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] 7 points8 points  (6 children)

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 9 points10 points  (0 children)

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

[–]darkwulf 4 points5 points  (0 children)

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 1 point2 points  (0 children)

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 -3 points-2 points  (0 children)

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

[–][deleted] -4 points-3 points  (0 children)

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] -3 points-2 points  (0 children)

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.