7 ms·

> We’re going to implement method iniling in JIT compiler, which is expected to increase Ruby’s performance in order of magnitude An order of magnitude as in .

by sho 8y ago

> We’re going to implement method iniling in JIT compiler, which is expected to increase Ruby’s performance in order of magnitude An order of magnitude as in .. 10x? This seems too good to be true. Half the arguments against Rails melt away like butter if that's truly the case. Anyone with a better understanding of the details care to comment on the likelihood of these performance gains being actually realised, and if not, what we might realistically expect?

sudhirj 8y ago
For hot code, probably, not the entire language in general. If you're looping through a million numbers doing the same calculation, or maybe rendering markdown in a loop an a lot of text, might hit 10X - the JIT will essentially write the code in C for you, then compile it and run it instead of Ruby.
- jashmatthews 8y ago
  Another factor is a lot of the hot code, like JSON serialization, DB clients, HTTP parsing, is all already in native C extensions. Performance there is only going to improve a little, although some can be better off as pure Ruby + JIT.
- himom 8y ago
  Rubinius uses LLVM IR for this. The only problem is rbx is still very slow on startup and interactive use. Ruby (MRI) will have to reinvent the wheel in order to get a panoply of optimizations that some very smart people have already baked in: like the ability to target almost any platform from the same library.. GCC requires cross-compiling per target.
  - jashmatthews 8y ago
    Didn't Rubinius deprecate their JIT due to a torrent of issues and bugs and have not yet replaced it? Or am I out of date?
    - chrisseaton 8y ago
      Yes Rubinius hasn't had a JIT for years.
jashmatthews 8y ago
Sinatra + Sequel is already very competitive in web performance with Go + Gin[1]. It's the Rails convenience stuff which slows things down massively. MJIT could probably bring Rails in line with Sinatra though. Between Ruby 1.8 and 2.5, performance has improved around 13x in tight loops[2]. The Rails performance issue has been massively overblown since 1.9 was released. Ruby 1.8 was a tree walking interpreter, so the move to a bytecode VM in 1.9 was a huge leap in performance. Twitter bailed to the JVM before moving to 1.9. A lot of those 10-100x performance differences to the JVM are gone thanks to the bytecode VM and generational GC. Bytecode VMs all have the same fundamental problem of instruction dispatch overhead, they're basically executing different C functions depending on input. Doing _anything_ to reduce this improves performance dramatically, even just spitting out the instruction source code into a giant C function, compiling it, and calling that in place of the original method. Another 10x improvement on tight loops should not be a problem. [1] https://www.techempower.com/benchmarks/#section=data-r15&hw=ph&test=fortune&l=hr9kov&f=zik073-zik0zj-zik0zj-zijzen-zik0zj-zijunz-zik0zj-cn3 https://www.techempower.com/benchmarks/#section=data-r15&hw=... [2] https://github.com/mame/optcarrot/blob/master/doc/benchmark.md https://github.com/mame/optcarrot/blob/master/doc/benchmark....
- sho 8y ago
  Thanks for the informative response (and sudhirj too)! Haven't looked at that benchmark for a while - very interesting. Sinatra is absolutely killing it. I knew it was faster than Rails but not that much faster. With 2.6 and sorbet [1] coming down the line, it's exciting to be a Rubyist again! [1] https://sorbet.run/ https://sorbet.run/
- meesterdude 8y ago
  I would have never thought a ruby stack would come anywhere close to Go performance. The path to optimization used to mean abstracting the really crazy parts into a Go microservice for things that just needed absurd responsivity; but it's clear now that a slim ruby stack could also be very effective - and without needing to learn a new language. Worthwhile to at least explore before going Go. Nor did i know that twitter jumped out of rails before ruby got performant. Which means the argument that twitter outgrew rails isn't so correct anymore. still, thanks for this insightful comment.
