[issue46850] [C API] Move _PyEval_EvalFrameDefault() to the internal C API
Change by Itamar Ostricher : -- nosy: +itamaro ___ Python tracker <https://bugs.python.org/issue46850> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46893] Allow extensions to set the vectorcall field on instances of PyFunctionObject
New submission from Itamar Ostricher : CPython extensions providing optimized execution of Python bytecode (like [Cinder JIT](https://docs.google.com/document/d/1l8I-FDE1xrIShm9eSNJqsGmY_VanMDX5-aK_gujhYBI/edit#heading=h.ujldakarfxhh) and [Pyjion](https://github.com/tonybaloney/Pyjion)) can benefit from being able to modify the vectorcall field on instances of PyFunctionObject to allow calling the optimized path (e.g. JIT-compiled) directly. We propose adding an API to allow extensions to override this field: ``` void PyFunction_SetVectorcall(PyFunctionObject *func, vectorcallfunc vectorcall); ``` -- components: Interpreter Core messages: 414302 nosy: carljm, dino.viehland, itamaro priority: normal severity: normal status: open title: Allow extensions to set the vectorcall field on instances of PyFunctionObject type: enhancement versions: Python 3.11 ___ Python tracker <https://bugs.python.org/issue46893> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30533] missing feature in inspect module: getmembers_static
Itamar Ostricher added the comment: interested in this too - came here to see if I can implement, but found that a patch is already available (GH-20911), and applies cleanly on latest main branch (see my PR comments) would be great if it gets merged! -- nosy: +itamaro ___ Python tracker <https://bugs.python.org/issue30533> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45697] PyType_IsSubtype is doing excessive work in the common case
Itamar Ostricher added the comment:
thanks for the feedback Serhiy!
repeating my response from the PR here as well (not sure what's the proper
etiquette.. :-) )
note that this code path is not for creating new types (which is slow as you
say), but for creating new instances (which is quite fast).
I ran some synthetic benchmarks with this change and without it (on an opt
build with PGO and LTO), and the gain is measurable:
build from main (commit acc89db9233abf4d903af9a7595a2ed7478fe7d3 which is the
base commit for this PR):
```
>for _ in {1..10}; do ./main-opt/python -m timeit -n 1 -s 'class Spam:
>pass' -- 'ten_k_spams = [Spam() for _ in range(1)]'; done
1 loops, best of 5: 896 usec per loop
1 loops, best of 5: 887 usec per loop
1 loops, best of 5: 857 usec per loop
1 loops, best of 5: 838 usec per loop
1 loops, best of 5: 847 usec per loop
1 loops, best of 5: 863 usec per loop
1 loops, best of 5: 845 usec per loop
1 loops, best of 5: 902 usec per loop
1 loops, best of 5: 890 usec per loop
1 loops, best of 5: 875 usec per loop
```
build with this change applied (commit
2362bf67e8acee49c6f97ea754d59dfd8982e07c):
```
>for _ in {1..10}; do ./test-opt/python -m timeit -n 1 -s 'class Spam:
>pass' -- 'ten_k_spams = [Spam() for _ in range(1)]'; done
1 loops, best of 5: 833 usec per loop
1 loops, best of 5: 885 usec per loop
1 loops, best of 5: 845 usec per loop
1 loops, best of 5: 838 usec per loop
1 loops, best of 5: 833 usec per loop
1 loops, best of 5: 827 usec per loop
1 loops, best of 5: 858 usec per loop
1 loops, best of 5: 811 usec per loop
1 loops, best of 5: 843 usec per loop
1 loops, best of 5: 845 usec per loop
```
also worth noting that the previous approach (GH-29380) was implemented on the
Instagram Server production workload in Meta/Facebook/Instagram (choose your
favorite) and resulted measurable perf gain of around 0.2%
--
___
Python tracker
<https://bugs.python.org/issue45697>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45697] PyType_IsSubtype is doing excessive work in the common case
Itamar Ostricher added the comment: thanks for the feedback & discussion, I submitted a new PR -- ___ Python tracker <https://bugs.python.org/issue45697> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45697] PyType_IsSubtype is doing excessive work in the common case
Change by Itamar Ostricher : -- pull_requests: +27650 pull_request: https://github.com/python/cpython/pull/29392 ___ Python tracker <https://bugs.python.org/issue45697> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45697] PyType_IsSubtype is doing excessive work in the common case
Itamar Ostricher added the comment: Dennis, you mean something like this? https://github.com/itamaro/cpython/commit/92d46b260cf6ccce1a47003f539294530138e488 sure, that would preempt the `PyType_IsSubtype` calls coming from these specific callsites, but the early return in `PyType_IsSubtype` would cover those as well as any other path, wouldn't it? -- ___ Python tracker <https://bugs.python.org/issue45697> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45697] PyType_IsSubtype is doing excessive work in the common case
Change by Itamar Ostricher : -- keywords: +patch pull_requests: +27638 stage: -> patch review pull_request: https://github.com/python/cpython/pull/29380 ___ Python tracker <https://bugs.python.org/issue45697> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45697] PyType_IsSubtype is doing excessive work in the common case
New submission from Itamar Ostricher : Based on real world profiling data we collected, a vast amount of `PyType_IsSubtype` calls are coming from `type_call`, when it decides whether `__init__` should run or not. In the common case, the arguments to this call are identical, but the implementation still walks the MRO. By returning early for identical types, the common case can be optimized with a non-trivial performance gain. -- components: Interpreter Core messages: 405575 nosy: itamaro priority: normal severity: normal status: open title: PyType_IsSubtype is doing excessive work in the common case type: performance versions: Python 3.11 ___ Python tracker <https://bugs.python.org/issue45697> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
