Mark Dickinson added the comment:
Hmm. I thought 2.7 (and 3.3, for that matter) was in bugfix mode only?
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue19171
___
Raymond Hettinger added the comment:
I thought 2.7 (and 3.3, for that matter) was in bugfix mode only?
It would be crazy to not apply this little fix-up.
--
nosy: +rhettinger
___
Python tracker rep...@bugs.python.org
Mark Dickinson added the comment:
It would be crazy to not apply this little fix-up.
Crazy? How so?
Note that this change, while introducing a performance enhancement in some
rather unlikely corner cases, also introduces a performance regression in some
other unlikely corner cases:
Before
Tim Peters added the comment:
I'll revert the 2.7 change if people agree that's a good thing. I'm fine with
it as-is. Armin pulled the idea from timing a Python public-key crypto project
(see the original message in this report), where he found a 14% improvement.
I don't care if the trivial
Mark Dickinson added the comment:
No need to revert. The improvement seems like a good one; I was just a bit
surprised to see it land in the maintenance branches as well as the default
branch. My understanding was that minor performance improvements aren't
normally candidates for inclusion
Tim Peters added the comment:
I'm glad you pointed it out, Mark! You're right about unintended consequences,
and I confess I didn't think at all about the exponent == 0 case.
I didn't remind myself that 2.7 was a bugfix branch either: I read Armin's
(which can be applied on both trunk and
Benjamin Peterson added the comment:
In general, we like to touch 2.7 as little as possible. I'm not sure it's worth
arguing about this (admittely small) change meets the bar.
--
___
Python tracker rep...@bugs.python.org
New submission from Armin Rigo:
The attached patch (which can be applied on both trunk and 2.7) gives a huge
speed improvement for the case 'pow(huge_number, smallish_number,
smallish_number)'. The improvement is unbounded: I get 20x with 'pow(x, y, z)'
with the arguments 'x = 3 ** 1, y
Changes by Benjamin Peterson benja...@python.org:
--
nosy: +mark.dickinson
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue19171
___
___
Tim Peters added the comment:
Good idea! The patch looks almost ready to me: the comment block before the
code block should be updated, since recomputing `base` is no longer being done
_just_ to force `base` to a non-negative value.
--
nosy: +tim.peters
stage: - patch review
Changes by Antoine Pitrou pit...@free.fr:
--
type: - performance
versions: -Python 2.7
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue19171
___
Tim Peters added the comment:
A bit of history: last time I fiddled that code, I didn't worry about this,
because for large enough exponents all internal numbers _eventually_ become
less than `base`. But the patch can speed up the _startup_ costs by an
arbitrary amount (for smaller
Tim Peters added the comment:
Grr: should be: all internal numbers _eventually_ become less than
`modulus`, not less than `base`.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue19171
Tim Peters added the comment:
New patch changes the comments to match the new code.
--
Added file: http://bugs.python.org/file31969/pow.diff
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue19171
Roundup Robot added the comment:
New changeset f34c59494420 by Tim Peters in branch '3.3':
Issue #19171: speed some cases of 3-argument long pow().
http://hg.python.org/cpython/rev/f34c59494420
New changeset 6fcdd1657ee3 by Tim Peters in branch 'default':
Issue #19171: speed some cases of
Changes by Tim Peters t...@python.org:
--
resolution: - fixed
stage: patch review - committed/rejected
status: open - closed
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue19171
___
16 matches
Mail list logo
