Projects That Are Making Fast Ruby a Reality

I remember this blog post about how optimizing method calls becomes much harder with refinements (from MRI Ruby 2.1):

http://blog.headius.com/2012/11/refining-ruby.html

It looks like JRuby has refinements now but maybe not great support for them (based on just some quick Googling):

https://github.com/jruby/jruby/issues/1062

So I'm curious if anything tested in the article has refinements support.

Personally I'm still skeptical of refinements, but I guess JRuby will have to support them or more and more gems will start to break.

I think the short answer is making a dynamic language really fast is really hard. You can do it, but historically you've needed to be Sun or Google to pull it off. Sun made java fast. Google made javascript pretty fast.

So ruby either needed to piggy back on someone else's work (jvm or whatever) or get some next-level-smart vm developers. Even then, people have written about how ruby presents some serious challenges.

I am still pretty skeptical. We've had very promising implementations of 80-90% of the language, which faltered once they got to the less tractable parts of the language. Not saying it can't be done, but definitely saying I'll believe it when I see it live on a few legacy production sites.

When you work on any medium-to-large Rails project, and you want to run a quick unit test to test some new functionality for your new class that inherits from, say, something in ActiveSupport, and AS pulls in a bunch of gem code that is opaque to you, and your class names a module that wasn't loaded yet and so it gets dynamically loaded (warning: global mutable state has been altered, causing weird load-order bugs), and then THAT module triggers other loads of things it depends on, and one of those monkeypatches a bug in an old version of some gem which has actually since been fixed but is still being monkeypatched with old code and causes a corner-case bug that you haven't discovered yet (shameless self-plug: I actually wrote a gem to help manage that stuff: https://github.com/pmarreck/pachinko), and your unit test ends up taking, like, 30 seconds to just load your stack of dependencies... (I've actually seen 40 sec stack loads, in the wild, at past jobs)

... Ruby is still slow.

Sure, there are band-aids to assist with that stuff (Guard, Zeus, etc.), but you're still dealing with spaghetti-dependency, mutating-global-state, side-effecting hell.

Which is exactly why I now want to work with Elixir and Phoenix instead.

Note: It IS possible to write Ruby in such a way that almost none of this stuff actually comes to pass. But even if you do, you'll have to deal with an entire library of code that does not.

>>Were the "Ruby will always be slow" people simply wrong? Well, yes. It was slow in the same way that python was slow. If you move all of the slow stuff to C or JIT it or whatever, it can be as fast as almost any language can be, with a few minor caveats.

MAth is tricky in pure Ruby for example, the spec does a check on integers to make sure they can ben contained in what we'll call Int, and don't need to be transformed into BigInt. Ruby does this check every time an integer changes, which is wildly expensive, but super convenient. Its really nice for small N, but you shouldn't add n-dimensional arrays this way.

Also, run time meta-programming is pretty slow, especially if you lean on #method_missing, that's hard to fix.

Those two things aside, there aren't any reasons that Ruby can't be made much faster, in fact for many use cases JRuby is presently very fast and with Java interop you can leverage Java libs.

> Were the "Ruby will always be slow" people simply wrong?

Simple answer, yes. Not saying that Ruby is fast now, however Ruby doesn't necessarily always have to be slow. Just like any languages/framework/etc. It can be made faster, although the amount of work to get there may be substantial.

At the time ruby was really slow, and with no real progress and a waning number of groups working to improve it. Now, it appears people are making progress and working on it.

> if Ruby can actually be a relatively fast language...

I think that "if" still is a pretty big if. If Truffle/Graal ships and is able to run Rails at a 30x perf improvement, that would be huge. Right now there's still some work left there, and the original article notes that they haven't been able to replicate the claimed perf gains. What's also tricky is that while there can often be "performance sweet spots" [1] in dynamic languages, it's very easy to accidentally fall out of them and make most of your app slow even if theoretically it's possible for it to run faster.

The TechEmpower benchmarks [2] are pretty damning when it comes to Ruby's current performance relative to other languages. For some projects, eventually it's easier to switch to a different language that's already fast rather than investing into speeding up a slow one.

[1] http://mrale.ph/blog/2011/11/05/the-trap-of-the-performance-... [2] https://www.techempower.com/benchmarks/

Ruby is slow, but enough for many things. Rails is slow, dog slow. And no one in Rails team care much.

While it is slightly unfair, most within the Ruby on Rails Community do not care about speed at all.

PHP has Facebook, Java has Sun and other Enterprise, JS has Google V8, as well as Mozilla / Apple providing competition, Lua has Mike Pall. Basically all these Dynamic Langauges has had million of dollars / man hours working on it for a long time.

In Ruby? If it wasn't for ko1 YARV Ruby is still very slow here.

So why all of a sudden we have two solution here that offer a magnitude of speed increase? My guess is that it created an interest within the Academic, VM Research Community, if they have to prove their VM ( OMR / Graal ) to work, they will have to choose one of the hardest, yet to optimized language to work on. I guess that is why both effort happens to be on Ruby.

You can still get the build with OpenJDK yourself i think, the reason they use Oracle JDK is that no body has access to it, bu having a build with Oracle JDK helps with this issue.

That's ridiculous. Firstly, all the Graal/Truffle/Ruby work is open source. The fact that they prefer not to maintain lots of different builds and their build infrastructure produces a mixed open/proprietary binary doesn't change the fact that you can get all the work for free.

Secondly, Oracle funded all of this work! Don't you think that's a little ungrateful? How relevant do you think faster Ruby even is to Oracle's core business? Less relevant than fast JS is to Google certainly, and yet, not only have they been funding a large cutting-edge research effort for years ... they gave the results away as open source too.

Sometimes I think people have lost perspective. I remember programming for Windows in the 1990s, when you were expected to pay for even basic things like treeview widgets or networking libraries. Now you get full blown JIT compilers for dynamic languages for nothing and people complain :(

Thanks, very interesting. I didn't know about this being able to run R inside JVM. What will happen with all existing packages that have C or C++ dependencies? Perhaps it would be doable with a bridge? Having R tightly embedded in the JVM would be amazing.

OMR Team member here: Glad to hear you had a good experience with our tech preview! We really appreciated the feedback you provided, and would definitely be willing to take more.

While the Reddit discussion you linked to is interesting, I'm not sure how relevant it is to the article.

JRuby has never been fast to boot, but after boot it's very fast to execute.

That is the JVM startup time. If you allow the vm to warm up and and JIT to kick in, you'll see significant gains.