[Python-3000] Python, int/long and GMP

[Adam Olsen]

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 {
> >       PyObject_HEAD
> >         mpz_t 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.

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

-- 
Adam Olsen, aka Rhamphoryncus