5 ms·

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

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!

pjungwir 11y ago
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 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 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.
shanemhansen 11y ago
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.
- chinhodado 11y ago
  Why is Java a dynamic language? Isn't Java statically typed?
  - supster 11y ago
    Static vs dynamic is actually kind of a blurry line: https://en.wikipedia.org/wiki/Strong_and_weak_typing https://en.wikipedia.org/wiki/Strong_and_weak_typing
  - alfanick 11y ago
    you can do metaprogramming - invent new methods or class on the run
  - ludamad 11y ago
    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.
  - mike_hearn 11y ago
    The dynamic its of Java are not its type system, they're things like late dynamic linking.
- nly 11y ago
  > 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.
  - Eridrus 11y ago
    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.
kemiller 11y ago
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.
pmarreck 11y ago
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 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.
ch4s3 11y ago
>>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.
lettergram 11y ago
> 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.
- whistlerbrk 11y ago
  This is correct, I would highly highly recommend reading "Deoptimizing Ruby" available here, http://chrisseaton.com/rubytruffle/deoptimizing/ 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.
  - ch4s3 11y ago
    That's a great read even if you aren't a Rubyist, especially the discussion of monkey patching.
reissbaker 11y ago
> 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-sweet-spot.html http://mrale.ph/blog/2011/11/05/the-trap-of-the-performance-... [2] https://www.techempower.com/benchmarks/ https://www.techempower.com/benchmarks/
ksec 11y ago
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.

pjungwir 11y ago

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

shanemhansen 11y ago

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.

chinhodado 11y ago
Why is Java a dynamic language? Isn't Java statically typed?
- supster 11y ago
  Static vs dynamic is actually kind of a blurry line: https://en.wikipedia.org/wiki/Strong_and_weak_typing https://en.wikipedia.org/wiki/Strong_and_weak_typing
- alfanick 11y ago
  you can do metaprogramming - invent new methods or class on the run
- ludamad 11y ago
  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.
- mike_hearn 11y ago
  The dynamic its of Java are not its type system, they're things like late dynamic linking.
nly 11y ago
> 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.
- Eridrus 11y ago
  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.

kemiller 11y ago

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.

pmarreck 11y ago

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

ch4s3 11y ago

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

lettergram 11y ago

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

whistlerbrk 11y ago
This is correct, I would highly highly recommend reading "Deoptimizing Ruby" available here, http://chrisseaton.com/rubytruffle/deoptimizing/ 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.
- ch4s3 11y ago
  That's a great read even if you aren't a Rubyist, especially the discussion of monkey patching.

reissbaker 11y ago

> 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-sweet-spot.html http://mrale.ph/blog/2011/11/05/the-trap-of-the-performance-... [2] https://www.techempower.com/benchmarks/ https://www.techempower.com/benchmarks/

ksec 11y ago

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.