4 ms·

Bytecode cache is experimentally released in Ruby2.3

108 points by remore 11y ago

pkmiec 11y ago
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.
- chrisseaton 11y ago
  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.
  - pkmiec 11y ago
    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 http://www.appfolioinc.com/jobs-openings?p=job%2FoZ1c2fwY (it says Santa Barbara, CA but really anywhere in the US is ok)
woodruffw 11y ago
Great news! I just hope Ruby community won't be as recalcitrant as the Python community about the 2-to-3 transition ;).
- imbellish 11y ago
  That's my daily work nightmare.
- riffraff 11y ago
  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 :)
- danso 11y ago
  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.
  - herbst 11y ago
    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.
iheartmemcache 11y ago
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 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.
- cookrn 11y ago
  I believe the link you pointed to is for work specific to JRuby, while the OP is specific to MRI.
est 11y ago
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.
- orf 11y ago
  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
  - poooogles 11y ago
    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.
- poooogles 11y ago
  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.
VeejayRampay 11y ago
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.
pantulis 11y ago
On the "Ruby Kaigi" presentation (http://www.atdot.net/~ko1/activities/2015_RubyKaigi2015.pdf 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?
- chrisseaton 11y ago
  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.
  - YorickPeterse 11y ago
    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
vinceyuan 11y ago
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.

108 points by remore 11y ago

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.

chrisseaton 11y ago
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.
- pkmiec 11y ago
  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 http://www.appfolioinc.com/jobs-openings?p=job%2FoZ1c2fwY (it says Santa Barbara, CA but really anywhere in the US is ok)

woodruffw 11y ago

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

imbellish 11y ago
That's my daily work nightmare.
riffraff 11y ago
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 :)
danso 11y ago
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.
- herbst 11y ago
  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.

iheartmemcache 11y ago

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

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

est 11y ago

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.

orf 11y ago
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
- poooogles 11y ago
  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.
poooogles 11y ago
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.

VeejayRampay 11y ago

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.

pantulis 11y ago

On the "Ruby Kaigi" presentation (http://www.atdot.net/~ko1/activities/2015_RubyKaigi2015.pdf 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?

chrisseaton 11y ago
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.
- YorickPeterse 11y ago
  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

vinceyuan 11y ago

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.