Subject: Re: [boost] [xint] Fourth release, requesting preliminary review again
From: Chad Nelson (chad.thecomfychair_at_[hidden])
Date: 2010-06-10 15:04:03
-----BEGIN PGP SIGNED MESSAGE-----
On 06/10/2010 01:50 PM, DE wrote:
>> [...] 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.
> 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
If you're doing anything more than simple addition and subtraction, it
probably will be.
> 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,
> hash etc.)
I'm not sure I understand what you're saying there.
> but as i understood from the docs fixed_integer does not exercise
> modular arithmetic like built-in types do
The library's fixed-size integers act like unsigned ints, as far as
modular arithmetic goes. Except, of course, that they're signed as well.
That's why I took pains to describe their behavior thoroughly, it's not
entirely obvious from knowledge of the built-in types.
> at the same time there already is modular arithmetic implementation in
> the lib
> it confuses me
> what was your intention?
To provide a fixed-integer implementation, primarily because you
requested it. :-) The fixed-integer stuff that the library provides is
somewhat more flexible than just relying on the modular behavior of the
built-in types though, because you can specify a number of bits that
isn't necessarily an even multiple of a built-in type's size. For
example, it allows 56-bit, 112-bit, and 168-bit integers (the key sizes
for Triple-DES) on a 32- or 64-bit machine, even though none of those
sizes are a multiple of 32 or 64.
That said, the version I'm finishing up now *does* take advantage of the
built-in types' behavior when the number of bits is an even multiple of
the underlying type's size, to squeeze a little extra performance out of
it by eliminating unneeded instructions at compile-time.
(Since some people will complain about my example: yes, it's contrived.
You don't need a large-integer library for Triple-DES, and you could use
a larger value and simply cut it down to the required bits. I was just
trying to show one place where it might be useful to calculate something
with an unusual number of bits.)
Oak Circle Software, Inc.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
-----END PGP SIGNATURE-----
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk