GMP 6 the incomatible GMP?
marc.glisse at inria.fr
Wed Jan 9 00:14:15 CET 2013
On Tue, 8 Jan 2013, David Miller wrote:
> From: Torbjorn Granlund <tg at gmplib.org>
> Date: Tue, 08 Jan 2013 12:50:01 +0100
>> 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.
>> I see some problems with that:
>> * There is a serial memory dependency problem, making the allocation
>> check at least one more cache latency away. I don't think OoO
>> execution will be able to hide that, as this is used.
My intuition would be that this won't matter, but you have more experience
than me with that.
> I don't know how amicable you are to an idea like this, but if user
> applications can only treat pointers to these objects as opaque then
> you can encode information in the lowest bits of the pointer.
> For example, you could encode in the lowest bit whether the _mp_d[-1]
> thing is being done or not.
> Then it's at worst a mis-predicted branch in the allocation check.
That seems similar (not saying one is better than the other) to what Niels
was proposing, where he was encoding it as a special value of the bitfield
_mp_alloc (so basically in a few bits of _mp_size) instead of _mp_d.
What is done by bignum libraries in many languages is that the base object
is a single pointer, and depending on the lowest (?) bit it is interpreted
either as a pointer to (alloc+)size+limb or as a small integer. But
again, their intended main use is with numbers that would fit in an int.
PS: thanks a lot for your sparc assembly work!
More information about the gmp-devel