Minor speedup for bigint squaring

[tim-one]

BPO	46233
Nosy	@tim-one
PRs	bpo-46233: Minor speedup for bigint squaring #30345

^{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 = 'https://github.com/tim-one'
closed_at = <Date 2022-01-04.02:43:20.811>
created_at = <Date 2022-01-02.22:48:26.766>
labels = ['interpreter-core', '3.11', 'performance']
title = 'Minor speedup for bigint squaring'
updated_at = <Date 2022-01-04.02:43:20.810>
user = 'https://github.com/tim-one'

bugs.python.org fields:

activity = <Date 2022-01-04.02:43:20.810>
actor = 'tim.peters'
assignee = 'tim.peters'
closed = True
closed_date = <Date 2022-01-04.02:43:20.811>
closer = 'tim.peters'
components = ['Interpreter Core']
creation = <Date 2022-01-02.22:48:26.766>
creator = 'tim.peters'
dependencies = []
files = []
hgrepos = []
issue_num = 46233
keywords = ['patch']
message_count = 2.0
messages = ['409534', '409645']
nosy_count = 1.0
nosy_names = ['tim.peters']
pr_nums = ['30345']
priority = 'normal'
resolution = 'fixed'
stage = 'resolved'
status = 'closed'
superseder = None
type = 'performance'
url = 'https://bugs.python.org/issue46233'
versions = ['Python 3.11']

[tim-one]

longobject.c's x_mul()'s special code for squaring gets kind of sloppy at the end of a digit pass, doing a useless add of 0 and an "extra" test for carry. Easily cleaned up.

I think the underlying cause is that the HAC algorithm description it was modeled on was quite "hand wavy" about how badly, and exactly when, the carry can exceed a single digit. Things are better-behaved at the end of a digit pass.

[tim-one]

New changeset 3aa5242 by Tim Peters in branch 'main':
bpo-46233: Minor speedup for bigint squaring (GH-30345)
3aa5242