Skip to content

Port LOAD_ATTR from old opcache to PEP 659 adaptive interpreter #52

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

Closed
markshannon opened this issue May 21, 2021 · 4 comments
Closed
Assignees

Comments

@markshannon
Copy link
Member

There are many specializations for LOAD_ATTR that make sense. LOAD_ATTR in 3.10 only handles two, so we should have an easy win here.

Possible specializations are:

  • Attribute is in instance dictionary
  • Attribute is in a slot
  • Attribute is a non-descriptor attribute of the class
  • Attribute is a property
  • Attribute is method
  • The owner is a module

We will want dictionary keys versioning for several of the above.

@markshannon
Copy link
Member Author

markshannon commented May 26, 2021

  • Add dict keys version
  • Add LOAD_ATTR_ADAPTIVE and two specializations corresponding to existing LOAD_ATTR
  • Split apart specialization for instance dicts into "known keys" and "probable index"
  • Add specializations for module and class attributes

Specializing for properties needs support from call specialization machinery, so will need to wait for that.

@nilansaha
Copy link

Not sure if this is the right place for this but have you guys thought about adding a workflow that automatically benchmarks any PRs opened from this fork and reports it ? Could be really interesting to see speedups as they happen no matter how small. I think the entire Python community is incredibly excited for what is going down here.

@gvanrossum
Copy link
Collaborator

Probably better to open a separate issue. FWIW benchmarks are noisy enough that I think this isn’t going to be all that useful.

@bluss
Copy link

bluss commented May 28, 2021

@nilansaha @gvanrossum Can the existing speed.python.org infrastructure be used for this? Ideally all the merged PRs would be followed-up there. Having a bot that can run the same benchmark set on a PR before it gets merged, would also be a great flow.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
Development

No branches or pull requests

4 participants