7 ms·

Projects That Are Making Fast Ruby a Reality

119 points by MrBra 11y ago

mbreedlove 11y ago
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/ca0e1474fcf3e20257c291fb0dbe0e11ac549624 https://github.com/rbenv/ruby-build/commit/ca0e1474fcf3e2025... pull request: https://github.com/rbenv/ruby-build/pull/864 https://github.com/rbenv/ruby-build/pull/864
- ksec 11y ago
  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.
- mike_hearn 11y ago
  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 :(
MrBra 11y ago
some discussion: https://www.reddit.com/r/ruby/comments/42xxsp/flammarion_the_nifty_ruby_gui_toolkit/ https://www.reddit.com/r/ruby/comments/42xxsp/flammarion_the...
- VeejayRampay 11y ago
  While the Reddit discussion you linked to is interesting, I'm not sure how relevant it is to the article.
  - MrBra 11y ago
    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 https://news.ycombinator.com/item?id=11064890, got a bit confused :)
ch4s3 11y ago
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 https://twitter.com/ChrisGSeaton/status/697515513858158592
- nextos 11y ago
  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.
  - eonwe 11y ago
    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/ http://chrisseaton.com/rubytruffle/cext/
    - ch4s3 11y ago
      I'm pretty sure they aim to interpret the c, but I don't want to speak for Chris.
      - mike_hearn 11y ago
        They don't just interpret the C, they JIT compile it.
- magaudet 11y ago
  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.
jaredcwhite 11y ago
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.
singularity2001 11y ago
wow, 11 sec to run hello world: ``` ~$ time ruby -X+T -e 'puts Truffle.graal?' real 0m3.843s user 0m11.867s ```
- craigmcnamara 11y ago
  JRuby has never been fast to boot, but after boot it's very fast to execute.
- ch4s3 11y ago
  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.
  - omaranto 11y ago
    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).
    - ch4s3 11y ago
      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.
    - jordanthoms 11y ago
      Startup is slow right now, but there is a project underway at Oracle Labs which will reduce it to a similar level as MRI.
  - mike_hearn 11y ago
    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.
singularity2001 11y ago
wow, 11 sec to run hello world: time ruby -X+T -e 'puts Truffle.graal?' real 0m3.843s user 0m11.867s

119 points by MrBra 11y ago

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/ca0e1474fcf3e20257c291fb0dbe0e11ac549624 https://github.com/rbenv/ruby-build/commit/ca0e1474fcf3e2025... pull request: https://github.com/rbenv/ruby-build/pull/864 https://github.com/rbenv/ruby-build/pull/864

ksec 11y ago
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.
mike_hearn 11y ago
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 :(

MrBra 11y ago

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

VeejayRampay 11y ago
While the Reddit discussion you linked to is interesting, I'm not sure how relevant it is to the article.
- MrBra 11y ago
  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 https://news.ycombinator.com/item?id=11064890, got a bit confused :)

ch4s3 11y ago

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 https://twitter.com/ChrisGSeaton/status/697515513858158592

nextos 11y ago
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.
- eonwe 11y ago
  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/ http://chrisseaton.com/rubytruffle/cext/
  - ch4s3 11y ago
    I'm pretty sure they aim to interpret the c, but I don't want to speak for Chris.
    - mike_hearn 11y ago
      They don't just interpret the C, they JIT compile it.
magaudet 11y ago
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.

jaredcwhite 11y ago

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.

singularity2001 11y ago

wow, 11 sec to run hello world: ``` ~$ time ruby -X+T -e 'puts Truffle.graal?' real 0m3.843s user 0m11.867s ```

craigmcnamara 11y ago
JRuby has never been fast to boot, but after boot it's very fast to execute.
ch4s3 11y ago
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.
- omaranto 11y ago
  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).
  - ch4s3 11y ago
    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.
  - jordanthoms 11y ago
    Startup is slow right now, but there is a project underway at Oracle Labs which will reduce it to a similar level as MRI.
- mike_hearn 11y ago
  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.

singularity2001 11y ago

wow, 11 sec to run hello world: time ruby -X+T -e 'puts Truffle.graal?' real 0m3.843s user 0m11.867s