Remove _DYNAMIC_EXIT
#129715
Labels
interpreter-core
(Objects, Python, Grammar, and Parser dirs)
performance
Performance or resource usage
topic-JIT
type-feature
A feature request or enhancement
Uh oh!
There was an error while loading. Please reload this page.
Looking at the latest benchmarking comparison for JIT on vs. JIT off, we currently have a number of benchmarks that are slowed down significantly, with 16 benchmarks slowing down over 5%, 3 slowing down over 15%, and one (
generators
) slowing down over 25%. Clearly, there are some code patterns that we just aren't handling well. If we want people to turn on the JIT, we need to minimize this potential downside.It appears the culprit is, well, generators. In particular,
_DYNAMIC_EXIT
. Long story short, I think we should ditch_DYNAMIC_EXIT
, at least for now. It was always a bit of a not-quite-complete solution to a hard tracing problem, and getting rid of it is enough to cancel out the slowdown on all of our slowest benchmarks (only 10 benchmarks are slowed down more than 5%, and none slowed down more than 10%).We use
_DYNAMIC_EXIT
for a couple of code patterns:FOR_ITER_GEN
orSEND_GEN
. This will no longer successfully project a trace.LOAD_ATTR_PROPERTY
orBINARY_SUBSCR_GETITEM
. These caches actually have the necessary information to continue tracing, so_DYNAMIC_EXIT
isn't really needed anymore.We may also want to fail to create traces that end in
YIELD_VALUE
, but that can be considered separately as a follow up.Once this is done, we can work on a new solution for tracing generators that's more robust (perhaps by using normal side exits, and starting each trace with a guard on the instruction pointer). We should probably only merge a solution once it's proven to work in practice, since the JIT is beginning to mature and stabilize.
(Thanks @mdboom for the idea.)
Linked PRs
_DYNAMIC_EXIT
#129716The text was updated successfully, but these errors were encountered: