Re: [boost] New Boost.XInt Library, request preliminary review

Subject: Re: [boost] New Boost.XInt Library, request preliminary review
From: Chad Nelson (chad.thecomfychair_at_[hidden])
Date: 2010-03-27 20:56:25

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

> No offense, but I'm not confident that COW semantics for the integer
> class is a wise design choice.
> 
> I assume you have tested the performance with and without COW semantics,
> as well tested the performance for thread safe operations with and
> without COW semantics, before making that decision.

Yes to everything except for the "thread safe operations with and
without COW semantics." The only way to provide fully thread-safe
operation with copy-on-write enabled is by putting locking functions in
the xint::integer class itself. I experimented with that, but in the end
I decided that it just wasn't that class's place to do that sort of
thing. As such, copy-on-write is only used when the library is compiled
in single-thread mode.

> Care to disclose the numbers?

In single-thread mode, running my test suite presently takes an average
of 1.30 seconds. Still in single-thread mode, but with copy-on-write
disabled, it's 2.42 seconds. (For the sake of completeness, full
thread-safe mode also takes 2.42 seconds. The main difference is a mutex
protecting the random number generator as well.)

> I guess that you have read the COW string article
> (http://www.gotw.ca/gotw/045.htm) by Herb Sutter, and his conclusions.

Of course.

> Optimizations on other parts should perhaps have been made before
> converting to COW semantics.

There were, a large number of them. They were insufficient.

> Using COW semantics could also complicate the complexity requirements
> for most functions, as they may be "amortized O(something)" instead of
> just "O(something)".

Wouldn't you rather have "amortized O(something)" than just
"O(something)", when the first O is about half the value of the second? ;-)

> Another concern I have is that NaN is "signaling" as most operations on
> a NaN integer will throw an exception. I think it would be more sound if
> operations on NaN integers would result in NaN integers, compare with
> float NaN.

I actually implemented it that way first. But after long consideration,
I decided that a signaling NaN was better. With the non-signaling one,
you could go through hours of calculations, only to find that NaN
returned at the beginning of them rendered all that work useless.

> Don't take these comments the wrong way, I'm very glad to see
> development of an arbitrary precision integer boost licensed library.

And I appreciate your comments, and your politeness in delivering them.
- -- 
Chad Nelson
Oak Circle Software, Inc.
*
*
*
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkuuqTYACgkQp9x9jeZ9/wR4QQCglIIunbj56RuifAw6n8w6DkFi
FHwAn34554rZI70/kMaLOdCrRV/va9Ce
=bCzG
-----END PGP SIGNATURE-----