Re: Threads

[Pierre Phaneuf <pp@ludusdesign.com>]

Tomas Andrle wrote:

> > IMHO, just avoid them. ;-)
> >
> > Really, do you actually *need* them?
> 
> I recommend you reading what John Carmack said about threads. It was nothing
> that would make you run away from them but basically he says:
> -
> Unless you have 2 CPUs (or to be more exact: 1 thread per cpu), using
> threads slows the game down (cache hierarchy gets broken (does anyone know
> what JC means by hierarchy?)). Q3A got sped up by using threads _on
> a multiprocessor system_ by 80% (or more, I don't remember but it's a lot
> anyway).

That's exact. Because of course a single process cannot split its work
across two or more CPU, you have to use kernel threads to use a number
of CPU over 1. But...

> Note that it was the actual rendering stuff which has been split into
> threads - not the sound output / input / networking etc.

.... I remember him saying to avoid threads as a mean to "have it easy",
like the sound/input/network example you gave.

Kernel threads (according to Carmack (and I support this claim!)) should
only be used in the case where you actually what to use more than one
CPU.

As a rule, you should try to have only one runnable process per CPU. So
if you have four CPU, you can have four threads. And they should be used
to split up *work*, not processing sound and sleeping all the time. If
you can't do that, you're better off leaving the other CPU for the OS
and its daemon and juste grab all that you can of the first CPU.

And splitting real work like scene rendering is stuff for the people
that really know what they're doing, let me tell you! The first approach
of Carmack to using both CPUs in a dual CPU system was horrible, leading
to severe performance degradation compared to the non-threaded version!

If the master couldn't do it on the first time, it *sure* isn't as easy
as it would look! The performance issue was with reading and writing too
much data from one CPU to the memory to another CPU, that lead to a lot
of traffic between the CPUs related to cache coherency.

That's quite wizard level stuff that I'm not sure I would have found out
myself (if it wasn't for Carmack's explanation) and I must note that my
day job is being a systems analyst for HNSX Supercomputers (a subsidiary
of NEC) for one of the largest supercomputing site in North America (USA
and Canada combined). We have spot number 29 on the top500.org list.

I'm supposed to know. ;-)

> A sound thread can make things easier to program but there should be
> something like a delay between the sound updates (checking if data can be
> written to /dev/dsp and checking for any sound events) or something similar
> to 'pthread_yield()' - that's obvious.

I don't understand this part completely... A delay? Why? What do you
exactly mean by sound updates and sound events? pthread_yield() doesn't
even exist (anymore), BTW... And it was of use mostly with older
non-preemptive implementations of pthreads (like PCthreads).

-- 
Pierre Phaneuf
Ludus Design, http://ludusdesign.com/
"First they ignore you. Then they laugh at you.
Then they fight you. Then you win." -- Gandhi