OK folks, help me out here. I'm not trying to troll, this is a genuine question.

In the not-so-distant-past, one of the reasons why a good number of developers/projects announced they were moving away from Ruby and using other languages/compilers was due to Ruby's slow performance—and not just that Ruby was slow, but that Ruby was slow due to the actual nature of the language. In other words, Ruby was destined to always be slow, so it didn't make sense to invest in making Ruby faster because that's, to a certain extent, a fool's errand.

Now we're actually seeing a number of initiatives that are claiming to take Ruby into performance arenas that are an order of magnitude faster than before. And not just the compiler level, but all through the stack: faster app servers, faster libraries, faster frameworks, etc.

So that's all very exciting, and I'm super thrilled as a Ruby developer, but here's my question: if Ruby can actually be a relatively fast language, what was going on before? Were the "Ruby will always be slow" people simply wrong? Or are there some new breakthroughs in compiler design that make it much more feasible for such a dynamic language as Ruby to be more performant? Inquiring minds want to know!

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.

"Sun made java fast. Google made javascript pretty fast."

But there's a lot of daylight between what you call "fast" and "pretty fast". For all the effort that has been poured into Javascript, it remains a slow language for general-purpose programming. That's why asm.js could speed up JS as much as it could; if JS was already "C fast" nobody would have needed or used asm.js. And nobody would talk about Web Assembly if JS was already that fast.

It is definitely true that the bytecode interpreters that pretty much all the dynamic languages started with were not the last words in speed, and things like JITs and such have sped them up a lot. When the dynamic interpreted languages were routinely 50x slower than C, there was room for improvement. But there seems to be a wall at around 10x slower than C for general-purpose programming [1] that the languages are having a hard time penetrating from what I can see: http://benchmarksgame.alioth.debian.org/u64q/which-programs-... (Bizarrely, they've broken out into two graphs, with the slower languages getting graphed first. It's actually one big graph, I think.)

Having heard people say for many, many years that "languages don't have speeds, only implementations do", I no longer believe that. After vast quantities of time and effort have been poured into the dynamic languages, they're still slow. Just not as slow as they used to be, and often with significantly larger memory footprints to get to "not as slow as they used to be".

NB: Pity LuaJIT is no longer on that site. If you design your "dynamic" language for speed, you can do a lot better. But I've not seen proof you can design a language for convenience and dynamicness and then come along 15+ years later and make it C-fast.

[1]: I have to qualify that, because any JIT worth its salt can optimize certain very advantageous code down to C speed. As the benchmark contains some of these tasks, you can see the dynamic languages with decent JITs reach their tails down to near C-speed in that graph. However, being able to optimize code that loops over integers and adds them up to C speed or even beyond if you automatically use SIMD doesn't mean that you're going to C performance in general.

I'd offer one riff further on all that: indeed, core languages do continue to influence speed on a scale that implementation details can only batter at the edges of.

In Ruby's case, ObjectSpace is worth taking a peek at for an example: http://ruby-doc.org/core-2.3.0/ObjectSpace.html We have here a method that counts all objects, by type, in the entire heap. How, exactly, could one propose to parallelize that? Not Easily. Does that leak synchronization needs -- and thus performance implications -- into every layer of GC, scheduling, class/module definition loading, and so on? Yup.

Doesn't matter how much you approach the pinnacle of excellence in JIT. Some definitions of operational parameters are just going to be expensive. Other languages that simply don't allow such operations are at a permanent advantage. There is no such thing as engineering without tradeoffs.

>> Bizarrely, they've broken out into two graphs, with the slower languages getting graphed first. <<

How wide is your phone? :-)

