5 ms·

> Ruby really needs to put performance on the roadmap as a serious project. http://engineering.appfolio.com/appfolio-engineering/2015/11/18/ruby-3x3 http://eng

> Ruby really needs to put performance on the roadmap as a serious project. http://engineering.appfolio.com/appfolio-engineering/2015/11/18/ruby-3x3 http://engineering.appfolio.com/appfolio-engineering/2015/11... > At RubyConf 2015 in San Antonio, Yukihiro "Matz" Matsumoto announced Ruby 3x3. The goal of Ruby 3x3 is to make Ruby 3 be 3 times faster than Ruby 2.

chrisseaton 10y ago
I'm not sure there are any realistic ideas to actually achieve this for MRI though (beyond the one-sentence bullet points in that article). The roadmap needs to have some roads on it rather than just wilderness! That's speaking as someone who works full time on optimising Ruby, and wrote a PhD on it. I think the one hope is that Evan Phoenix suggested an idea that would let an LLVM JIT optimise through the Ruby implementation, but this is a full-on research project (he said it wasn't, I'm not sure I agree), and nobody is working on it.
- Freaky 10y ago
  OMR might offer some hope too - https://github.com/rubyomr-preview/ruby https://github.com/rubyomr-preview/ruby http://www.slideshare.net/MatthewGaudet/experiments-in-sharing-java-vm-technology-with-cruby http://www.slideshare.net/MatthewGaudet/experiments-in-shari...
- kristianp 10y ago
  How is GraalVM + JRubyTruffle going? It's a fast implementation of ruby. https://github.com/graalvm/jrubytruffle https://github.com/graalvm/jrubytruffle
- MrBra 10y ago
  You should watch the Evan Phoenix talk at RubyKaigi 2015 ("Ruby 2020") https://www.youtube.com/watch?v=QaLvtNpoc5o https://www.youtube.com/watch?v=QaLvtNpoc5o. It proposes a very interesting path for Ruby to get way faster, without resorting to the JRuby implementation. Basically what he's proposing is we could compile all the Ruby Stdlib ahead of time to a LLVM kind of bytecode. Once you do that, a JIT compiler for Ruby code could perform a way deeper optimization, because the compiler horizon-line will be stretched much further away: the compiler will be able to inspect the Stdlib bytecode and make optimizations to your Ruby code taking all that into account! This could be a revolutionary approach for MRI, please go see the talk, it's really interesting!
astrodust 10y ago
Three times faster is a good start, but honestly, if JavaScript had only come 3x faster than it was in its early days nobody would take it seriously for anything.
- MrBra 10y ago
  Except that JS became that faster because Google invested $ millions on making it so.
cutler 10y ago
He also said in a recent podcast that Ruby 3 will likely take 2 to 3 years to complete so don't bet the future on it.
- ksec 10y ago
  But they also mention it is 3x faster then Ruby 2.0! Ruby 2.1 and 2.2 actually bought in lots of performance improvement already.
kristianp 10y ago
Wow, I'm surprised that YARV[1] has no JIT, I thought that might have been part of the reason for the switch to it back in the day (late 2007). [1] https://en.wikipedia.org/wiki/YARV https://en.wikipedia.org/wiki/YARV

chrisseaton 10y ago

I'm not sure there are any realistic ideas to actually achieve this for MRI though (beyond the one-sentence bullet points in that article). The roadmap needs to have some roads on it rather than just wilderness! That's speaking as someone who works full time on optimising Ruby, and wrote a PhD on it. I think the one hope is that Evan Phoenix suggested an idea that would let an LLVM JIT optimise through the Ruby implementation, but this is a full-on research project (he said it wasn't, I'm not sure I agree), and nobody is working on it.

Freaky 10y ago
OMR might offer some hope too - https://github.com/rubyomr-preview/ruby https://github.com/rubyomr-preview/ruby http://www.slideshare.net/MatthewGaudet/experiments-in-sharing-java-vm-technology-with-cruby http://www.slideshare.net/MatthewGaudet/experiments-in-shari...
kristianp 10y ago
How is GraalVM + JRubyTruffle going? It's a fast implementation of ruby. https://github.com/graalvm/jrubytruffle https://github.com/graalvm/jrubytruffle
MrBra 10y ago
You should watch the Evan Phoenix talk at RubyKaigi 2015 ("Ruby 2020") https://www.youtube.com/watch?v=QaLvtNpoc5o https://www.youtube.com/watch?v=QaLvtNpoc5o. It proposes a very interesting path for Ruby to get way faster, without resorting to the JRuby implementation. Basically what he's proposing is we could compile all the Ruby Stdlib ahead of time to a LLVM kind of bytecode. Once you do that, a JIT compiler for Ruby code could perform a way deeper optimization, because the compiler horizon-line will be stretched much further away: the compiler will be able to inspect the Stdlib bytecode and make optimizations to your Ruby code taking all that into account! This could be a revolutionary approach for MRI, please go see the talk, it's really interesting!

astrodust 10y ago

Three times faster is a good start, but honestly, if JavaScript had only come 3x faster than it was in its early days nobody would take it seriously for anything.

MrBra 10y ago
Except that JS became that faster because Google invested $ millions on making it so.

cutler 10y ago

He also said in a recent podcast that Ruby 3 will likely take 2 to 3 years to complete so don't bet the future on it.

ksec 10y ago
But they also mention it is 3x faster then Ruby 2.0! Ruby 2.1 and 2.2 actually bought in lots of performance improvement already.

kristianp 10y ago

Wow, I'm surprised that YARV[1] has no JIT, I thought that might have been part of the reason for the switch to it back in the day (late 2007). [1] https://en.wikipedia.org/wiki/YARV https://en.wikipedia.org/wiki/YARV