Re: Threads

[Pierre Phaneuf <pp@ludusdesign.com>]

Keith Lucas wrote:

> > correctly. When one thread touched some data that the other thread also
> > used, CPUs were constantly flushing caches (BAD!) and exchanging
> > coherency information (slows down the CPU). Net result: the threaded
> > version was SLOWER than the non-threaded version.
> 
> No, but then I'm not after /particularly/ a performance gain. And
> actually I'm not a coder really, I'm a systems architect who
> gets his hands dirty with C++ from time to time.

Yes, but I'm not talking about having a performance gain, I'm talking
about the threaded version being slower than the non-threaded version on
a dual CPU machine (quite non-intuitive, but this is reality).

If you would just gain nothing and get similar performance, you could
easily bear with this, and play along like if there was only one CPU,
but this *sucks*.

Maybe even that slow down is acceptable. Also, if you don't touch
(meaning *both* read or write) any memory pages that another thread is
also touching (note that I said *page*, which is to say a 4K block that
could contain any variable without your knowledge), you should be fine.

But think of this: how can you be SURE that variable you use all the
time is not put in the same page as that other variable the other thread
use all the time by malloc or the linker? Being *sure* requires really
fancy stuff like using a different malloc implementation that uses mmap
and uses separate memory pools for different threads. I think Hoard is
that way.

> {We have, for example, already decided to use STL, because the gain in
> developer time not spent doing our own versions of the things is worth
> the loss in performance associated with using generalised components
> rather than specialised ones.}

The runtime performance of STL is quite good by the way. It's more in
the compilation time that it is losing...

-- 
"I've run DOOM more in the last few days than I have the last few
months. I just love debugging ;-)" -- Linus Torvalds

---------------------------------------------------------------------
To unsubscribe, e-mail: linuxgames-unsubscribe@sunsite.auc.dk
For additional commands, e-mail: linuxgames-help@sunsite.auc.dk