[Python-Dev] Optionally using GMP to implement long if available (original) (raw)

Tim Peters tim.peters at gmail.com
Tue Nov 4 03:37:28 CET 2008

[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 x8664.

[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

More information about the Python-Dev mailing list