[Python-3000] Python, int/long and GMP (original) (raw)

James Y Knight foom at fuhm.net
Fri Sep 28 09:53:28 CEST 2007

On Sep 27, 2007, at 10:29 PM, Victor Stinner wrote:

Hi,

I read some days ago a discussion about GMP (license). I wanted to know if GMP is really better than current Python int/long implementation. So I wrote a patch for python 3000 subversion (rev. 58277). I changed long type structure with: struct longobject { PyObjectHEAD mpzt number; };

So I can now say that GMP is much slower for Python pystone usage of integers. I use 32-bit CPU (Celeron M 420 at 1600 MHz on Ubuntu), so most integers are just one CPU word (and not a GMP complex structure).

GMP doesn't have a concept of a non-complex structure. It always
allocates memory. If you want to have a single CPU word integer, you
have to provide that outside of GMP. GMP's API is really designed for
allocating an integer object and reusing it for a number of
operations. You can generally get away with not doing that without
destroying performance, but certainly not on small integers.

Here's the init function, just for illustration: mpz_init (mpz_ptr x) { x->_mp_alloc = 1; x->_mp_d = (mp_ptr) (*__gmp_allocate_func) (BYTES_PER_MP_LIMB); x->_mp_size = 0; }

So replacing py3's integers with gmp as you did is not really fair.
If you're going to use GMP in an immutable integer scenario, you
really need to have a machine-word-int implementation as well.

So, if you want to actually give GMP a fair trial, I'd suggest trying
to integrate it with python 2.X, replacing longobject, leaving
intobject as is.

Also, removing python's caching of integers < 100 as you did in this
patch is surely a huge killer of performance.

James

More information about the Python-3000 mailing list