Re: [boost] [xint] Fourth release, requesting preliminary review again

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-----
Hash: SHA1

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.)
- -- 
Chad Nelson
Oak Circle Software, Inc.
*
*
*
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkwRNyMACgkQp9x9jeZ9/wSdwwCdGbskHqLFeoZ9dpW2NeIB5jLi
ZzMAoMWGbfhiQtcberJIujrVH9JRbEaI
=EDY1
-----END PGP SIGNATURE-----