Python very slow on the Sharp Zaurus - any idea why?

[Tim Peters]

[Paul Rubin]
> Ouch!!  That doesn't sound so good for the Zaurus.
>
> Is the idea here to discover if a*b overflows 32 bits, if a and b are
> 32 bit ints?

The idea is to discover whether Python int * int overflows, which translates
to whether C long * long overflows a C long, regardless of its size.

> On compilers supporting 64-bit (long long) ints, it may be faster to
> use them instead of floating point for this check.

You're welcome to pursue it.  Note that on platforms where sizeof(long) == 8
(like 64-bit Linux, but not 64-bit Windows), sizeof(long long) is usually 8
too.

> I think that includes GCC and current Microsoft compilers among others.

Yes, although MS doesn't spell it "long long".

> It may even be ok to synthesize 32-bit multiplication from several
> 16-bit multiplications, to avoid these overflows.

A generalization (without the bogus 32-bit assumption) is what the 2.1 int
mult overflow-checking code tried to do.  It almost always worked; IIRC, it
raised a bogus OverflowError if the true product was exactly -sys.maxint-1.
It was also responsible for the infamous "LONG_BIT definition appears wrong
for platform" bug when building Python on an old Linux release that shipped
with a bad set of header files.

Note that it's faster to use a few float operations on a modern Pentium, and
that's overwhelmingly Python's most popular HW platform.