This is awesome! Ruby is a notoriously hard language to optimize thanks to its (wonderful) dynamism, so it's very exciting to see substantial performance gains with this new JIT.
Something that I noticed that might throw others for a loop as well: the changeset is north of 350K, but the actual JIT is only a couple of thousands of lines of C. 90% of the changeset is two torture test files.
"YJIT currently provides average speedups of 23% over the CRuby interpreter on realistic benchmarks, and near-instant warm-up time. Plans are to include YJIT in the Ruby 3.1 preview release so that more users can test it out and benefit from potential performance gains."
> YJIT uses significantly more memory when active -- e.g. OptCarrot takes 80MB without YJIT and 350MB with YJIT. This can be adjusted by setting --yjit-exec-mem-size.
This one gave me a worry. I think it can be addressed, but if it can't this whole effort seems a bit overrated to me.
It's always a trade off of time and space, especially for dynamic languages. Glad the flag is there, and it will be interesting to see more real-world data once it's out in the wild.
More than just the JIT itself, I'm very interested in seeing if this will push Ruby towards making other performance-related inprovements to it's data structures and bytecode format:
But you do the process you described only once per "warmed up" method right? Yes it sound expensive but once it's warmed up it should be as good as YJIT or am I missing something?
This is so cool and for people who use Jekyll it improves Jekyll's liquid template rendering speed. JRuby and TrufflyRuby's JIT did not, at least for me.
Something that I noticed that might throw others for a loop as well: the changeset is north of 350K, but the actual JIT is only a couple of thousands of lines of C. 90% of the changeset is two torture test files.