On Tue, 8 Jan 2013, David Miller wrote:
From: Torbjorn Granlund <t...@gmplib.org>
Date: Tue, 08 Jan 2013 12:50:01 +0100
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.
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.
--
Marc Glisse
PS: thanks a lot for your sparc assembly work!
_______________________________________________
gmp-devel mailing list
gmp-devel@gmplib.org
http://gmplib.org/mailman/listinfo/gmp-devel
