Subject: Re: [boost] [xint] Fourth release, requesting preliminary review again
From: DE (satan66613_at_[hidden])
Date: 2010-06-10 13:50:33
on 10.06.2010 at 5:49
Chad Nelson wrote :
> A stack-based integer's magnitude would always have to be stored
> directly adjacent to the integer itself on the stack, or risk having one
> deallocated before the other. That means no sharing of memory (even
> temporarily) for integers with identical magnitudes, and no moving
> magnitudes around by pointer-swapping -- every time you copy an integer
> for any reason, you'd have to copy each and every byte of the magnitude
> along with it. Swapping two 512-bit integers, just as an example, would
> mean three copies of 64+ bytes each, rather than a simple pointer swap.
> I assume you wanted to use stack-based memory for speed, but due to the
> above, it would likely be slower than the equivalent heap-based integer.
> Especially with a good caching allocator.
> It would probably also require some modifications to the lower levels of
> the code, to disable all the pointer-swapping stuff that I've built in
> for speed. That makes it difficult to experiment with it at present.
> Once the library is finalized, we can play with it and see if we can
> find a way around that problem.
yes you are right
i can see the rationale behind this now
i guess the cost of allocation compared to cost of operations is
negligible so in fact stack version will not gain much
and it seems to me that i recalled the discussion about it
anyway i think that fixed integer is a valuable part of the lib
one more question arises is that many algorithms that use built-in
integer modular arithmetic can be generalized to larger ints (PRNG,
but as i understood from the docs fixed_integer does not exercise
modular arithmetic like built-in types do
at the same time there already is modular arithmetic implementation in
it confuses me
what was your intention?
-- Pavel P.S. if you notice a grammar mistake or weird phrasing in my message please point it out
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk