YJIT: Make ratio_in_yjit always available

[k0kubun]

This PR changes ratio_in_yjit to be available on any YJIT-enabled build. To minimize overhead when --yjit or --yjit-stats is not used, we increment a global variable without branching or locking. The counter could be inaccurate on Ractors.

Performance

interpreter

before: ruby 3.3.0dev (2023-07-13T18:48:14Z master 62ecf78b87) [x86_64-linux]
after: ruby 3.3.0dev (2023-07-13T20:22:04Z yjit-reg-counter 6c13fcc476) [x86_64-linux]

----------  -----------  ----------  ----------  ----------  -------------  ------------
bench       before (ms)  stddev (%)  after (ms)  stddev (%)  after 1st itr  before/after
railsbench  1912.2       0.6         1913.4      0.6         1.00           1.00
----------  -----------  ----------  ----------  ----------  -------------  ------------

--yjit

before: ruby 3.3.0dev (2023-07-13T18:48:14Z master 62ecf78b87) +YJIT [x86_64-linux]
after: ruby 3.3.0dev (2023-07-13T20:22:04Z yjit-reg-counter 6c13fcc476) +YJIT [x86_64-linux]

----------  -----------  ----------  ----------  ----------  -------------  ------------
bench       before (ms)  stddev (%)  after (ms)  stddev (%)  after 1st itr  before/after
railsbench  1237.2       1.1         1239.3      1.1         1.00           1.00
----------  -----------  ----------  ----------  ----------  -------------  ------------

--yjit-stats

before: ruby 3.3.0dev (2023-07-13T18:48:14Z master 62ecf78b87) +YJIT [x86_64-linux]
after: ruby 3.3.0dev (2023-07-13T20:22:04Z yjit-reg-counter 6c13fcc476) +YJIT [x86_64-linux]

----------  -----------  ----------  ----------  ----------  -------------  ------------
bench       before (ms)  stddev (%)  after (ms)  stddev (%)  after 1st itr  before/after
railsbench  1326.9       1.0         1317.0      1.0         1.00           1.01
----------  -----------  ----------  ----------  ----------  -------------  ------------

This PR doesn't seem to have a significant performance impact on railsbench.

[maximecb]

So the good news is it looks like you managed to make the overhead negligible, but that comes at the expense of some accuracy. Are we sure that the loss in accuracy will always be small?

Looking at the PR. I think maybe things could be simplified a bit? It looks like there are a few functions exported on both sides. Ideally, maybe we should try to do as much of the vm_insn_count accounting on the C side?

I'm also wondering if you tried to make it so that the C interpreter loop just does an atomic increment on a vm_insn_count global variable? I assume you've tried this and it was slower?

[k0kubun]

I'm also wondering if you tried to make it so that the C interpreter loop just does an atomic increment on a vm_insn_count global variable? I assume you've tried this and it was slower?

I assumed it wouldn't be faster than incrementing a local variable, so I didn't try it. I tried it now, and here's the result.

Using lock addq does slow down the interpreter on railsbench by 2%. However, using addq without locking does not slowdown the interpreter on railsbench. Given that it could be inaccurate only when you run multiple Ractors, I think it's a better type of inaccuracy for us? I'll update the PR like that after lunch.

[maximecb]

However, using addq without locking does not slowdown the interpreter on railsbench. Given that it could be inaccurate only when you run multiple Ractors, I think it's a better type of inaccuracy for us? I'll update the PR like that after lunch.

Sounds like it could be a pretty good tradeoff 👍 🙂

[k0kubun]

I simplified the implementation 6cf33c8 and updated the benchmark results on the PR description. The current version seems much nicer 🙂

[maximecb]

Nice! It's awesome that we can now have all the stats including percentage in YJIT on all builds! 😎