-----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-----