Bytecode cache is experimentally released in Ruby2.3 | Hacker News Reader

Bytecode cache is experimentally released in Ruby2.3

rimuru.lunanet.gr.jp

108 pointsremore19 comments

For those who missed it, a HN user is working full-time on dynamic optimizations in Ruby (just finished his PhD thesis on it) - https://news.ycombinator.com/item?id=10791428 - It's showing significant (10x) speed-ups using real interesting methodologies. He's working on it full-time as the project lead at Oracle now. That thesis is worth a week-end read, it's something I would dedicate 4-6 lectures to if I was a professor.

I believe the link you pointed to is for work specific to JRuby, while the OP is specific to MRI.

This is definitely a nice improvement which can lead to Ruby performance improvements.

It's also worth noting that Ruby 3 in general will have a focus on performance. Matz talked about performance and the Ruby 3x3 effort during his RubyKaigi keynote. The goal of Ruby 3x3 is to make Ruby 3 be 3 times faster than Ruby 2.

Full disclosure: I work for AppFolio which is helping to sponsor the Ruby 3x3 effort.

Do you know if it has been decided where AppFolio is going to direct its generous support yet? Are you hiring anyone?

I think the most realistic option is the idea of putting the LLVM bitcode of MRI's functions into the MRI binary so that an LLVM JIT could optimise through the core library. Evan Phoenix talked about this idea at Ruby Kaigi.

Yes, we are going to hire someone. We now have the position open and are looking for candidates. We already have a couple of folks interested and we'd like to get a few more so that we can find the best fit.

[0] http://www.appfolioinc.com/jobs-openings?p=job%2FoZ1c2fwY (it says Santa Barbara, CA but really anywhere in the US is ok)

When is the last time you hear CPython performance objectives and improvements?

I think the main problem of 2-3 transition is not the incompatibilities, but lack of gain. If Py3k is 20% faster than Py2k it's a strong signal for mass upgrading.

This is actually most of the reason I'm being driven away from Python to Clojure. Sure I can write highly performant Python, but it stops being pythonic.

I'd be so happy if we just gave up on CPython and everyone put their effort into getting PyPy up to 3.5. That's just me though.

Py3 is a lot faster than py2, read the release notes. In general though I think the CPython team prefer a cleaner implementation than a confusing one that's a bit faster. Just use PyPy

Do you have a source for this performance that's not the release notes? In day to day work I don't see much more than a 10% gains.

I like that there seems to be a lot of emphasis on performance for Ruby these days. I know it's a hard subject to optimize for, especially in the case of Ruby, but it's really appreciated.

On the "Ruby Kaigi" presentation (http://www.atdot.net/~ko1/activities/2015_RubyKaigi2015.pdf), Koichi Sasada states that Matz doesn't like the automatic compilation of source files a la Python, which automatically generates .pyc files.

Why is this? I understand the inconvenience of having lots of compiled files in your deployment structure but I guess having a static compile phase would be worse. Any opinions on this?

I think Rubinius used to do it the python way (.rbc files in the same directory) but I think it stopped (not the authority on that so may be wrong).

I think if you could do it transparently as a cache, and out of sight and synchronised properly it would be fine, but writing files everywhere is not ideal. Imagine two users running the same files but with different configurations in the same directory at the same time. It's just a mess waiting to happen.

Don't know if that's Rubinius' or Matz's problem with it though.

Rubinius stores the bytecode either in $PWD/.rbx or $HOME/.rbx depending on which of the two exists. By default $HOME/.rbx is used.

EDIT: I meant the default being $HOME/.rbx, not $PWD/.rbx

Great news! I just hope Ruby community won't be as recalcitrant as the Python community about the 2-to-3 transition ;).

The 1.8 to 1.9 transition was a significant hurdle, and virtually all of the anecdotes I've heard from people who quit Ruby because of its purportedly bad backwards compatibility were about 1.8->1.9. The cause of the difficulty was similar: Unicode.

In any case, Ruby has/had a much different dynamic back then. Most developers using Ruby were doing so because of Rails. When Rails made the move, not switching would have been tech-debt-suicide for any stack depending on Rails or library that was heavily associated with Rails.

I've just recently started using Python...and while there are a few big players who still have SDKs in 2.x...I can't think of any single Python library I've used that has had as much pull as RoR does on Ruby.

We have both in our company. And they stills struggle with Python 2 in many cases because software just never got updated to 3 (but still is somewhat active). While our Ruby team could just upgrade one after the other thing, especially as most gems pretty soon supported 1.9 as well.

It is also worth mentioning that i still need to have Python 2 and 3 installed to properly work on my Linux box. But i havent had needed a Ruby 1.8 since at least 1.5 years now.

there was some talk by matz in which he mentioned that maybe one of the reasons the 1->2 transition in ruby wasn't so bad as python 2->3 was that people got a nice dangling carrot in front of them in the form of performance improvements and "nice" language features, and were motivated to port stuff.

So the plan for 2->3 is to have the same "motivational" changes, like a much faster runtime. We can hope :)

That's my daily work nightmare.

It is actually "Do not parse and compile the files which have been parsed and compiled. Use the cache.".

Can't believe it is done so late.

Reply on news.ycombinator.com