| FazBrowse GitHub Viewer | Trending | | Home |
| Tools: [Download Repo ZIP] [Original HTTPS Page] |
Sorry, something went wrong.
|
If we're touching these, it would make sense to convert them to Argument Clinic, now that *args support is implemented (9af34c9). Lines 1818 to 1823 in 77195cd Lines 1835 to 1840 in 77195cd |
Sorry, something went wrong.
|
I wrote an "Argument Clinic" version here: But seems it is not as fast as current "without Argument Clinic" version: Result of microbench:
On the most commonly used case, "max(a, b [, ...])", there is not noticeable speed up when we use AC, especially when multiple arguments are passed (the last case). I noticed that in 9af34c9 , the varargs on stack are packed to tuple before passed to callee, and callee obtains each argument by access the tuple's elements. |
Sorry, something went wrong.
|
One goal of fastcall is to avoid the creation of a temporary tuple to pass positional arguments (https://bugs.python.org/issue29259). IMHO, the process of pack/unpack arguments to a tuple is unnecessary in 9af34c9 . I would have a try, then may open another issue if necessary. |
Sorry, something went wrong.
Yes, such a change demands a separate issue / PR. It would be nice if you could add proof-of-concept benchmark results when you present the idea in the new bpo issue. I can add the relevant core devs on the nosy list, if you want. Keep in mind that readability and maintainability weigh very heavy when considering a PR; that also goes for optimisation changes. |
Sorry, something went wrong.
While that change certainly looks better, it is buggy; it does not heed the key function. With that in mind, the benchmarks you posted in #30286 (comment) are obviously wrong; the benchmarks with the key keyword are not correct. |
Sorry, something went wrong.
|
I wonder if Argument Clinic Itself could be updated to convert *args to vectorcall/fastcall if some kind of flag appears in the AC declaration |
Sorry, something went wrong.
|
*args support was added to AC in #18609 @isidentical any thoughts on removing the tuple creation in some cases, or with some flag? |
Sorry, something went wrong.
I opened a new issue (gh-903701), Footnotes
|
Sorry, something went wrong.
Thanks for revising my mistake. I'v seen the new results after your amend. |
Sorry, something went wrong.
|
@colorfulappl Is this PR still blocked by #90370? |
Sorry, something went wrong.
Summary: Builtin functions min() and max() now use METH_FASTCALL upstream issue: python/cpython#90350 upstream PR: python/cpython#30286 upstream commit: python/cpython@0066ab5 Reviewed By: carljm Differential Revision: D52650071 fbshipit-source-id: 93971e865ab9515efc9771c58582f63d15e0342d
…30286) Builtin functions min() and max() now use METH_FASTCALL
…30286) Builtin functions min() and max() now use METH_FASTCALL
| Back | FazBrowse Home | New Git URL |
Builtin functions min() and max() are labeled as METH_VARARGS | METH_KEYWORDS, which use tp_call calling convention.
After changing their label to METH_FASTCALL | METH_KEYWORDS, they can be invoked by vectorcall.
This optimization simplifies parameter passing and avoids creation of temporary tuple while parsing arguments, brings about up to 200%+ speed up on microbenchmarks.
faster-cpython/ideas#199
https://bugs.python.org/issue46192