Fwd: Using MPIR or GMP with multiple memory managers
Jason Moxham
---------- Forwarded Message ----------
Subject: Fwd: Using MPIR or GMP with multiple memory managers
Date: Friday 04 Sep 2009
From: jason <ja...@njkfrudils.plus.com>
To: ja...@njkfrudils.plus.com
---------- Forwarded message ----------
From: "Jason Moxham" <ja...@njkfrudils.plus.com>
Date: Aug 27, 8:39 pm
Subject: Using MPIR or GMP with multiple memory managers
To: sage-devel
----- Original Message -----
From: "Nils Bruin" <nbr...@sfu.ca>
To: "sage-devel" <sage-...@googlegroups.com>
Sent: Thursday, August 27, 2009 5:07 PM
Subject: [sage-devel] Re: Using MPIR or GMP with multiple memory
managers
On Aug 27, 3:46 am, Jason Moxham <ja...@njkfrudils.plus.com> wrote:
> the source arguments to the mpz_* functions are const pointers so the
> memory
> they point to will not change (thru that pointer) , ie as long as c does
> not
> alias a or b then GMP will not change a or b . The above code will work.
Excellent. So that gives one safe approach with a small memcpy
penalty.
> Logic is two-compliment on a stored sign-magnitude representation so the
> above
> does not hold. The chance that GMP wants more than above for say mpz_add
> is
> not zero , consider SSE or the new AVX extenstions if these become a big
> benefit , then we may round up to next largest 16bytes or whatever.I have
> one
> case where I may want to do this sort of round up , but I probably wont
> get
> around to trying it out for about a year. MPIR is optimized for the
> "common
> case" and I am hoping that this weird situation where we want to use two
> memory mangers is a one off.
OK. Understandable. I don't think anybody would want MPIR to slow down
in order to satisfy certain exotic API demands. Once we have this
under way, I may just try if preallocating enough space to avoid the
temp speeds things up.
If it's noticeable, perhaps it's an idea to export the way in which
mpz_add, mpz_sub (and perhaps a few other common routines) compute the
required number of limbs for their result as a macro? Preallocating
sufficient limbs probably can lead to speed-ups regardless of which
memory manager is used. In cases where it's complicated, one could
just leave it out.
We allready do this with some internal stuff eg toom3 mul , so this
would no
problem to do.
so for example for mpz_add(z,x,y) , mpir would define
MPIR_MPZ_ADD_MAX_MEM_ALLOC(x,y) which be an expression that as long as
you
have allocated at least that much memory then no rellocation will take
place
, and if the macro is not defined(the default) you would have to fall
back
to a slower copy.
-------------------------------------------------------
This is the end of a long thread.
This sounds like a good idea and an easy one to implement. So for example for
mpz_add we would define
#define MPZ_ADD_MIN_ALLOC(x,y) (MAX(ABSIZ(x),ABSIZ(y))+1)
if thats the correct expression
This being used so that if the destination varible has at least this many
limbs allocated then no reallocation of the destination varible will take
place.
Do you concur and if so what should we call it?
Jason
Bill Hart
Jason Moxham
the obsoleted mpz_array_init , and even here it uses the phrase "if in
doubt" , the implication being it may change in the future. I agree it not
that likely to change , but rather than guarantee it , its just as easy to
stick in this macro , and we still have the option of changing allocation
requirements later and not breaking any compatibility.
Jason Moxham
this is for mpz_add(x,y,z)
#define __GMP_MPZ_ADD_MIN_ALLOC(x,y,z)
(__GMP_MAX(__GMP_ABS(y->_mp_size),__GMP_ABS(z->_mp_size))+1)
Nils, what are the functions most likely to benefit from defining these
macros?
Thanks
Jason