GMP 6 the incomatible GMP?
rguenther at suse.de
Tue Jan 8 11:26:19 CET 2013
On Tue, 8 Jan 2013, Torbjorn Granlund wrote:
> nisse at lysator.liu.se (Niels M?ller) writes:
> Hmm. I guess one could go down to only 8 bits or so for the alloc field,
> and for larger allocations, store the number of allocated limbs at the
> head of the limb array (in the case limb size is not artificially small,
> it could be just _mp_d[-1]).
> That's another idea.
> Do you think 48 bits (or 47 bits absolute value) for _mp_size will be
> large enough for the foreseeable future (say, 10 years)?
> I think that will be sufficient for some hundred years, since any
> super-linear algorithm applied to an operand of 2^53 bits (2^47 64-bit
> limbs) would hardly ever terminate even with a multi-THz CPU.
> There are also other tweaks discussed for mpz_t, to allow initialization
> without allocation.
> Yep, we should do that too. I cannot recall the details, but I assume
> that this would not create an incompatibility?
Another idea is to embed limbs for small numbers into __mpz_struct itself
(I was playing with that idea to reduce the number of allocations done
by ISL used by GCC now). Sort of have a magic _mp_alloc number (zero?)
that tells GMP that everything after _mp_alloc are the actual limbs.
with suitable N (what's a suitable number of limbs to special-case,
given that limb-size is target dependent? One limb would be easiest
(just use the space of the _mp_d pointer), extra "half" limbs would be
ugly I suppose.
ISL has lots of arrays of __mpz_structs which seem to be often
copied around and the actual numbers are usually small (would fit
Doing this wouldn't create an incompatibility I think, but if you
re-org things anyway maybe there is a better opportunity to
Richard Biener <rguenther at suse.de>
SUSE / SUSE Labs
SUSE LINUX Products GmbH - Nuernberg - AG Nuernberg - HRB 16746
GF: Jeff Hawn, Jennifer Guild, Felix Imend
More information about the gmp-devel