mpz_t caching

[Niels Möller]

Vincent Lefevre <vincent at vinc17.net> writes:

> In 2014, Patrick Pelissier (in Cc) implemented a mpz_t allocation
> cache for MPFR, redefining mpz_init and mpz_clear, in order to
> avoid some deallocations/allocations (via the indirect call to
> the allocation functions) when mpz_t's cleared and init'ed again
> a bit after. I've attached the patch that was applied to MPFR.

I take it this was done to improve performance? Do you have any
information on what applications benefitted, and some numbers for
typical performance improvement?

If I understand the patch correctly, the idea is essentially to keep
your own free-list for the limb storage pointed to by _mp_d? If you beat
libc's malloc, and by how much, is going to be quite system dependent.

> Note: A drawback is that it may be necessary to free the caches at
> the end of the program so that tools like valgrind don't complain.

And there are also thread-safety issues; currently GMP leaves all such
problems to the provided allocation function, while a cache would need
some thread-local storage (or locks, but I guess that's highly
undesirable if the idea is to gain performance).

Regards,
/Niels

-- 
Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26.
Internet email is subject to wholesale government surveillance.