On Tuesday 25 August 2009 22:07:26 Juanjo wrote: > On Aug 25, 9:59 pm, Jason Moxham <ja...@njkfrudils.plus.com> wrote: > > On Tuesday 25 August 2009 20:35:48 Juanjo wrote: > > > I think that the cheapest solution is the one you suggested: allocate > > > the bignums manually and hope that GMP does not reallocate them. This > > > can be easily done in ECL, because the actual bignum creation is > > > restricted to a few functions in src/c/big.d. In all calculations with > > > bignums the procedure is as follows: > > > 1* Identify bignum operands > > > 2* Create one or more intermediate operators as GMP integers with > > > some preallocated limbs. > > > 3* Perform the calculations using the intermediate operators. > > > 4* Create a bignum object from the intermediate value. > > > 5* Clear that intermediate operator. > > > Steps 2,3,5 would work even with Sage's allocator, just by ensuring > > > that step 5* uses mpz_clear (Right now we do not need it). Step 4* > > > would be the only one to change, manually allocating the memory that > > > GMP needs. > > > > GMP will still need to allocate memory for internal needs using its > > allocator, but it is freed again . If the destination operand has > > enough memory for the largest possible output +1 then this should be > > enough , although I dont know if we can guarantee it , or if we want to( > > ie if we guarantee it now , then we have to forever) > > I think you do not understand steps 4 and 5: we already KNOW the size > of the memory that we have to allocate using ECL's allocator.
I think you mean you allready know the size that is big enough to hold the answer , which is not the same as what GMP needs to allocate to calculate the answer. For example to multiply two ints of 2000 limbs and 3000limbs , the result may fit in 4999 limbs , but to allocate 4999 for the result is not enough, to allocate 5000 limbs may also be not enough , we do not guarantee that we wont use more than this . We will definitely use more memory , but this is internal , and I hope you dont need to know this. But , the algorithm may say 5000 limbs is the minimum so allocate 5120 limbs ( a rounder power of two ) to facilitate fast execution.I dont think we do do this at the moment , but I wouldn't want restrict it. For a quick fix , I believe it will work , but your relying on an undocumented, and not even specified feature that just happens to be true for the moment , ie like Y2K > We will > be simply copying an integer created by GMP to a location that is > private for ECL and that neither GMP nor ECL will manage -- it belongs > to the garbage collector. After creating ECL's copy, the integer > created with GMP can be cleared. As I said, allocation and > deallocation of intermediate values can be done using Sage's memory > manager, for ECL will guarantee that every integer which is created > will be destroyed as well. > > Juanjo > --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
