On Tue, 8 Jan 2013, Niels Möller wrote:
Marc Glisse <marc.gli...@inria.fr> writes:
Then we might as well always put it in _mp_d[-1], no? IIRC that's what
mpfr does.
That will increase overhead (both allocation and processing, I think)
for small bignums, which may be undesirable. But I don't really know how
significant that is.
I am not sure about processing. The allocated size is hidden behind the
pointer, but you are already dereferencing that pointer anyway, and you
are saving on the bit manipulations to separate size from alloc. It does
indeed waste a bit of heap space (not sure that's significant), which can
also increase the processing in malloc/free.
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.
--
Marc Glisse
_______________________________________________
gmp-devel mailing list
gmp-devel@gmplib.org
http://gmplib.org/mailman/listinfo/gmp-devel
