_mp_alloc vs ALLOC

[Marc Glisse]

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

-- 
Marc Glisse