On 17/11/2010 06:36 PM, Warp wrote:

>    Actually a surprisingly large number of GUI applications are multithreaded,
> by necessity.

I wish *more* GUI applications were multithreaded. :-S

(For example, closing the CD tray is enough to lock up almost the entire 
Windows Explorer shell until the OS can determine whether there is a CD 
in the drive. Similarly, accidentally clicking on drive A: will do more 
or less the same thing. WTF, people?!)

>    One industry where multithreading has been all the rage in later years
> is the gaming industry.

Really? I haven't been paying attention especially closely. Last time I 
looked, the advice was "don't ever buy a multi-core CPU for a gaming 
machine because no games support it yet". Has that finally changed now?

>    The problem of multithreading in a game engine is quite a difficult one.

The magic problem I found was that when I play games on a dual-core 
system, the game speeds up. As in, like, you can now run 7x faster 
(which is great), and the enemies can shoot back at you 7x faster. And 
the graphics flicker. And the sound gets out of sync. And basically it's 
impossible to play. Setting the task affinity to pin the game to one 
core fixes the problem. (I gather it's to do with the real-time clock 
being per-core or something like that...)

> One of the major problems is that a typical game engine needs to perform
> hundreds and hundreds of small tasks on each frame, and distributing these
> tasks to multiple processors efficiently is hard.

Presumably it's hard to balance work evenly. Then there's the problem of 
cache coherence if you try to do too much balancing. (I.e., if the data 
you want is in the cache on core X, trying to process that data from 
core Y is *slower* than not using an extra thread.)

> Just the mutual exclusion
> problem is hard because it needs to be as efficient as possible.

I guess the solution is to avoid the need for mutual exclusion to the 
maximum extent possible. Even if you can make it efficient, by 
definition it reduces the amount of stuff that can happen at once.

> You usually need very specialized lock-free algorithms and
> containers

Using lock-free systems is one good way of avoiding the problem, yes.

> and high-level languages often make developing them difficult.

I can't say. I haven't tried. It's one of those things that I'd like to 
read about someday though. I have no idea how these algorithms work, and 
it sounds interesting.

Post a reply to this message