Uh oh!
There was an error while loading. Please reload this page.
gh-87613: Argument Clinic vectorcall decorator - #145381
Conversation
Add `@vectorcall` as a decorator to Argument Clinic (AC) which generates a new [Vectorcall Protocol](https://docs.python.org/3/c-api/call.html#the-vectorcall-protocol) argument parsing C function named `{}_vectorcall`. This is only supported for `__new__` and `__init__` currently to simplify implementation. The generated code has similar or better performance to existing hand-written cases for `list`, `float`, `str`, `tuple`, `enumerate`, `reversed`, and `int`. Using the decorator added vectorcall to `bytearray` and construction got 1.09x faster. For more details see the comments in pythongh-87613. The `@vectorcall` decorator has two options: - **zero_arg={C_FUNC}**: Some types, like `int`, can be called with zero arguments and return an immortal object in that case. Adding a shortcut is needed to match existing hand-written performance; provides an over 10% performance change for those cases. - **exact_only**: If the type is not an exact match delegate to the existing non-vectorcall implementation. NEeded for `str` to get matching performance while ensuring correct behavior. Implementation details: - Adds support for the new decorator with arguments in the AC DSL Parser - Move keyword argument parsing generation from inline to a function so both vectorcall, `vc_`, and existing can share code generation. - Adds an `emit` helper to simplify code a bit from existing AC cases Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
corona10
left a comment
There was a problem hiding this comment.
Could you replace current hand-written with your new DSL.
Let's see how handle them.
cmaloney
commented
Mar 1, 2026
I have commits to do that in my draft branch (https://github.com/python/cpython/compare/main...cmaloney:cpython:ac_vectorcall_v1?expand=0); can pull them into this branch if that would be easier / better to review. This generally produces code that is as fast or faster than the hand-written ones currently (full benchmarking in: #87613 (comment)) |
Added commits moving |
Uh oh!
There was an error while loading. Please reload this page.
corona10
commented
Mar 2, 2026
I will take a look at this PR til end of this week. |
skirpichev
commented
Mar 2, 2026
I would like to suggest you at least to think about complexobject.c. Based on benchmarks for the float pr (#22432) I would expect a good performance boost (maybe not 1.5x, but more than from freelist addition). Yes, this case seems to be already covered by the enum.c example (kwargs). On another hand, the complex class has special hacks to support multiple signatures (
Still, there are some regressions, e.g. int(str). Could you explain this difference? I also suggest you to try pyperformance on this. |
cmaloney
commented
Mar 2, 2026
Will implemnt it in my draft branch this week. As part of developing this PR I added Vectorcall Protocol support to
The Lines 6539 to 6559 in c9a5d9a That switch specializes 1-argument to call I'm comparing to the handwritten because I want
Will run on this PR as it exists currently. I can also run on my draft branch but not sure that will give a clear signal as it migrates every hand-written vectorcall even if it makes them slower. Ideally to me would be able to figure out what types are commonly constructed in pyperformance benchmarks so I can make a draft branch adding |
erlend-aasland
commented
Mar 2, 2026
Did you consider adding this implicitly if supported, instead of making it opt-in? Disclaimer: I didn't take a look at the implementation yet. |
| self.vectorcall = False | ||
| self.vectorcall_exact_only = False | ||
| self.vectorcall_zero_arg = '' |
There was a problem hiding this comment.
I wonder if we should collect these in a "vectorcall config dataclass". The stuff in this file is already so cluttered with tons of class members and local variables.
There was a problem hiding this comment.
I'm not sure it would help readability much for introducing a new to this bit of code pattern.
Would be really nice to refactor the decorator parsing -> argument functions (at_*), they are really repetative to me at the moment; would be nice to not have to do custom key=value parsing in the new at_vectorcall.
There was a problem hiding this comment.
Updated to use a dataclass for this. None now indicates not decorated, then can check individual elements if non-None
Yes, I hope that can mitigate speed regression with Decimal's since v3.13. Edit: no, this doesn't help too much.
In any case, this will happen on case-by-case basis (this pr should include minimal set of such examples). BTW, here my results for this pr + c14c173. Benchmark code: cmaloney@ddcd3b6, run with --rigorous
Benchmark hidden because not significant (9): list(), list_subclass, float(), float(str), bytearray(), tuple(list), int(), reversed(list), enumerate(list) With default ./configure:
BTW, I wonder how noisy your benchmarks, here an alternative approach with bench_func().# vectorcall-bench.pyimportpyperfrunner=pyperf.Runner()
bench_cases= ['1<<7', '1<<38', '1<<300', '1<<3000']
forcinbench_cases: # XXX: bigger samplei=eval(c)
bn=f'int({c})'runner.bench_func(bn, int, i)
forcinbench_cases:
i=eval(c)
s=str(i)
bn=f'int({c!r})'runner.bench_func(bn, int, s)As before, all optimizations:
Default:
I agreed. But if auto-generated code catch major patterns for current hand-written functions - it will be great.
No, I don't think it does make much sense with a lot of conversions to AC magic in one shot. |
My leaning is explicit at least to start. I think that provides a good path for gradual adoption / testing / rollout (hopefully in the 3.15 timeframe). I'd really like at least an alpha which reaches wider testing with a couple common types (ex. bytes) moved to make sure there aren't unanticipated tradeoffs or issues. |
vstinner
left a comment
There was a problem hiding this comment.
Would it be possible to add a @vectorcall test to Modules/_testclinic.c?
vstinner
commented
Mar 13, 2026
This PR is very promising! Great work. |
cmaloney
commented
Mar 18, 2026
Added a vectorcall test to the Debating if a hypothesis test of "does this parse the right args + kwargs" would provide value for the complexity. |
cmaloney
commented
Mar 25, 2026
Full pyperformance numbers on the current PR below. No cases stand out to me / all seems to be within noise for my machine. That is Not sure what will make this easier to review. I am happy to resolve the merge conflict anytime but also don't want to disturb in-process reviews. I am thinking of scoping this down to just pyperformance comparison: 3484ef6 (just before) vs HEAD (vectorcall clinic)Platform: Linux-6.19.9-arch1-1-x86_64-with-glibc2.43 | 32 logical CPUs
|
| /* Forward declarations for vectorcall exemplar types, needed because | ||
| * clinic/_testclinic.c.h is included before the type definitions. */ | ||
| static PyTypeObject VcNew_Type; |
There was a problem hiding this comment.
Created gh-150097 to track that we shouldn't need to do this
Uh oh!
There was an error while loading. Please reload this page.
eendebakpt
left a comment
There was a problem hiding this comment.
Three minor nits, but this looks like a nice improvement.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
| int _result = {c_basename}_impl({vc_impl_arguments}); | ||
| {unlock} | ||
| if (_result != 0) {{ | ||
| Py_DECREF(self); |
There was a problem hiding this comment.
This path is not tested (claude reports some more missing coverage). I checked the generated output and it looks good.
There was a problem hiding this comment.
Coverage of this got dropped when I removed the zero_arg case. Adding a new test class for keyword only type which will cover
…age of generated cases
Uh oh!
There was an error while loading. Please reload this page.
- kwnames != NULL to remove need for label - Unify prototypes - Remove unused parameter - Restructure functions which contained ifs to be two functions or preferrably use a common unified prototype. - Make it so vectorcall requires fast converters - Add test for unsupported converter - Link to more things in NEWS - Replace fast and slow with more descriptive terminology
| """, | ||
| indent=4)) | ||
| elif self.min_pos or max_args != NO_VARARG: | ||
| self.codegen.add_include('pycore_modsupport.h', |
There was a problem hiding this comment.
This is hoisted to _check_positional which both non-vectorcall and vectorcall use
cmaloney
commented
Jul 19, 2026
Substantialy reworked The |
| PyObject *a; | ||
| PyObject *b = Py_None; | ||
| if (_PyType_CAST(type) != &VcNewExact_Type) { |
There was a problem hiding this comment.
This does not seem to happen in any of the paths in this PR. Could we change this into an assert?
| VECTORCALL_FINALE_MARKERS_INIT: Final[dict[str, str]] = { | ||
| "init_declarations": "PyObject *self;\nint _result;", | ||
| "self_alloc": libclinic.normalize_snippet(""" | ||
| self = _PyType_CAST(type)->tp_alloc( |
There was a problem hiding this comment.
| self=_PyType_CAST(type)->tp_alloc( | |
| assert(_PyType_CAST(type)->tp_new==PyType_GenericNew); | |
| self=_PyType_CAST(type)->tp_alloc( |
| } | ||
| VECTORCALL_DELEGATE_MARKERS_INIT: Final[dict[str, str]] = { | ||
| "self_alloc": libclinic.normalize_snippet(""" | ||
| self = _PyType_CAST(type)->tp_alloc( |
There was a problem hiding this comment.
| self=_PyType_CAST(type)->tp_alloc( | |
| assert(_PyType_CAST(type)->tp_new==PyType_GenericNew); | |
| self=_PyType_CAST(type)->tp_alloc( |
Generated vectorcall replaces tp_new with a bare tp_alloc, which is only correct when tp_new is PyType_GenericNew.
Add
@vectorcallas a decorator to Argument Clinic (AC) which emits a Vectorcall Protocol argument parsing C function named{type}_vectorcall. This is only supported for__new__and__init__currently to simplify implementation.The generated code has similar or better performance to existing hand-written cases for
list,float,str,tuple,enumerate,reversed, andint. Using the decorator onbytearray, which has no handwritten case, construction got 1.09x faster. For more benchmark details see #87613 (comment).The
@vectorcalldecorator has two options:zero_arg={C_FUNC}: Some types, likeint, can be called with zero arguments and return an immortal object in that case. Adding a shortcut is needed to match existing hand-written performance; provides an over 10% performance change for those cases.exact_only: If the type is not an exact match delegate to the existing non-vectorcall implementation. Needed forstrto get matching performance while ensuring correct behavior.Implementation details:
vc_, and existing can share code generation.emithelper to simplify code a bit from existing AC casesCo-Authored-By: Claude Opus 4.6 noreply@anthropic.com