GMP 6 the incomatible GMP?
tg at gmplib.org
Wed Jan 9 11:10:33 CET 2013
Marc Glisse <marc.glisse at inria.fr> writes:
Experimentally (for me, others can have wildly different use cases),
what really helps for small nums isn't to save space, it is to not
allocate at all, for instance storing a few limbs in the base type and
only allocating when that's not enough (recycling storage can work
even better, but is for very specific uses and may not make sense for
a generic library). There are plans to add a bignum type to the C++
standard, and people are discussing whether it should be part of the
specification that constructing small numbers (not even just 0)
doesn't use dynamic allocation. Now the target users of this bignum
type and GMP are not exactly the same (bignum would be used a lot by
people who only need int but want to be safe), so it makes sense if
the best solutions differ.
I am sure this is often a god idea, perhaps it would be good also in
My main reason for not originally doing it like that is code complexity.
Having three operands (thing mpz_add) each with two possible
representations, will give some alternative execution paths.
Another problem is mpz_t size. It is currently 16 bytes on 64-bit
machines (and 12 bytes on on 32-bit machines). Even if only one bit of
these bytes are used for typing, we ain't getting much headroom from the
remaining 127 and 95 bits, respectively. Making the structures larger
is to costly.
More information about the gmp-devel