Re: [boost] [xint] Third release is ready, requesting preliminary review

Subject: Re: [boost] [xint] Third release is ready, requesting preliminary review
From: Chad Nelson (chad.thecomfychair_at_[hidden])
Date: 2010-05-03 13:40:13

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

On 05/03/2010 12:46 PM, Stewart, Robert wrote:

>> Not exactly useless -- I *do* know enough to avoid things that are 
>> completely useless. :-) The purpose was to initialize them to the
>> value of another integer, such as a parameter, before going into a
>> loop that modifies them based on their current values. With
>> copy-on-write, the initial allocation can be skipped, which
>> (depending on the number of times it needs to loop) can be a
>> significant savings.
>
> You say you copy an instance and then mutate it.  Guess what!  The
> copy involves manipulating the reference count and the mutating
> operations must all check whether the instance is unique.  The first
> mutating operation actually makes a unique copy and the rest just
> check superfluously. 

The first operation *may* make a unique copy, if the operation results
in a change to the number. There's no guarantee that it will.

For example, in earlier versions of the library (when the divide
function wasn't split up the way it is now), I needed to do a
calculation to see whether the divisor and dividend needed to be
normalized. If they did (about half the time), they had to be mutated;
if they didn't, they kept their original values. With copy-on-write, it
was simple to make mutable copies of them, and only actually mutate them
(and pay the price for it) when it was needed.

> Thus, in the cited example, since there will be a mutated copy, COW
> pessimizes the code.  In single threaded code, the overhead is small,
> assuming good branch prediction in the processor, but it isn't zero.
> (When used in MT code, of course, the overhead is worse.)

When used in MT code, the library doesn't use copy-on-write, so that's
not a problem.

> My point is your example in no way justifies COW.  Provide another
> real use case from your library that isn't served by move semantics,
> and you'll have convinced folks that COW is appropriate.

I already have: it's quite a bit faster. :-) Though as I said, I may
have identify something that's slowing down the move stuff. I'll post
more information when I have it. I'll be happy to remove copy-on-write
if I can make the library as fast with move semantics.
- -- 
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/

iEYEARECAAYFAkvfCn0ACgkQp9x9jeZ9/wR6jgCfa8qyIUZhUU7jO4hrDgT9U8Ms
UkAAoIsqbBUrcWOGnKQ5uyK6mZW0RRZx
=UOqu
-----END PGP SIGNATURE-----