Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Get rid of conditional inputs and outputs for instructions in bytecodes.c #128914

Open
markshannon opened this issue Jan 16, 2025 · 1 comment
Open
Labels
interpreter-core (Objects, Python, Grammar, and Parser dirs) performance Performance or resource usage type-feature A feature request or enhancement

Comments

@markshannon
Copy link
Member

markshannon commented Jan 16, 2025

We should remove the conditional stack effects in instruction definitions in bytecodes.c

Conditional stack effects already complicate code generation and that is only going to get worse with top-of-stack caching and other interpreter/JIT optimizations.

There were two reasons for having conditional stack effects:

  1. Ease of porting the old ceval code to bytecodes.c
  2. Performance

Reason 1 no longer applies. Instructions are much more regular now and it isn't that much work to remove the remaining conditional stack effects.

That leaves performance. I experimentally removed the conditional stack effects for LOAD_GLOBAL and LOAD_ATTR which is the worse possible case for performance as it makes no attempt to mitigate the extra dispatch costs and possibly worse specialization.
The results are here
Overall we see a 0.8% slowdown. It seems that specialization is not significantly worse, but there is a large increase in PUSH_NULL following LOAD_GLOBAL that appears to responsible for the slowdown. An extra specialization should fix that.

Prior discussion

Linked PRs

@picnixz picnixz added type-feature A feature request or enhancement interpreter-core (Objects, Python, Grammar, and Parser dirs) performance Performance or resource usage labels Jan 17, 2025
@picnixz
Copy link
Member

picnixz commented Jan 17, 2025

(Tagging it as a performance change even though we would end up with a slowdown. However, this is still something that is performance-related)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
interpreter-core (Objects, Python, Grammar, and Parser dirs) performance Performance or resource usage type-feature A feature request or enhancement
Projects
None yet
Development

No branches or pull requests

2 participants