_mp_alloc vs ALLOC
tg at gmplib.org
Fri Feb 24 11:32:37 CET 2012
bodrato at mail.dm.unipi.it writes:
Il Ven, 24 Febbraio 2012 10:40 am, Torbjorn Granlund ha scritto:
> I cannot see how TMP_ALLOC_LIMBS_2 could save *anything* for small
I'm not sure I agree with Torbjorn. Nevertheless developers time is a far
more precious resource than a few cpu cycles or bytes of code size...
That's why I completely change my question, always about allocations.
I always used the MPZ_REALLOC macro, to enlarge (if needed) the memory
area available for an integer. This macro gives a (possibly new) pointer
with the requested size available... but it also copies the content.
Sometimes I know in advance that the content can be discarded. Is there a
standard way to ensure a given size without moving data?
I use this trick for that:
rp = realloc (rp, 1);
rp = realloc (rp, newsize);
I suspect there is a lot to win from using such a trick, at least of the
old size was large. But perhaps some malloc implementations are so slow
for finding a 1-byte block that it can also become slower? (It is a
pity the C library provide only very primitive allocation functions.)
I am not sure how to deal with this in GMP. We could add a flag field
in MPZ_REALLOC, or have special functions+macros.
Unfortunatly, we are somewhat constrained by the replaceable allocation
functions; changing the __gmp_reallocate_func type will break
compatibility with user code. We will therefore need to make two
realloc calls by invoking the fairly high-level __gmp_reallocate_func
twice. Oh well.
More information about the gmp-devel