ZJIT: Profile each instruction at most num_profiles times #13903
Conversation
|
What do you think about having num profiles correspond to the sum of:
This way we can still keep one count per iseq but we don't have a profile-time explosion with loops. |
With that implementation, when there's a loop, non-looped instructions or instructions in a different loop will have a significantly smaller number of profiles. While it satisfies "we don't have a profile-time explosion with loops", I don't think it's the intended behavior. |
I think that's fine, actually, and mirrors what we have today as well. It's kind of sampling-profiler-esque. |
|
I think many instructions will need only one profile (as suggested in the PR description), so I'm fine with that for such instructions. I feel uncomfortable having only one profile for other instructions. However, if the intention is that we assume it never happens in reality because people don't use while loops and it doesn't matter for loop methods themselves, I'm open to merging such a change. |
This PR changes ZJIT instructions to only profile at most
--zjit-num-profilestimes.ZJIT currently profiles all instructions for
num_profilescalls, but when the ISEQ contains a while loop, each instruction can be profiled more thannum_profilestimes, which I didn't expect. So this PR optimizes such cases. We don't really use while loops in reality, but loop methods themselves use a while loop, so this will be helpful for real-world code too.There's a trade-off that we need to consume more memory for the per-insn counters, but the impact seems significant enough to justify it. In addition, we could make it more compact and/or restrict some instructions to profile only once to save memory, but it's out of scope in this PR.