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

Mark Dickinson dickinsm at gmail.com
Tue Nov 4 12:00:11 CET 2008


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

I've just uploaded a patch to the issue tracker that allows Python
to use 30-bit digits on platforms having a 64-bit integer type:

http://bugs.python.org/issue4258

[Tim Peters]
> 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" :-)

If we're talking about standards and portability, doesn't "i*j" fail
on those (nonexistent?) platforms where the 'int' type is only 16-bits?
Shouldn't this be something like "(long)i * j" instead?

And for 32x32 -> 64, can't this simply be replaced by "(uint64_t)i * j",
where uint64_t is as in C99?  I'd hope that most compilers would
manage to turn this into the appropriate 32x32-bit hardware multiply.

I agree that very-long-integer optimizations probably don't really belong in
Python, but this patch should also provide significant benefits for short
and medium-sized integers.  I guess I need to go away and do some
benchmarking...

Mark


More information about the Python-Dev mailing list