_mp_alloc vs ALLOC
marc.glisse at inria.fr
Wed Feb 22 21:20:23 CET 2012
On Wed, 22 Feb 2012, Torbjorn Granlund wrote:
> bodrato at mail.dm.unipi.it writes:
> Unrelated :-) We might define more macros like TMP_ALLOC_LIMBS_2 . I mean
> _3 and _4. So that they can be used to reduce the number of allocations.
> Do you agree? (I just touched mpz/gcdext.c, and _4 should be used there).
> I'd vote for killing TMP_ALLOC_LIMBS_2 rather than add TMP_ALLOC_LIMBS_N
> for some range of N.
> Please look at the generated code from TMP_ALLOC from any reasonable
> compiler. It is a sub from sp, the a copy from sp to the target
> variable. Cost: about 1 cycle.
That's for the alloca case. Without alloca, one call to malloc is better
than two (although that usually also means the numbers are big and any gmp
operation will dwarf allocation). Also, the threshold between alloca and
malloc is quite high, and with many separate allocations that all barely
fit below this threshold, the total amount of stack memory used can become
too large for some applications (lowering the threshold may be easier than
allocating things in groups though).
On Wed, 22 Feb 2012, Niels Möller wrote:
> Torbjorn Granlund <tg at gmplib.org> writes:
>> TMP_ALLOC_LIMBS_2 is clutter IMHO.
> Sure, it's pointless in a normal build.
> As I understand it, the reason for having TMP_ALLOC_LIMBS_2 is to make
> --enable-alloca=debug more effective, by getting some kind of red zone
> separating the two areas. Whether or not that's worth the clutter, I'm
> not sure.
Er, I guess you mean TMP_ALLOC_LIMBS_2 as opposed to a single call to
TMP_ALLOC_LIMBS manually split in two, not as opposed to 2 calls to
More information about the gmp-devel