On Mon, Jan 4, 2010 at 10:59 AM, Bill Hart <goodwillh...@googlemail.com> wrote: > Could you also place traces in memory.c in the default allocate and > reallocate functions, and in tal-reent.c in the default allocate > function to see where these allocations are actually being made. You > might also stick a trace in mpz/mul.c to see what is being allocated > there. > > I'd be interested in knowing where the allocation is actually being > made from and if it is temporary or a full allocation that is being > made. > > Thanks, > > Bill. If you want to see all the memory calls, you use one of the gmpy binaries from http://code.google.com/p/gmpy/ and enable debug mode just before the operation you want to monitor. It sends the debug info to stderr. (The only special action taken by gmpy is to round up small allocations to a 16 bytes.) > > 2010/1/4 Case Vanhorsen <cas...@gmail.com>: >> On Mon, Jan 4, 2010 at 10:38 AM, Bill Hart <goodwillh...@googlemail.com> >> wrote: >>> If it is the latter then here is the relevant code: >>> >>> wsize = usize + vsize; >>> >>> ..... >>> >>> if (wp == up || wp == vp) >>> { >>> free_me = wp; >>> free_me_size = w->_mp_alloc; >>> } >>> else >>> (*__gmp_free_func) (wp, w->_mp_alloc * BYTES_PER_MP_LIMB); >>> >>> w->_mp_alloc = wsize; >>> wp = (mp_ptr) (*__gmp_allocate_func) (wsize * BYTES_PER_MP_LIMB); >>> w->_mp_d = wp; >>> >>> Which shows that the only things that can go wrong are: >>> >>> 1) BYTES_PER_MP_LIMB is not 4 >>> >>> or >>> >>> 2) something is wrong with __gmp_allocate_func >>> >>> The latter is given by the following code: >>> >>> void * (*__gmp_allocate_func) _PROTO ((size_t)) = __gmp_default_allocate; >>> >>> void * >>> __gmp_default_allocate (size_t size) >>> { >>> void *ret; >>> #ifdef DEBUG >>> size_t req_size = size; >>> size += 2 * BYTES_PER_MP_LIMB; >>> #endif >>> ret = malloc (size); >>> if (ret == 0) >>> { >>> fprintf (stderr, "GNU MP: Cannot allocate memory (size=%u)\n", size); >>> abort (); >>> } >>> .... >>> >>> which is where your message is coming from. But malloc is clearly >>> being fed the right value. >>> >>> To check if the temporary allocation made by the FFT is correct is >>> slightly more work.... >>> >>> Bill. >>> >>> 2010/1/4 Bill Hart <goodwillh...@googlemail.com>: >>>> This would be using the FFT. And the FFT should in theory require 4 >>>> times the input bit size in order to do the squaring. So to multiply >>>> integers of 2^31 bits, it will request 2^30 bytes of memory. This is >>>> all assuming that the FFT is written to use memory fairly efficiently. >>>> This is in addition to the amount of memory required for the input and >>>> output, which will be a total of 2^31 bits plus 2^32 bits. That makes >>>> a total of just below 8 times the input size, or 2^31 bytes. >>>> >>>> It's possible to reduce the FFT memory usage a little below that in >>>> theory, but not much. >>>> >>>> Or are you saying that the number of bytes allocated in the actual >>>> output mpz_t is the amount given there? >>>> >>>> Bill. >>>> >>>> 2010/1/4 Cactus <rieman...@googlemail.com>: >>>>> >>>>> >>>>> On Jan 4, 2:43 pm, Bill Hart <goodwillh...@googlemail.com> wrote: >>>>>> uintptr_t is a c99 feature. So it "exists" on linux, but formally only >>>>>> in c99 mode. I'm not keen to switch MPIR to c99. But we can define >>>>>> something in mpir.h which on Windows in uintptr_t and on linux is the >>>>>> same size as an mp_limb_t or whatever (I think it is the case that an >>>>>> mp_limb_t should always be the same size as a pointer on the systems >>>>>> we care about). >>>>> >>>>> If I square numbers of increasin sizes, I get the output: >>>>> >>>>> 26 134217724 >>>>> 27 268435456 >>>>> 28 536870911 >>>>> 29 1073741821 >>>>> 30 2147483645 >>>>> GNU MP: Cannot allocate memory (size=4294837280) >>>>> >>>>> The number on the left is log2(number of bits in the input), the >>>>> number on the right being the number of bits in the result. >>>>> >>>>> As can be seen it fails for 2^31 input bits because memory for 2^32 >>>>> _bytes_ cannot be allocated. >>>>> >>>>> So it is asking for a lot more memory than its should need. >> IIRC, the prior calls for allocation where much smaller, I think by a >> factor of 8. I'll look at the log file when I'm home. The bug is that >> MPIR shouldn't be asking for that much memory in this case. Anyway, a >> full 64-bit implementation should be able to allocate 16GB of RAM for >> one mpz. >>>>> >>>>> mpz_mul asks for memory through the call: >>>>> >>>>> void *_mpz_realloc (mpz_ptr m, mp_size_t new_alloc) >>>>> >>>>> and mp_size_t is defined to be an int in gmp-impl.h: >>>>> >>>>> typedef long int mp_size_t; >>>>> >>>>> This is 32-bits on Windows so the realloc call will fail as soon as >>>>> 2^32 bytes are asked for. >>>>> >>>>> The define: >>>>> >>>>> typedef size_t mp_size_t; >>>>> >>>>> would seem to be better here. >>>>> >>>>> But this doesn't explain the excess memory request. >>>>> >>>>> Brian >>>>> >>>>> -- >>>>> >>>>> You received this message because you are subscribed to the Google Groups >>>>> "mpir-devel" group. >>>>> To post to this group, send email to mpir-de...@googlegroups.com. >>>>> To unsubscribe from this group, send email to >>>>> mpir-devel+unsubscr...@googlegroups.com. >>>>> For more options, visit this group at >>>>> http://groups.google.com/group/mpir-devel?hl=en. >>>>> >>>>> >>>>> >>>> >>> >>> -- >>> >>> You received this message because you are subscribed to the Google Groups >>> "mpir-devel" group. >>> To post to this group, send email to mpir-de...@googlegroups.com. >>> To unsubscribe from this group, send email to >>> mpir-devel+unsubscr...@googlegroups.com. >>> For more options, visit this group at >>> http://groups.google.com/group/mpir-devel?hl=en. >>> >>> >>> >> >> -- >> >> You received this message because you are subscribed to the Google Groups >> "mpir-devel" group. >> To post to this group, send email to mpir-de...@googlegroups.com. >> To unsubscribe from this group, send email to >> mpir-devel+unsubscr...@googlegroups.com. >> For more options, visit this group at >> http://groups.google.com/group/mpir-devel?hl=en. >> >> >> > > -- > > You received this message because you are subscribed to the Google Groups > "mpir-devel" group. > To post to this group, send email to mpir-de...@googlegroups.com. > To unsubscribe from this group, send email to > mpir-devel+unsubscr...@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/mpir-devel?hl=en. > > >
-- You received this message because you are subscribed to the Google Groups "mpir-devel" group. To post to this group, send email to mpir-de...@googlegroups.com. To unsubscribe from this group, send email to mpir-devel+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/mpir-devel?hl=en.