(It's just to confuse people who insist on saying this language is first, this language is second … as though rank order was useful information.)

The bizarre part to me is putting the right hand side of the graph up first. If the left side was first, I wouldn't have commented.

Is there a right hand side and left hand side here? --

http://benchmarksgame.alioth.debian.org/u32/which-programs-a...

> Google made javascript pretty fast.

A small outsourced team in Denmark did, actually. Sure, they were hired by Google, but that kind of belies your argument that only a large corp can do this, no?

For sure, a small team can do the work. The question is: who will pay them to? Your five smart compiler friends could maybe get contract work making specific hotspots a bit faster for some specific medium-sized company.

But who is going to finance them rebuilding the whole approach from scratch over several years, in a way that benefits a whole platform rather than just their company, and shelter the team from short-term priorities and reorgs?

That takes a big company that has an enormous economic stake in the entire platform.

Also, Sun making Java fast was due to Hotspot, which was inspired by work on Self, the successor to Smalltalk.

Why is Java a dynamic language? Isn't Java statically typed?

Dynamically typed languages essentially have something like Java's Object type as the type of everything. Using wide types like that and interfaces in Java, you easily have dynamic traits in your code.

Static vs dynamic is actually kind of a blurry line: https://en.wikipedia.org/wiki/Strong_and_weak_typing

The dynamic its of Java are not its type system, they're things like late dynamic linking.

you can do metaprogramming - invent new methods or class on the run

"Sun made java fast. Google made javascript pretty fast."

And Mike Pall made Lua pretty damn fast.

> Sun made java fast.

Arguably one of the most prevalent Java platforms these days, Android, doesn't JIT... it compiles AoT. Java is actually a great example of languages with static type systems being easier to optimize, whereas the JVM is the new hotness for everything dynamic.

The mobile environment really benefits AoT though; you care about CPU usage more due to battery life and you really care about startup performance because slow starts make your platform seem sluggish.

Java's main usage (outside of Android) atm is on the server-side, and startup time isn't a huge deal there and you care about cost more than actual perf.

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.

> 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/

> 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.

This is correct, I would highly highly recommend reading "Deoptimizing Ruby" available here, http://chrisseaton.com/rubytruffle/deoptimizing/ for more information on WHY making Ruby fast is hard and what the Truffle+Graal does to make it fast.

That's a great read even if you aren't a Rubyist, especially the discussion of monkey patching.

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.

>>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.

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.

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.

Ruby+Truffle+Graal support was removed from rbenv (ruby-build, actually) on Jan. 1st.

Apparently, "the new builds are click-through licensed" and will be based off "Oracle's JDK rather than Open JDK."

I can't wait for Oracle to die.

commit: https://github.com/rbenv/ruby-build/commit/ca0e1474fcf3e2025...

pull request: https://github.com/rbenv/ruby-build/pull/864

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 :(

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.

OMR is really cool, I spun up the docker image and my project ran on it out of the box. That said, JRuby has been great for us, and we're really excited about Truffle+Graal (which won't run Rails yet but seems close). Chris Seaton is super smart and a really nice guy. Apparently Truffle+Graal should be able to run R soon https://twitter.com/ChrisGSeaton/status/697515513858158592

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.

You're welcome. I love the project, and I'll be watching github closely as you move towards open source. I'll try to run some gems I like that use c extensions soon.

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.

In some cases they could perhaps do the same thing that's done with Ruby: interpret the C-extensions.

It's not as crazy as it may seem and JRuby benefits hugely from it: http://chrisseaton.com/rubytruffle/cext/

I'm pretty sure they aim to interpret the c, but I don't want to speak for Chris.

They don't just interpret the C, they JIT compile it.

some discussion: https://www.reddit.com/r/ruby/comments/42xxsp/flammarion_the...

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

Oops sorry you are right, I was supposed to post that inside the Flammarion post that I made just before this one at https://news.ycombinator.com/item?id=11064890, got a bit confused :)

wow, 11 sec to run hello world: ``` ~$ time ruby -X+T -e 'puts Truffle.graal?'

real 0m3.843s user 0m11.867s ```

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.

The JVM startup time is very small nowadays (seriously, write a Hello World! class in Java to test it if you don't believe me). The culprit is probably JRuby's startup time (and maybe the Truffle + Graal version of JRuby is even slower to startup than regular JRuby).

Yeah, I'm oversimplifying. However, compared to MRI, the JVM starts up quite slowly. Pile on JRuby et al and you end up with an even slower time to go. I think the JRuby people have been very focused on feature parity, interop, and bug fixes so I'm not sure they've prioritized startup time. For now, I'm happy with that, I don't restart my app that often, basically only on deploys.

Startup is slow right now, but there is a project underway at Oracle Labs which will reduce it to a similar level as MRI.

JVM hello world can be about 50 milliseconds. The issue is the Graal/JRuby overhead. Bear in mind that Graal is a JIT compiler that is itself written in Java. So it has to compile itself before it gets fast at compiling anything else!

There is an AOT mode being worked on that should solve that, but it's not open source.