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