Hacker News Reader

Comment by astrodust | Hacker News Reader

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.

View on HN

> Ruby really needs to put performance on the roadmap as a serious project.

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.

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.

You should watch the Evan Phoenix talk at RubyKaigi 2015 ("Ruby 2020") 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!

OMR might offer some hope too - https://github.com/rubyomr-preview/ruby

http://www.slideshare.net/MatthewGaudet/experiments-in-shari...

How is GraalVM + JRubyTruffle going? It's a fast implementation of ruby.

https://github.com/graalvm/jrubytruffle

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.

Except that JS became that faster because Google invested $ millions on making it so.

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

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.

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.

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.

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

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.

That's good news!

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?

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

2. https://docs.python.org/3.6/whatsnew/3.6.html

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.

PyPy: http://pypy.org/

well since he disregarded jruby, you would have thought pypy was out too.

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.

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.

Reply on news.ycombinator.com