bpo-46939: Specialize calls to Python classes#31707
Conversation
|
I nearly went insane writing and debugging this. The general idea follows Mark's comments in faster-cpython/ideas#267 (comment). However, since we're specializing |
Sorry, something went wrong.
|
Nice! Haven't had a chance to review this yet (I can probably get to it tomorrow, though). Unfortunately, I have another, larger PR open that heavily conflicts with this one. Is it okay if this waits until #31709 is merged? The caching in this PR will need to be reworked a bit to use the new inline caching mechanism, but it shouldn't be too difficult. |
Sorry, something went wrong.
|
This feels a bit fragile to me, but it is an interesting alternative to my approach of pushing an additional cleanup frame (https://github.com/python/cpython/compare/main...faster-cpython:specialize-calls-to-normal-python-classes?expand=1) This PR should be faster for calls to Python classes, but the extra frame field will have a cost for calls to Python functions. |
Sorry, something went wrong.
Indeed, hence why I nearly went insane :). One very easy way to trip over is that all new P.S. Do your benchmarks say anything? I'm really sorry but right now I can't benchmark. P.P.S. That's an interesting approach that I can't currently wrap my head around. Sorry if I created any duplicate work. |
Sorry, something went wrong.
|
I've updated the first comment with a micro benchmark using pyperf on Windows with PGO. The results show |
Sorry, something went wrong.
|
Pyperformance shows a speedup in object-heavy workloads. 1% speedup on average: |
Sorry, something went wrong.
…ize_py_class_calls
|
I'll close it when that one's merged |
Sorry, something went wrong.
CALL_X supporting
__init__inlining:Micro benchmark using pyperf (Windows, PGO):
https://bugs.python.org/issue46939