56 ms·

> I’m curious how the impact affects development, deployment, etc. YJIT is pretty much transparent in production, if not it's likely a bug. When we tried MJIT

by byroot 5y ago

> I’m curious how the impact affects development, deployment, etc. YJIT is pretty much transparent in production, if not it's likely a bug. When we tried MJIT in production to compare it against YJIT, it causes lots of request timeouts on deploy, because the JIT warmup would take 10 to 20 minutes and it's much slower during that phase. But YJIT warms ups extremely fast and with a much lower overhead, it's seemless on deploy. The only thing you may need to tweak is `--yjit-exec-mem-size`, it defaults to `--yjit-exec-mem-size=256` (MB) which is not quite enough for larger apps. As for development, it would work, but with code reloading enabled, you'd likely exhaust the executable memory allocation pretty fast, because for now YJIT doesn't GC generated code [0]. It will come soon, hopefully before the 3.1.0 release, but that's one of the reason why it's not enabled by default. [0] https://github.com/Shopify/yjit/issues/87 https://github.com/Shopify/yjit/issues/87

joelbluminator 5y ago
Is it 256 mb for the entire app server or is it multiplied by each Unicorn/Puma process?
- byroot 5y ago
  Each process, a small part of it might make it into CoW during boot, but that won't make a big difference. If you don't have the free RAM for it and you app is small enough, you can try lower values. Also note that currently YJIT fully initialize that memory to make it easier to debug, so it's not even virtual. That's another thing that is on the roadmap to be improved soon, and ultimately you'll only pay for the part that YJIT really use even if 250MB is allocated. But overall all JITs trade increased memory usage for faster execution, you have to store that generated code and metadata somewhere.
  - joelbluminator 5y ago
    Do u guys expect it to be on by default eventually, at least for Rails apps?
    - byroot 5y ago
      Yes. Basically the main reason it isn't the default now is the still rough executable memory management. Other than that it's been rock solid and offers decent speedup across a wild range of benchmarks and real world applications. So my personal expectation is for it to be enabled by default in 3.2, but I might be wrong.

by byroot 5y ago

joelbluminator 5y ago

Is it 256 mb for the entire app server or is it multiplied by each Unicorn/Puma process?

byroot 5y ago
Each process, a small part of it might make it into CoW during boot, but that won't make a big difference. If you don't have the free RAM for it and you app is small enough, you can try lower values. Also note that currently YJIT fully initialize that memory to make it easier to debug, so it's not even virtual. That's another thing that is on the roadmap to be improved soon, and ultimately you'll only pay for the part that YJIT really use even if 250MB is allocated. But overall all JITs trade increased memory usage for faster execution, you have to store that generated code and metadata somewhere.
- joelbluminator 5y ago
  Do u guys expect it to be on by default eventually, at least for Rails apps?
  - byroot 5y ago
    Yes. Basically the main reason it isn't the default now is the still rough executable memory management. Other than that it's been rock solid and offers decent speedup across a wild range of benchmarks and real world applications. So my personal expectation is for it to be enabled by default in 3.2, but I might be wrong.