GH-112354: Initial implementation of warm up on exits and trace-stitching #114142
Conversation
|
Sorry, didn't get to a proper review of this today. I've been trying (and failing) to merge the JIT branch into this one without crashing. Maybe we can chat "in person" later? |
|
Okay, I was able to get it working-ish... but it's not pretty. We can go over it when we meet. |
There was a problem hiding this comment.
Here's a first, partial pass. I've tried to focus on things that confused me. I haven't fully reviewed optimizer.c yet, nor the _COLD_EXIT uop definition, so I'll focus on those when I find some time.
Maybe it would be useful to add TODO comments indicating things you're planning to tackle in the near future (subsequent PRs)? Like the counters.
I'd prefer to save that for another PR. Maybe the one that removes the |
|
FTR, the thresholds are likely to get completely changed soon. We probably want to change the fixed thresholds to some sort of adaptive thresholds, and consider the T1 and T2 thresholds together so that specialization works correctly. |
|
If you look at GitHub there’s still a missing cast somewhere. |
There was a problem hiding this comment.
Didn't look too closely at the cases generator or optimizer (I'm assuming there are other eyes on that).
- I appreciate the writeup!
- I like that the interpreter/JIT interfaces are a lot more unified on this iteration. I know you're not crazy about conditional macro stuff but I think it makes things a lot easier to follow in this case. Thanks.
- Suggestions to remove bit of tricky code duplication in
template.c. - A couple of questions about setting
tstate->previous_executor. - A few other random questions/suggestions I had while reading through.
- One thing I find sort of tricky to keep track of is the nuances of the first couple of instructions in the trace (when/where
_START_EXECUTORis added, when/where pointers to optimizers/executors are smuggled in as operands, etc). This might be worth cleaning up now or in the future, or at least writing up. Not sure.
|
When you're done making the requested changes, leave the comment: |
|
I don't think there is a new bug here, but this PR exposes it. #115727 |
Only works for boolean guards, not type guards, for now. And
_EXIT_TRACEnow.Needs to be carefully documented, there's some subtlety here.
Exits are implemented as an array of records attached to the executors, and a fixed set of cold exit executors.
We can shrink the
_PyExitDatafurther, by moving the counters into a global table, but that's for another PR.See faster-cpython/ideas#644 for a rough sketch of the design.