13 ms·

Ruby 3 JIT can make Rails faster

123 points by rguiscard 5y ago

ksec 5y ago
So we now have Ruby MJIT, from CRuby and k0kubun, "MJIT" was originally implemented by Vladimir Makarov. MIR, coming from Vladimir Makarov ( RedHat ) again. YJIT coming from Shopify, Dr Maxime Chevalier-Boisvert is leading the team and Dr Stefan Marr ( I think ) will be joining them soon. TruffleRuby, with Dr Chris Seaton now also working in Shopify. JRuby, Charles Nutter ( RedHat ).
- an_opabinia 5y ago
  Will TruffleRuby win? GraalJS is typically 38x slower than Node. Maybe everyone should be porting to V8.
  - lf-non 5y ago
    This is surprising. Last I checked performance was better than node. Are you taking into account JVM warmup time ? Also does the JVM have adequate memory (thinking of GC thrashing)?
    - vips7L 5y ago
      The readme of TruffleRuby even states that large ruby applications take a large time to warmup and they're working on it.
    - an_opabinia 5y ago
      > Last I checked performance was better than node. I don't know if there's any real world node application that is faster on GraalJS, no matter how much "warming up." It is incredibly slow. I understand there's marketing copy out there saying stuff to the contrary, but really, if it was that great, people would be using it. Which I'm confident people don't, because real world applications use tons of the node API that Graal doesn't support, like `setTimeout`.
      - kaba0 5y ago
        Looking at the issues of GraalJS, it seems to me rather that it is a few nodejs devs who doesn’t seem to know what is a worthwhile benchmark, sometimes laughably so. It is well within the same performance range, faster at some tasks, slower at others.
- tekknolagi 5y ago
  From https://blogs.kent.ac.uk/unikentcomp-news/2021/04/16/stefan-marr-receives-royal-society-industry-fellowship-for-collaboration-with-shopify/ https://blogs.kent.ac.uk/unikentcomp-news/2021/04/16/stefan-... it looks like he will be working on GraalRuby/TruffleRuby
open-source-ux 5y ago
I'm very much in favour of seeing performance as a key part of the development of any dynamic, interpreted language. (I single out dynamic languages because in most typed, compiled languages, fast execution speed comes for free.) However, David Heinemeier Hansson, co-founder of Basecamp and creator or Ruby-on-Rails, has this interesting take on the cost of running Ruby for their business. Make of it what you will: Only 15% of the Basecamp operations budget is spent on Ruby (2019) https://m.signalvnoise.com/only-15-of-the-basecamp-operations-budget-is-spent-on-ruby/ https://m.signalvnoise.com/only-15-of-the-basecamp-operation...
- multiplegeorges 5y ago
  While I agree that the cost of "Ruby" gets dwarfed when running a larger business that uses it, I think it's really important to the larger ecosystem around Ruby that this low-level research/work happens. It's also really great to see large companies like Shopify invest in such low-level things, and not just on gems/changes that directly touch their business.
- davidw 5y ago
  Sure, that's a really important point, but if you get it mostly 'for free', you can - at the margin - expand the kinds of businesses where Ruby makes sense.
