[Python-Dev] Optionally using GMP to implement long if available

[Tim Peters]

[Gregory P. Smith]
>> One optimization that could be done to the existing Python longobject
>> code is to allow it to use larger digits.  Currently it is hardcoded
>> to use 15bit digits.
>>
>> The most common desktop+server CPUs in the world (x86) all support
>> efficient 32bit*32bit -> 64bit multiply so there is no good reason to
>> limit python itself to 15bit digits when on either x86 or x86_64.

[Martin v. Löwis]
> Perhaps Tim Peters should also comment here - but if you can come up
> with a patch that does that in a portable way, I would be in favor.
> The challenge, ISTM, is to make it still compile on all systems
> (regardless of how inefficient it might be on minor platforms).

Eh -- the strong points of Python's long implementation have always
been reliability and portability.  Both are greatly aided by sticking
to operations spellable in standard C89, and by avoiding
platform-specific trickery & #ifdef'ery.  So, no, I'm not keen on
this.  Note that while 32x32->64 multiply is supported by x86 HW, that
doesn't mean there's a uniform way to get at this HW capability across
C compilers.  In contrast, (at least) efficient HW 15x15->30 multiply
is universally spelled in C via "i*j" :-)

A similar gripe applies to schemes to replace the long implementation
by GMP (optionally or not):  it adds complexity to the code.  I like
GMP myself, but am happy using one of the Python GMP wrappers when I
/want/ GMP (as timings in other messages show, using GMP is a speed
loser before ints grow "really big").

Indeed, if I had it to do over again, I would balk even at adding
Karatsuba multiplication to Python (it added extra complexity with no
real payback, given that those who care about the speed of very long
int multiplication are far better off using a GMP wrapper anyway).

grouchily y'rs  - tim