GMP 6 the incomatible GMP?

[Marc Glisse]

On Tue, 8 Jan 2013, Niels Möller wrote:

> Marc Glisse <marc.glisse at 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