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.
James
_______________________________________________
Python-3000 mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-3000
Unsubscribe:
http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
