[issue19171] pow() improvement on longs

2013-10-08 Thread Benjamin Peterson
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 ___

[issue19171] pow() improvement on longs

2013-10-08 Thread Tim Peters
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 2

[issue19171] pow() improvement on longs

2013-10-08 Thread Mark Dickinson
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 i

[issue19171] pow() improvement on longs

2013-10-08 Thread Tim Peters
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

[issue19171] pow() improvement on longs

2013-10-08 Thread Mark Dickinson
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

[issue19171] pow() improvement on longs

2013-10-08 Thread Raymond Hettinger
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 _

[issue19171] pow() improvement on longs

2013-10-08 Thread Mark Dickinson
Mark Dickinson added the comment: Hmm. I thought 2.7 (and 3.3, for that matter) was in bugfix mode only? -- ___ Python tracker ___ __

[issue19171] pow() improvement on longs

2013-10-05 Thread Tim Peters
Changes by Tim Peters : -- resolution: -> fixed stage: patch review -> committed/rejected status: open -> closed ___ Python tracker ___ _

[issue19171] pow() improvement on longs

2013-10-05 Thread Roundup Robot
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 3-ar

[issue19171] pow() improvement on longs

2013-10-05 Thread Tim Peters
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 ___ __

[issue19171] pow() improvement on longs

2013-10-05 Thread Tim Peters
Tim Peters added the comment: Grr: should be: "all internal numbers _eventually_ become less than `modulus`", not "less than `base`". -- ___ Python tracker ___ ___

[issue19171] pow() improvement on longs

2013-10-05 Thread Tim Peters
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 exponents

[issue19171] pow() improvement on longs

2013-10-05 Thread Antoine Pitrou
Changes by Antoine Pitrou : -- type: -> performance versions: -Python 2.7 ___ Python tracker ___ ___ Python-bugs-list mailing list U

[issue19171] pow() improvement on longs

2013-10-05 Thread Tim Peters
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 _

[issue19171] pow() improvement on longs

2013-10-05 Thread Benjamin Peterson
Changes by Benjamin Peterson : -- nosy: +mark.dickinson ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: https:/

[issue19171] pow() improvement on longs

2013-10-05 Thread Armin Rigo
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 =