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-02 11:29:38

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

On 05/02/2010 03:19 AM, Jeffrey Hellrung wrote:

>> Sorry for the tone of that, I wasn't implying anything wrong with 
>> yourself, just that this kind of result (multithreaded version
>> being slower) is usually because soemthing don't lend itself to be
>> multithreaded. Do you have this MT code somewhere still, i may have
>> a look if needed.
> 
> Chad, what Joel is referring to as "multithreaded" is really
> "thread-safe" in the context of your library, right?  I mean, not that
> Joel is using incorrect terminology on purpose, but maybe some terms and
> intents got confused during the discussion. 

Ah, okay. The confusion was probably my fault, I tend to call it "the
multithreaded version" when I should call it "the thread-safe version."

> You (Chad) don't actually implement any distributed arithmetic
> algorithms, right?

Right. A few functions, like the random_prime one, could make good use
of it, but it should be easy enough for the end-user to implement that
if he wants it.

> Why do you need to link to Boost.Thread for the thread-safe version? I'm
> under the impression the thread-safe version does not use COW, so
> read-access shouldn't need to be serialized, which puts it at the same
> level of "thread safety" as the STL containers.  I don't see where
> Boost.Thread fits into this.  Do you have static data shared among all
> xint::integer instances?

The only thing that I need Boost.Thread for is serializing access to the
random number generator -- I assume that most of the generators provided
by Boost.Random can't tolerate being used by multiple threads
simultaneously.

Boost.Thread is major overkill for that purpose, at least in my opinion,
but until Boost.Atomic or something similar is approved, it's the only
cross-platform way that I know of to safely serialize access without
writing my own code for the purpose.

> Regarding COW specifically:  I'm guessing COW will be a tough sell,

I keep hearing that, but why? It's an internal detail, one that provides
(or at least seems to) a very noticeable speed boost under some
circumstances, and is disabled when it can't be safely used. Why would
anyone, other than developers doing work on the library (i.e. me), care
one way or another that the library uses it?

> and I'm having a hard time swallowing that COW is 2x faster than
> (even emulated) move semantics. Is the performance difference
> strictly from differing numbers of copy operations? Can you identify
> (i.e., give an example of a real algorithm) where a move-enabled
> xint::integer produces more copies than a COW-enabled xint::integer?

Please see my reply from earlier this morning to Joel Falcou. I hadn't
thought about it extensively before, but I may be mistaken about most of
the source of the slowdown. I'll be testing that further today.
- -- 
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/

iEYEARECAAYFAkvdmmIACgkQp9x9jeZ9/wTt8gCgzbSshmgH0XrFjZpcuHU/4Dk5
3esAoI1vsa2PhvwPoJyz+vocUaeNN8Pu
=tUVz
-----END PGP SIGNATURE-----