|
![](/i/fill.gif) |
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
|
![](/i/fill.gif) |