On 5/1/2010 11:44 PM, joel falcou wrote:
If you're saying that people often write multithreaded programs, then I have to disagree. In my experience, it's rare, and most programmers actively avoid them. Plural of anedocte is not data. In genral, not taking multithreading seriously now is likely to be a
Chad Nelson wrote: problem in the upcoming years.
Then it means you did somethign wrong or the code doesn't lend itself to trivial multithreading ... 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. You (Chad) don't actually implement any distributed arithmetic algorithms, right? 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? Regarding COW specifically: I'm guessing COW will be a tough sell, 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? - Jeff