- riffraff 5y ago
  I mostly agree with the argument, but it's worth noting that a faster runtime may itself results in cutting the other 85% of costs, i.e. you don't need to complicate your architecture to deal with performance issues, nor hire more ops people to manage more servers etc..
  - dwohnitmok 5y ago
    Yeah, that DHH article has one sentence doing a lot of work: "Whether we run on Python, PHP, Rust, Go, C++, or whatever, we’d still need databases, we’d still need search, we’d still need to store files." It's not clear that's true (as in yes you'd probably still need all of those things at a high level, but would you need as much of them and would you need them out of process on another machine?). If magically your programming language gave you enough performance that a single binary + SQLite served all your needs and stuff like caches, message buses, and the like were completely unnecessary that'd radically change your ops budget. Of course that is truly magical, but then again there are quite a lot of papers that demonstrate well-crafted single binary services outperforming heterogenous complex clusters with orders of magnitude more compute resources.
mchusma 5y ago
This is great to hear. It seems like in 3.1 JIT will make probably sense for rails apps. Every little performance improvement helps!
sosodev 5y ago
JIT doesn’t seem like the big optimization that Rails needs. Rails has low throughput because you have to run multiple full-fat instances of rails to handle requests in parallel or multiple beefy threads to handle requests concurrently. Either way you’re spending a huge amount of ram to add a small amount of throughput. JIT only adds a marginal improvement to this current setup. A true async backend like Falcon adds a huge amount of concurrent throughput if tuned correctly and ractors could provide a big parallelism boost if they shared more memory.
- StreamBright 5y ago
  I think in the context of high performance it is pointless to talk about Rails. Even the memory requirements make it impossible scale above a certain (very low) threshold. In the context of developer productivity it is also pointless to talk about high performance because people sacrifice performance for developer happiness. Once you understand that you have these two dimensions most frameworks are revolving around it is getting much clearer which one to pick for a certain use case.
  - aledalgrande 5y ago
    This is legend. Rails can be and is used in high throughtput scenarios, people who say it can't scale all think they are working at Twitter while they just wrote inefficient code. It is true that spending time optimizing queries will give you more benefits than JIT though. CPU is not the bottleneck for most Web tasks.
    - StreamBright 5y ago
      Sorry I used to work for Amazon and we did not allow Rails to be exposed to external customers for performance reasons. I think what you classify as high performance is very different what I classify as high performance. Btw. I haven't seen Rails or Ruby on this list in the top 50% for a while: https://www.techempower.com/benchmarks/ https://www.techempower.com/benchmarks/ I would prefer hard data as opposed to "this is a legend". UPDATE: Rails is number 399 out of 439, having 0.3% performance of the top frameworks in a plain text task. I know, facts hurt.
multiplegeorges 5y ago
It's great to see such low-level efforts happening in the Ruby community and sponsored by some of the large companies using Ruby.
hit8run 5y ago
Thanks at k0kubun and all the others investing their time to Ruby optimization. When performance is a metric one needs to care about Ruby is a bad choice and will stay a bad choice. I find C# with dotnet a very good framework that has amazing performance characteristics and also good developer tooling. I coded many things with Ruby and Rails privately and as my daily job but nowadays it is mostly C# for webdev.
The_rationalist 5y ago
No mention of TruffleRuby?

123 points by rguiscard 5y ago

ksec 5y ago

So we now have Ruby MJIT, from CRuby and k0kubun, "MJIT" was originally implemented by Vladimir Makarov. MIR, coming from Vladimir Makarov ( RedHat ) again. YJIT coming from Shopify, Dr Maxime Chevalier-Boisvert is leading the team and Dr Stefan Marr ( I think ) will be joining them soon. TruffleRuby, with Dr Chris Seaton now also working in Shopify. JRuby, Charles Nutter ( RedHat ).

an_opabinia 5y ago
Will TruffleRuby win? GraalJS is typically 38x slower than Node. Maybe everyone should be porting to V8.
- lf-non 5y ago
  This is surprising. Last I checked performance was better than node. Are you taking into account JVM warmup time ? Also does the JVM have adequate memory (thinking of GC thrashing)?
  - vips7L 5y ago
    The readme of TruffleRuby even states that large ruby applications take a large time to warmup and they're working on it.
  - an_opabinia 5y ago
    > Last I checked performance was better than node. I don't know if there's any real world node application that is faster on GraalJS, no matter how much "warming up." It is incredibly slow. I understand there's marketing copy out there saying stuff to the contrary, but really, if it was that great, people would be using it. Which I'm confident people don't, because real world applications use tons of the node API that Graal doesn't support, like `setTimeout`.
    - kaba0 5y ago
      Looking at the issues of GraalJS, it seems to me rather that it is a few nodejs devs who doesn’t seem to know what is a worthwhile benchmark, sometimes laughably so. It is well within the same performance range, faster at some tasks, slower at others.
tekknolagi 5y ago
From https://blogs.kent.ac.uk/unikentcomp-news/2021/04/16/stefan-marr-receives-royal-society-industry-fellowship-for-collaboration-with-shopify/ https://blogs.kent.ac.uk/unikentcomp-news/2021/04/16/stefan-... it looks like he will be working on GraalRuby/TruffleRuby

open-source-ux 5y ago

I'm very much in favour of seeing performance as a key part of the development of any dynamic, interpreted language. (I single out dynamic languages because in most typed, compiled languages, fast execution speed comes for free.) However, David Heinemeier Hansson, co-founder of Basecamp and creator or Ruby-on-Rails, has this interesting take on the cost of running Ruby for their business. Make of it what you will: Only 15% of the Basecamp operations budget is spent on Ruby (2019) https://m.signalvnoise.com/only-15-of-the-basecamp-operations-budget-is-spent-on-ruby/ https://m.signalvnoise.com/only-15-of-the-basecamp-operation...

multiplegeorges 5y ago
While I agree that the cost of "Ruby" gets dwarfed when running a larger business that uses it, I think it's really important to the larger ecosystem around Ruby that this low-level research/work happens. It's also really great to see large companies like Shopify invest in such low-level things, and not just on gems/changes that directly touch their business.
davidw 5y ago
Sure, that's a really important point, but if you get it mostly 'for free', you can - at the margin - expand the kinds of businesses where Ruby makes sense.
riffraff 5y ago
I mostly agree with the argument, but it's worth noting that a faster runtime may itself results in cutting the other 85% of costs, i.e. you don't need to complicate your architecture to deal with performance issues, nor hire more ops people to manage more servers etc..
- dwohnitmok 5y ago
  Yeah, that DHH article has one sentence doing a lot of work: "Whether we run on Python, PHP, Rust, Go, C++, or whatever, we’d still need databases, we’d still need search, we’d still need to store files." It's not clear that's true (as in yes you'd probably still need all of those things at a high level, but would you need as much of them and would you need them out of process on another machine?). If magically your programming language gave you enough performance that a single binary + SQLite served all your needs and stuff like caches, message buses, and the like were completely unnecessary that'd radically change your ops budget. Of course that is truly magical, but then again there are quite a lot of papers that demonstrate well-crafted single binary services outperforming heterogenous complex clusters with orders of magnitude more compute resources.

mchusma 5y ago

This is great to hear. It seems like in 3.1 JIT will make probably sense for rails apps. Every little performance improvement helps!

sosodev 5y ago

JIT doesn’t seem like the big optimization that Rails needs. Rails has low throughput because you have to run multiple full-fat instances of rails to handle requests in parallel or multiple beefy threads to handle requests concurrently. Either way you’re spending a huge amount of ram to add a small amount of throughput. JIT only adds a marginal improvement to this current setup. A true async backend like Falcon adds a huge amount of concurrent throughput if tuned correctly and ractors could provide a big parallelism boost if they shared more memory.

StreamBright 5y ago
I think in the context of high performance it is pointless to talk about Rails. Even the memory requirements make it impossible scale above a certain (very low) threshold. In the context of developer productivity it is also pointless to talk about high performance because people sacrifice performance for developer happiness. Once you understand that you have these two dimensions most frameworks are revolving around it is getting much clearer which one to pick for a certain use case.
- aledalgrande 5y ago
  This is legend. Rails can be and is used in high throughtput scenarios, people who say it can't scale all think they are working at Twitter while they just wrote inefficient code. It is true that spending time optimizing queries will give you more benefits than JIT though. CPU is not the bottleneck for most Web tasks.
  - StreamBright 5y ago
    Sorry I used to work for Amazon and we did not allow Rails to be exposed to external customers for performance reasons. I think what you classify as high performance is very different what I classify as high performance. Btw. I haven't seen Rails or Ruby on this list in the top 50% for a while: https://www.techempower.com/benchmarks/ https://www.techempower.com/benchmarks/ I would prefer hard data as opposed to "this is a legend". UPDATE: Rails is number 399 out of 439, having 0.3% performance of the top frameworks in a plain text task. I know, facts hurt.

multiplegeorges 5y ago

It's great to see such low-level efforts happening in the Ruby community and sponsored by some of the large companies using Ruby.

hit8run 5y ago

Thanks at k0kubun and all the others investing their time to Ruby optimization. When performance is a metric one needs to care about Ruby is a bad choice and will stay a bad choice. I find C# with dotnet a very good framework that has amazing performance characteristics and also good developer tooling. I coded many things with Ruby and Rails privately and as my daily job but nowadays it is mostly C# for webdev.

The_rationalist 5y ago

No mention of TruffleRuby?