Re: Threads

[Keith Lucas <keith@fysh.org>]

>  - Threads only add overhead when used on a single processor machine
>  - On a multiple processor machine, threads have bad cache coherency
> problems

OK I'm not really aiming much at multi-processor machines.

And know about the overhead on a single CPU.

> | programming 'with threads' (ie.: with Linux threads that share
> | page tables) is fundamentally more error-prone that coding isolated
> | threads (ie. processes). This is why you see all those lazy Linux
> | programmers using processes (ie. isolated threads) - if there is no
> | need to share too much state, why go the error-prone path? Under
> | Linux processes scale just as fine on SMP as threads.

Hmm. 

> John Carmack tried using threads in Quake 3 to support multiple CPU
> systems, with one thread running the game, and the other spewing the
> OpenGL primitives (thus having the OpenGL driver chew up time on the
> other CPU). More than one thread per CPU turned out to be too much
> overhead, and it took a LOT of work to make the two-thread version work
> 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.
> 
> With a lot of work, he finally managed to squeeze an improvement out of
> this, but not as much as he thought at the beginning. Do you think you
> are a better coder than Carmack? ;-)

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.

Obviously performance is nice, but the game design we have can be
implemented just fine without push any envelopes. What I'm looking at
is whether it'll be easier to develop the thing as a multi-threaded
app: our boundary condition is developer time, not performance.

{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.}

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