Quite curious how it will evolve, yet another JIT to track as compiler geek.
Plus points for having all code generation flags in the standard implementation, instead of requiring a debug build like on V8, or an additional plugin like on most JVMs.
sabslikesobs · 4h ago
I don't know anything about compliers, so this note about reasons and intentions from the presentation link was helpful to me:
> YJIT can make Ruby code run faster, but this is a balancing act, because the JIT compiler itself must consume both memory and CPU cycles to compile and optimize your code while it is running. Furthermore, in large-scale production environments such as those of GitHub, Shopify and Stripe, we end up in a situation where YJIT is compiling the same code over and over again on a very large number of servers, which seems very inefficient.
> In this presentation, we will go over the design of ZJIT, a next generation Ruby JIT which aims to save and reuse compiled code between executions. We hope that this will help us eliminate duplicated work while also allowing the compiler to spend more time optimizing code so that we can get better performance.
Seems pretty cool. I haven't run into any these limitations in my own usage really, but I'm working at very small scales.
MarkSweep · 26m ago
> I haven't run into any these limitations in my own usage really, but I'm working at very small scales.
That’s the way a lot of the optimization problems work. If you have a sever or two, the efficiency is not such a big deal. Once you have a lot of servers, making Ruby a few percents more efficient reduces the number of servers you need and thus justifies paying people to optimize Ruby.
Plus points for having all code generation flags in the standard implementation, instead of requiring a debug build like on V8, or an additional plugin like on most JVMs.
> YJIT can make Ruby code run faster, but this is a balancing act, because the JIT compiler itself must consume both memory and CPU cycles to compile and optimize your code while it is running. Furthermore, in large-scale production environments such as those of GitHub, Shopify and Stripe, we end up in a situation where YJIT is compiling the same code over and over again on a very large number of servers, which seems very inefficient.
> In this presentation, we will go over the design of ZJIT, a next generation Ruby JIT which aims to save and reuse compiled code between executions. We hope that this will help us eliminate duplicated work while also allowing the compiler to spend more time optimizing code so that we can get better performance.
Seems pretty cool. I haven't run into any these limitations in my own usage really, but I'm working at very small scales.
That’s the way a lot of the optimization problems work. If you have a sever or two, the efficiency is not such a big deal. Once you have a lot of servers, making Ruby a few percents more efficient reduces the number of servers you need and thus justifies paying people to optimize Ruby.