speed of mpz_odd_p and lazy allocation

[Torbjorn Granlund]

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[0] 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?

-- 
Torbjörn