5 ms·

Ruby really needs to put performance on the roadmap as a serious project. The work done on Python, on Perl, on JavaScript especially shows that there's huge gai

Ruby really needs to put performance on the roadmap as a serious project. The work done on Python, on Perl, on JavaScript especially shows that there's huge gains that can be made if you prioritize it. Sadly the core Ruby team has been incredibly indifferent and at times outright hostile to projects like JRuby and Rubinius that have tried valiantly to push Ruby forward. I'd rather not see people use JavaScript, Swift, or C# because Ruby wasn't fast enough for their particular problem.

Scarbutt 11y ago
The work done on Python, on Perl, on JavaScript especially shows that there's huge gains that can be made if you prioritize it. What's the work done on Python?
- jerf 11y ago
  PyPy: http://pypy.org/ http://pypy.org/
  - Scarbutt 11y ago
    well since he disregarded jruby, you would have thought pypy was out too.
    - jerf 11y ago
      Well, if you disregard the reimplementations, there's no evidence that there's a lot of speedup to be had, either. The core implementations haven't gotten much faster. So I took at least one sensible interpretation.
  - deleted 11y ago
    [deleted]
- deleted 11y ago
  [deleted]
- mangeletti 11y ago
  If we're not counting PyPy, and we're not counting Cython, and we're not counting the ease of writing CPU-bound code in C or C++[1] while leaving the rest of your application in Python (e.g., like Numpy and other libraries do), then we're left with: Releases like Python 3.6[2], where lots of little optimizations are made, give Python a performance growing edge on Ruby. 1. https://docs.python.org/2/extending/extending.html https://docs.python.org/2/extending/extending.html 2. https://docs.python.org/3.6/whatsnew/3.6.html https://docs.python.org/3.6/whatsnew/3.6.html
  - BuckRogers 11y ago
    There's ease in writing extensions for Ruby in C and C++ as well. Those Python 3.6 enhancements are still going to result in CPython being absolutely crushed by Python 2.7 on PyPy5.
molecule 11y ago
> 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 11y 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 11y 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 11y 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!
outworlder 11y ago
Yes. Rubinius, in particular, should be given more love. I mean, it is one thing to say that Ruby is fast enough for your startup's application supported by lots of memcached instances with a CloudFlare front. It's another thing entirely to have a compiler written in your language, and claiming that that it is fast enough.
- astrodust 11y ago
  I had a lot of hope for Rubinius and that team is all heroes in my book. What a shame that the whole project ran into serious friction due to politics and culture. Their greatest legacy, the incredibly comprehensive Ruby Test suite, seems to be largely ignored by the core team which is a true shame. http://rubinius.com/2014/12/31/matz-s-ruby-developers-don-t-use-rubyspec/ http://rubinius.com/2014/12/31/matz-s-ruby-developers-don-t-...
  - chrisseaton 11y ago
    After Rubinius discontinued it as a standalone project, it was adopted by someone else and now lives in the MRI org on GitHub https://github.com/ruby/spec https://github.com/ruby/spec.
    - astrodust 11y ago
      That's good news!
deleted 11y ago
[deleted]
PeCaN 11y ago
Even Tcl is faster than (or comparable to) Ruby these days.¹ (Incidentally, Tcl definitely doesn't get enough love for having a very high-quality implementation.) When the stringly-typed language is competitive in performance, maybe you should reevaluate a bit.² -- ¹According to entirely unreliable microbenchmarks found via quick web searches. ²Not to knock Tcl. I actually love Tcl. One of the reasons I love Tcl is the ease of extending it in languages with better performance.

Scarbutt 11y ago

The work done on Python, on Perl, on JavaScript especially shows that there's huge gains that can be made if you prioritize it. What's the work done on Python?

jerf 11y ago
PyPy: http://pypy.org/ http://pypy.org/
- Scarbutt 11y ago
  well since he disregarded jruby, you would have thought pypy was out too.
  - jerf 11y ago
    Well, if you disregard the reimplementations, there's no evidence that there's a lot of speedup to be had, either. The core implementations haven't gotten much faster. So I took at least one sensible interpretation.
- deleted 11y ago
  [deleted]
deleted 11y ago
[deleted]
mangeletti 11y ago
If we're not counting PyPy, and we're not counting Cython, and we're not counting the ease of writing CPU-bound code in C or C++[1] while leaving the rest of your application in Python (e.g., like Numpy and other libraries do), then we're left with: Releases like Python 3.6[2], where lots of little optimizations are made, give Python a performance growing edge on Ruby. 1. https://docs.python.org/2/extending/extending.html https://docs.python.org/2/extending/extending.html 2. https://docs.python.org/3.6/whatsnew/3.6.html https://docs.python.org/3.6/whatsnew/3.6.html
- BuckRogers 11y ago
  There's ease in writing extensions for Ruby in C and C++ as well. Those Python 3.6 enhancements are still going to result in CPython being absolutely crushed by Python 2.7 on PyPy5.

molecule 11y ago

> 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 11y 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 11y 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 11y 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!

outworlder 11y ago

Yes. Rubinius, in particular, should be given more love. I mean, it is one thing to say that Ruby is fast enough for your startup's application supported by lots of memcached instances with a CloudFlare front. It's another thing entirely to have a compiler written in your language, and claiming that that it is fast enough.

astrodust 11y ago
I had a lot of hope for Rubinius and that team is all heroes in my book. What a shame that the whole project ran into serious friction due to politics and culture. Their greatest legacy, the incredibly comprehensive Ruby Test suite, seems to be largely ignored by the core team which is a true shame. http://rubinius.com/2014/12/31/matz-s-ruby-developers-don-t-use-rubyspec/ http://rubinius.com/2014/12/31/matz-s-ruby-developers-don-t-...
- chrisseaton 11y ago
  After Rubinius discontinued it as a standalone project, it was adopted by someone else and now lives in the MRI org on GitHub https://github.com/ruby/spec https://github.com/ruby/spec.
  - astrodust 11y ago
    That's good news!

deleted 11y ago

[deleted]

PeCaN 11y ago

Even Tcl is faster than (or comparable to) Ruby these days.¹ (Incidentally, Tcl definitely doesn't get enough love for having a very high-quality implementation.) When the stringly-typed language is competitive in performance, maybe you should reevaluate a bit.² -- ¹According to entirely unreliable microbenchmarks found via quick web searches. ²Not to knock Tcl. I actually love Tcl. One of the reasons I love Tcl is the ease of extending it in languages with better performance.