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