holstvoogd 8y ago
Just spun up my ridiculously heavy rails app and did a quick test with one of the more cpu-intensive actions and see no evidence of any improvement at all. If anything, it was a bit less predictable. This little test was nowhere near an actual benchmark, but I wouldn't hold my breath. Test suite still passes on it though, so upgrading shouldn't be a huge deal at least へ‿(ツ)‿ㄏ

by sho 8y ago

sudhirj 8y ago

For hot code, probably, not the entire language in general. If you're looping through a million numbers doing the same calculation, or maybe rendering markdown in a loop an a lot of text, might hit 10X - the JIT will essentially write the code in C for you, then compile it and run it instead of Ruby.

jashmatthews 8y ago
Another factor is a lot of the hot code, like JSON serialization, DB clients, HTTP parsing, is all already in native C extensions. Performance there is only going to improve a little, although some can be better off as pure Ruby + JIT.
himom 8y ago
Rubinius uses LLVM IR for this. The only problem is rbx is still very slow on startup and interactive use. Ruby (MRI) will have to reinvent the wheel in order to get a panoply of optimizations that some very smart people have already baked in: like the ability to target almost any platform from the same library.. GCC requires cross-compiling per target.
- jashmatthews 8y ago
  Didn't Rubinius deprecate their JIT due to a torrent of issues and bugs and have not yet replaced it? Or am I out of date?
  - chrisseaton 8y ago
    Yes Rubinius hasn't had a JIT for years.

jashmatthews 8y ago

Sinatra + Sequel is already very competitive in web performance with Go + Gin[1]. It's the Rails convenience stuff which slows things down massively. MJIT could probably bring Rails in line with Sinatra though. Between Ruby 1.8 and 2.5, performance has improved around 13x in tight loops[2]. The Rails performance issue has been massively overblown since 1.9 was released. Ruby 1.8 was a tree walking interpreter, so the move to a bytecode VM in 1.9 was a huge leap in performance. Twitter bailed to the JVM before moving to 1.9. A lot of those 10-100x performance differences to the JVM are gone thanks to the bytecode VM and generational GC. Bytecode VMs all have the same fundamental problem of instruction dispatch overhead, they're basically executing different C functions depending on input. Doing _anything_ to reduce this improves performance dramatically, even just spitting out the instruction source code into a giant C function, compiling it, and calling that in place of the original method. Another 10x improvement on tight loops should not be a problem. [1] https://www.techempower.com/benchmarks/#section=data-r15&hw=ph&test=fortune&l=hr9kov&f=zik073-zik0zj-zik0zj-zijzen-zik0zj-zijunz-zik0zj-cn3 https://www.techempower.com/benchmarks/#section=data-r15&hw=... [2] https://github.com/mame/optcarrot/blob/master/doc/benchmark.md https://github.com/mame/optcarrot/blob/master/doc/benchmark....

sho 8y ago
Thanks for the informative response (and sudhirj too)! Haven't looked at that benchmark for a while - very interesting. Sinatra is absolutely killing it. I knew it was faster than Rails but not that much faster. With 2.6 and sorbet [1] coming down the line, it's exciting to be a Rubyist again! [1] https://sorbet.run/ https://sorbet.run/
meesterdude 8y ago
I would have never thought a ruby stack would come anywhere close to Go performance. The path to optimization used to mean abstracting the really crazy parts into a Go microservice for things that just needed absurd responsivity; but it's clear now that a slim ruby stack could also be very effective - and without needing to learn a new language. Worthwhile to at least explore before going Go. Nor did i know that twitter jumped out of rails before ruby got performant. Which means the argument that twitter outgrew rails isn't so correct anymore. still, thanks for this insightful comment.

holstvoogd 8y ago

Just spun up my ridiculously heavy rails app and did a quick test with one of the more cpu-intensive actions and see no evidence of any improvement at all. If anything, it was a bit less predictable. This little test was nowhere near an actual benchmark, but I wouldn't hold my breath. Test suite still passes on it though, so upgrading shouldn't be a huge deal at least へ‿(ツ)‿ㄏ