-
-
Notifications
You must be signed in to change notification settings - Fork 30.8k
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
GH-93657: More LOAD_ATTR specializations #93892
GH-93657: More LOAD_ATTR specializations #93892
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Specializing property accesses is clearly worthwhile.
I'm not so sure about mutable descriptors. Do they represent a large enough fraction of attributes, and is the specialized form that much faster?
@@ -3650,6 +3649,76 @@ _PyEval_EvalFrameDefault(PyThreadState *tstate, _PyInterpreterFrame *frame, int | |||
NOTRACE_DISPATCH(); | |||
} | |||
|
|||
TARGET(LOAD_ATTR_CLASS_MUTABLE_DESCRIPTOR) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is this common enough to justify its own specialization, especially as we need to do much of the work of general lookup?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
According to the stats on the faster-cpython repo, this represents 5.7% of the remaining failures. In contrast, properties are 13.8%. Class method objects are quite close, at 6.2%.
Here's a microbenchmark, with no PGO nor LTO, but it's a Windows release build (similar to -O3).
python -m timeit -s "
from enum import Enum
class Colours(Enum):
RED = 1
" "Colours.RED"
# on MAIN:
2000000 loops, best of 5: 121 nsec per loop
2000000 loops, best of 5: 120 nsec per loop
2000000 loops, best of 5: 120 nsec per loop
# on this PR:
5000000 loops, best of 5: 77.2 nsec per loop
5000000 loops, best of 5: 73.5 nsec per loop
5000000 loops, best of 5: 72.1 nsec per loop
With PGO and LTO, I expect the difference to be less dramatic. But I still expect this form to be ~=15% faster than the base version.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do you have a non-enum example?
enums members should be simple class attributes.
#93910
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't. This opcode was specifically designed with enum in mind.
I'm quite surprised that the property specialisation's speedup is less than 2x:
Maybe your work in #93897 shall fix that. |
Given that #93910 is likely to be messing up our stats, maybe put this hold for a while? |
Specializes for
@property()
with Python functions