Tim Peters wrote:
> Python assumes 2's comp in several places already.
Yeah, I just noticed that.
> I thought you were going to time this <wink>?
I am.
If you assume that, for the vast majority of multiplications, both
multiplicands are in the range -sqrt(sys.maxint):sqrt(sys.maxint),
the following gives a 15% performance improvement for me:
unsigned long sa = (a < 0L);
unsigned long sb = (b < 0L);
unsigned long ua = sa ? -a : a;
unsigned long ub = sb ? -b : b;
if ((ua | ub) & OVERFLOW_POSSIBLE_MASK)
{
<CURRENT IMPLEMENTATION, AS IS>
}
If both numbers are evenly distributed from -sys.maxint:sys.maxint,
this yields about a 3% slowdown, though. These numbers are just for
the core multiply path, since I pulled it out in order to compare
algorithms better.
I'm looking into improving the rest, but it's difficult.
-Jerry
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4