mpz_t caching

Vincent Lefevre vincent at vinc17.net
Mon Sep 7 10:54:11 UTC 2015


On 2015-09-07 12:36:51 +0200, Niels Möller wrote:
> Vincent Lefevre <vincent at vinc17.net> writes:
> 
> > I suspect that the cause
> > of the difference is that with mpz_t caching, the mpz_t's are
> > preallocated with a size that is large enough to avoid internal
> > reallocations in GMP (thus memory copies), but in such a case, the
> > right solution would be to use mpz_init2.
> 
> The lazy initialization discussed a few days ago might also help a bit,
> then limb storage isn't allocated until the first assignment to the
> variable, and then reallocations should be less likely.

Doesn't this save only the first allocation? Like mpz_init, I don't
think that this should be visible. The only possible cause I'm
thinking of, would be a succession of reallocations in a loop
because the mpz_t's are growing.

-- 
Vincent Lefèvre <vincent at vinc17.net> - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)


More information about the gmp-devel mailing list