----- Original Message ----- From: "Nils Bruin" <nbr...@sfu.ca> To: "sage-devel" <sage-devel@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. --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
