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

Adam Olsen rhamph at gmail.com
Fri Sep 28 18:44:43 CEST 2007

On 9/28/07, James Y Knight <foom at fuhm.net> wrote:

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: mpzinit (mpzptr x) { x->mpalloc = 1; _x->mpd = (mpptr) (*gmpallocatefunc) (BYTESPERMPLIMB); x->mpsize = 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.

I can vouch for that. Allocation can easily dominate performance. It invalidates the rest of the benchmark.

-- Adam Olsen, aka Rhamphoryncus

More information about the Python-3000 mailing list