nisse at lysator.liu.se
Fri Sep 4 08:24:31 UTC 2015
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).
Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26.
Internet email is subject to wholesale government surveillance.
More information about the gmp-devel