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-----
> 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.
> 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.
Oak Circle Software, Inc.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (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