Avoid temporary varargs tuple creation in argument passing

@larryhastings

BPO	46212
Nosy	@larryhastings, @pablogsal, @isidentical, @erlend-aasland, @colorfulappl
PRs	gh-90370: Avoid temporary `varargs` tuple creation in argument passing #30312
Files	bench-print.py

^{Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.}

Show more details

GitHub fields:

assignee = None
closed_at = None
created_at = <Date 2021-12-31.10:05:47.113>
labels = ['3.11', 'expert-argument-clinic', 'performance']
title = 'Avoid temporary `varargs` tuple creation in argument passing'
updated_at = <Date 2022-01-21.14:06:02.177>
user = 'https://github.com/colorfulappl'

bugs.python.org fields:

activity = <Date 2022-01-21.14:06:02.177>
actor = 'erlendaasland'
assignee = 'none'
closed = False
closed_date = None
closer = None
components = ['Argument Clinic']
creation = <Date 2021-12-31.10:05:47.113>
creator = 'colorfulappl'
dependencies = []
files = ['50533']
hgrepos = []
issue_num = 46212
keywords = ['patch']
message_count = 6.0
messages = ['409412', '409413', '409414', '409659', '411129', '411130']
nosy_count = 5.0
nosy_names = ['larry', 'pablogsal', 'BTaskaya', 'erlendaasland', 'colorfulappl']
pr_nums = ['30312']
priority = 'normal'
resolution = None
stage = 'patch review'
status = 'open'
superseder = None
type = 'performance'
url = 'https://bugs.python.org/issue46212'
versions = ['Python 3.11']

Linked PRs

gh-90370: avoid temporary tuple creation for vararg in AC #126064

When "Augument Clinic generated code" are parsing arguments, the args are packed to a tuple before passing to callee. This may be unnecessary.

Pass a raw pointer which points to on-stack varargs, and a varargssize integer to indicate how many varargs are passed, can save the time of tuple creation/destruction and value copy.

I wrote some microbenchs.

Patch: b68176d

Environment:
macOS 12.1
clang 13.0.0
configure with --enable-optimizations

Result on microbench:

+--------------------------------------------+-------------------------+------------------------+
| Benchmark                                  | ./opt_baseline/res.json | ./opt_patched/res.json |
+============================================+=========================+========================+
| print(a, b, c)                             | 917 ns                  | 820 ns: 1.12x faster   |
+--------------------------------------------+-------------------------+------------------------+
| print(a, b, c, *v)                         | 1.56 us                 | 1.62 us: 1.04x slower  |
+--------------------------------------------+-------------------------+------------------------+
| print(a, sep='', file=stdout)              | 376 ns                  | 295 ns: 1.27x faster   |
+--------------------------------------------+-------------------------+------------------------+
| print(*v, sep='', flush=True, file=stdout) | 2.02 us                 | 1.94 us: 1.04x faster  |
+--------------------------------------------+-------------------------+------------------------+
| Geometric mean                             | (ref)                   | 1.05x faster           |
+--------------------------------------------+-------------------------+------------------------+

Benchmark hidden because not significant (3): print(a), print(a, sep='', flush=True, file=stdout), print(a, b, c, *v, sep='', flush=True, file=stdout)

Note that _PyArg_UnpackKeywordsWithVararg is defined with PyAPI_FUNC. Changing its argument spec is strictly a backwards incompatible change, IIUC.

I am a rookie in Python, did not notice changing PyAPI_FUNC means breaking backward compatibility.

I have reverted _PyArg_UnpackKeywordsWithVararg and committed again.

@pablogsal

Note that _PyArg_UnpackKeywordsWithVararg is defined with PyAPI_FUNC. Changing its argument spec is strictly a backwards incompatible change, IIUC.

AFAIK we have committed _PyArg_UnpackKeywordsWithVararg on 3.11 alpha, so I think it should be fine. Also CC: @pablogsal

AFAIK we have committed _PyArg_UnpackKeywordsWithVararg on 3.11 alpha, so I think it should be fine.

I see, so no ABI worries then.

@erlend-aasland

@erlend-aasland, I'm not sure we can mark this a fixed issue.

The merged pr covers only part of the original proposal (e.g. it doesn't work for the OP example with print()).

I planned to came to this issue in few steps:

Current gh-122943: Rework support of var-positional parameter in Argument Clinic #122945.
Move the code for var-positional parameter to a separate converter (this is not easy, because it needs more parameters).
Split that converter into two converters -- 'tuple' and 'array' to support different representations.

There may be other intermediate steps. I tried to do this in one step, but it was too complicated.

Now, #126064 created conflicts with #122945. I spent a day for this, and see a light at the end of tunnel, but the simplest way to resolve conflict is to revert #126064. Then merge #122945, then continue the initial plan. This will take a time.

Alternatively, I can fuse all these steps in #122945, but the result will be larger and very dirty, because I would need to use dirty tricks like using globals to pass values of local variables between function calls in three or four different modules.

@skirpichev

Reverting #126064 will also mean reverting #126235. Are there any others that would need reverting, @skirpichev?

@serhiy-storchaka

Reverting #126064 will also mean reverting #126235.

Not necessary. Reverting #126064 will just introduce some performance regression for converted functions. But as @serhiy-storchaka planned to address this issue In The Right Way - this will be eventually fixed.

Are there any others that would need reverting

None, as far as I know.

Sounds good. Serhiy, please go ahead.

(Given the size (few lines) of #126064, I don't see big problem to resolve merge conflicts. I'll try to do this. Serhiy, feel free to ignore these efforts.)

(Given the size (few lines) of #126064, I don't see big problem to resolve merge conflicts. I'll try to do this. Serhiy, feel free to ignore these efforts.)

IMO, this would be the best option; if we can avoid the revert churn that would be great.

So, if this is not urgent, give me a day.

I think, this is fixed by #122945 and #126560.

@colorfulappl

Thanks, @colorfulappl, for the proposal and initial work; thanks Serhiy and Sergey for the PRs 🍰 👏 🥳

pythongh-90370: Argument Clinic: avoid temporary tuple creation for v…

Navigation Menu

Repository navigation

Avoid temporary `varargs` tuple creation in argument passing #90370

Linked PRs

9 remaining items

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

Avoid temporary varargs tuple creation in argument passing #90370

Description

Linked PRs

Activity

colorfulappl commented on Dec 31, 2021

colorfulappl commented on Dec 31, 2021

erlend-aasland commented on Dec 31, 2021

colorfulappl commented on Jan 4, 2022

isidentical commented on Jan 21, 2022

erlend-aasland commented on Jan 21, 2022

9 remaining items

skirpichev commented on Oct 31, 2024

serhiy-storchaka commented on Nov 6, 2024

erlend-aasland commented on Nov 6, 2024

skirpichev commented on Nov 6, 2024

erlend-aasland commented on Nov 6, 2024

skirpichev commented on Nov 6, 2024

erlend-aasland commented on Nov 6, 2024

skirpichev commented on Nov 6, 2024

skirpichev commented on Nov 8, 2024

erlend-aasland commented on Nov 8, 2024

Metadata

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

Issue actions

Avoid temporary `varargs` tuple creation in argument passing #90370