_mp_alloc vs ALLOC
bodrato at mail.dm.unipi.it
bodrato at mail.dm.unipi.it
Fri Jun 1 08:54:50 CEST 2012
Ciao,
Il Gio, 31 Maggio 2012 3:25 pm, Marc Glisse ha scritto:
> On Thu, 31 May 2012, Niels Möller wrote:
>> And then the question remains, are there systems and C libraries where
>> free + malloc is significantly slower than realloc in common cases?
>
> I am afraid so. Experiments are needed, but my intuition tells me that for
> small numbers (for large numbers, the cost of copying in realloc is anyway
> small compared to whatever operation you are doing), free+malloc will be
> significantly slower than realloc.
I renewed the question because I was looking into mpq. In almost all cases
(mpq_abs, mpq_get_den, mpq_get_num, mpq_inv, mpq_neg, mpq_set,
mpq_set_den, mpq_set_num, mpq_set_z) I touched, the "whatever" operation
is a copy, and we risk to spend almost half of the total time in the copy
implied by realloc.
Of course, those functions are not the most time-critical ones...
I know there are other arguments, we might discuss about a possible change
in the memory interface. The points I see:
- should we ask for a fourth function (alloc, free, conservative_realloc,
nonconservative_realloc)?
>> (Speaking of allocation, I also wonder what to do about the problem
>> described in
>> http://gmplib.org/list-archives/gmp-devel/2012-January/002161.html,
>> there were no replies at the time).
- should we keep the old_size parameter in the interface?
> Related: I was always unhappy about the order of the reallocation function
> arguments. malloc and free can be used by gmp (just ignore the old size
> passed as last argument) but realloc needs a wrapper.
- should we change the order of parameters?
Best regards,
Marco
--
http://bodrato.it/papers/
More information about the gmp-devel
mailing list