[Patches] [ python-Patches-1442927 ] PyLong_FromString optimization

[SourceForge.net]

Patches item #1442927, was opened at 2006-03-04 01:21
Message generated for change (Comment added) made by alanmcintyre
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1442927&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Core (C code)
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Submitted By: Alan McIntyre (alanmcintyre)
Assigned to: Nobody/Anonymous (nobody)
Summary: PyLong_FromString optimization

Initial Comment:
The current implementation of PyLong_FromString in
Python 2.5 uses muladd1 to add each digit of the input
string into the final number.  Because muladd1 creates
a new long to hold the result on every call, an
intermediate long object is created/destroyed for each
digit in the input string.  

This patch improves on the current implementation of
PyLong_FromString in 3 main ways:

1. Creates and manipulates (in-place) a single long
object to hold the result, skipping the creation of all
those intermediate long objects.

2. Multiple digits from the input string are
consolidated into a single long digit before adding
them into the long integer object.  This greatly
reduces the number of "multiply/add" cycles required to
push all the digits into the long object.

3. Three chunks of code like "if (ch <= '9') k = ch -
'0'" in longobject.c are replaced by a digit value
lookup vector.  I'm not irreversibly stuck on this
idea; it doesn't measurably add to performance, but it
just seems (to me, anyway) to make the code in
long_from_binary_base and PyLong_FromString a little
less cluttered.  This is the same lookup table from
patch 1335972 (an optimization for int()).  I expect if
both patches get accepted it would be best to make them
both reference a single instance of this table; if it
looks like that's what will happen I'll tweak one or
both patches as necessary.


My cheezy test results (included in the attached file
in an OpenOffice spreadsheet) show that the patch makes
long() about 50% faster than the existing
implementation for decimal input strings of about 10
characters.   Longer input strings show even better
performance improvement, leveling off around 3x faster
for very long strings.

This patch passes regression tests on my machine
(WinXP, Visual C++ .net Standard 2003).  I plan to try
out the tests on my Linux box this weekend just to make
sure the performance boost still remains when Python
gets compiled by a C compiler that isn't neutered
(standard .net 2003 doesn't appear to allow any
optimizations).

The test and test data generation scripts I used for
this performance comparison are included in the
attached zip file. 

At the moment I don't have any added tests; if somebody
can suggest some things that ought to be tested I'll
gladly write some tests.


----------------------------------------------------------------------

>Comment By: Alan McIntyre (alanmcintyre)
Date: 2006-03-06 17:33

Message:
Logged In: YES 
user_id=1115903

Version #2 is attached.  I made a couple of tweaks and
tested the patch out on Linux just to make sure the
performace is still as good with compiler optimizations. 
For short numbers (numbers that would fit into an int),
long() is 10-30% *slower* than before applying the patch. 
For longer numbers, long() is up to 249% faster, with the
peak occurring around 1000 digits.

If the negative performance impact for int-sized digits is
unacceptable, I will see if I can do something about it. 
However, one always has the option of using int() on very
long strings anyway, and it will automatically fall through
to PyLong_FromString if the number is too long.  The
performance impact on int() for small numbers is so small as
to be negligible (<5%), which is to be expected since the
modified code isn't called when using int() on input strings
< 2**32. 

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1442927&group_id=5470