speed of mpz_odd_p and lazy allocation
nisse at lysator.liu.se
Wed Aug 15 00:15:24 CEST 2012
bodrato at mail.dm.unipi.it writes:
> There are places in the code where mp_d is written disregard of
> previous value of size and alloc... (E.g. try $ grep -C2 "PTR *(.)\[0\]
> *=" mpz/*.c )
Pointing to a const limb won't help there, of course. Common scratch
limb (as suggested by Torbjörn) might work.
> Do you mean a sort of realloc-on-write? To protect read-only values?
A was thinking of abort on write, rather. I have seen two use cases that
call for changes to these conventions:
1. Initialization of objects containing mpz_t fields with a single
memcpy from a template object. Currently, one must also call mpz_init
for each mpz_t. I imagine Marc's use cases are something similar.
2. Compile time constants. I'd like a way to define compile time
constant bignums, without using gmp internals.
One could solve (1) by saying that alloc = 0, size = 0 means that
storage should be allcoated at write. _mp_d could point to a scratch
limb, if we want to keep _mp_d writable at all times. And solva part
of (2) by sating that alloc = 0, size != 0 means storage allocated by
the application, and the mpz_t should be treated as read-only by gmp.
Without thinking deeply about it, I think needed handling of alloc = 0
could be done in the unlikely branch of MPZ_REALLOC.
Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26.
Internet email is subject to wholesale government surveillance.
More information about the gmp-devel