Skip to content

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

Closed

Description

@markshannon

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

Activity

  1. added
    type-featureA feature request or enhancement
    interpreter-core(Objects, Python, Grammar, and Parser dirs)
    performancePerformance or resource usage
    on Jan 17, 2025
  2. picnixz commented on Jan 17, 2025

    @picnixz
    Member

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

  3. added a commit that references this issue on Jan 20, 2025
  4. added a commit that references this issue on Jan 21, 2025
  5. added 2 commits that reference this issue on Jan 22, 2025
  6. added a commit that references this issue on Jan 23, 2025
  7. markshannon commented on Jan 23, 2025

    @markshannon
    MemberAuthor

    It seems that #128918 caused a 2-3% slowdown on the free-threading build.

  8. mdboom commented on Jan 23, 2025

    @mdboom
    Contributor

    It seems that #128918 caused a 2-3% slowdown on the free-threading build.

    FWIW, I couldn't reproduce this on our infrastructure. I'm not claiming one is better or more reliable, only that the effect being noticed here might be more complicated...

  9. added a commit that references this issue on Jan 27, 2025
  10. markshannon commented on Jan 28, 2025

    @markshannon
    MemberAuthor

    Latest implementation has no adverse impact on performance.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    interpreter-core(Objects, Python, Grammar, and Parser dirs)performancePerformance or resource usagetype-featureA feature request or enhancement

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions