On Thu, 27 Aug 2009, Nils Bruin wrote:

>
> 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.

You can use the mpn_* functions directly, which make explicit assumptions 
about buffer lengths. (Probably not worth the hassle though.)

- Robert

--~--~---------~--~----~------------~-------~--~----~
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to 
sage-devel-unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~----------~----~----~----~------~----~------~--~---

Reply via email to