speed of mpz_odd_p and lazy allocation
tg at gmplib.org
Tue Aug 21 10:31:32 CEST 2012
nisse at lysator.liu.se (Niels Möller) writes:
To me, it would make sense to let mpz_init not allocate storage, but
point to a shared limb, possibly read-only, and set _mp_alloc to zero.
But I haven't reviewed the code to see where _mp_d is written without
checking _mp_alloc. So I don't know if an extra branch in those places,
to support lazy allocation, matters for performance.
We should study the feasbility of avoiding limb allocation at mpz_init
time (and the other GMP init functions).
For readers, we should almost surely play some tricks with pointing the
mp_d field somewhere safe. We might nevertheless check how many places
make dummy reads.
As Marc points out, some functions will write one-limb results without
checking the alloc field. That was a design decision by me when writing
the original library. An example would be mpz_set_ui.
We need to find places that would need an MPZ_REALLOC.
And we will need to change MPZ_REALLOC (the macro or a functions it
calls) to either allocate or reallocate.
How much editing will be needed? What performance impacts are expected?
More information about the gmp-devel