[gameprogrammer] Multithreaded humor and musings

What follows is a post over at ars technica: http://episteme.arstechnica.com/eve/ubb.x/a/tpc/f/174096756/m/453000214731/r/509007214731#509007214731

It is probably the most succinct and humorous way to describe multithreaded programming to the lay person that I've seen:

-------------------
The problem is not that it is a difficult transition, programmers are used to constantly transitioning to the next language/hardware/whatever that's the norm. The problem is that even once you have the concept and execution of multi-threaded development down pat, it still kicks you in the ass. Think of it like taking care of mischievous eight year olds ( threads). You know what it is that you have to do to keep them fed, clean, and out of trouble. If you are taking care of one, it's not hard to keep an eye on them and make sure they aren't doing anything they aren't supposed to. When you add another one though, it gets a lot harder to make sure that one or the other isn't off torturing the cat or climbing on the cabinets. Now, assume that you are actually trying to get three or more of them to do something constructive, like math homework (poor branch prediction, you have to micro manage them). You look down to help one with some addition, and one of the others goes off and pees in the cat food. You don't notice, because you are too busy dragging the third one back to the table, so then hours later when you smell something funny and the cat won't leave you alone, you find the defiled cat food, but you have no idea how it happened. THAT is what multi threaded programming is like. There are no "solutions" or "learning" it, it is a constant battle. Sure, some people are better at it than others, and you can get great performance out of it, but it is always a nightmare to debug. On the other hand, traditional single core chips with a large cache are more like a new intern fresh from college. They don't have much knowledge of how things actually work yet, so you do have to give explicit instructions, but you can pretty much just hand the instructions to them and know they will be followed without much problem. ... -Xavin at ars technica
-------------------

The impending release of the Xbox 360 and Playstation 3, both multicore consoles, the debate over multithreaded game programming is raging. Nice to see that the GP list was ahead of this game by oh, many months. But its amazing how many people just don't "get it" when it comes to concurrency. You'll find people who brush it off as, oh that's easy, or oh we've been doing multithreaded programming for years. The above example is a superb illustration that, while yes we understand concurrent programming, its still really difficult to get right.

I know we've gone over the various ways that one could implement high-concurrency game engines, but the Xbox 360 vs PS3 debate adds another dimension to the discussion: is it better to have symmetric multi-processing or asymmetric multi processing?

The 360 has 3 symmetric, general purpose Power cores. The PS3 has one general purpose Power core, plus 7 dsp-esque "synergistic processing units." All the Sony fans are going nuts over having so many cores, but I would still choose the 3 symmetric cores, and so it seems would many other developers, if this anandtech article has any credence: http://www.anandtech.com/video/showdoc.aspx?i=2453&p=3

With symmetric multi processing, you can distribute the load on game objects like we talked about before, or some other dataset. With asymmetric multi processing (Cell, PS3) I would think you would be relegated to the multithreaded library framework. I claim this because the distributed object model requires each object to be able to execute all functions required of it in the game world, and not just the specific sets of functions that perform well on the SPEs. So that model seems much better suited to general processing cores. Whereas a library is better suited to a more low level, fine tuning, style of programming that would work better with an asynchronous multiprocessing architecture.

Plus the asynchronous style doesn't seem very fun at all to program. Nor does it sound very clean.

Couple all this with the news that Sony will be selling the Playstation 3 at a substantial loss, per Gamespot: http://www.gamespot.com/news/2005/06/28/news_6128295.html . "Merrill Lynch Japan predicts Sony will lose more than $1 billion on hardware during its next-gen console's first year..." And you really start to get the feeling that Sony is betting the farm here.

And in a completely rational and sane world, I don't think Sony would ever have a chance to succeed. But we don't live in that world. Unfortunately, we live in a world run by marketing. But this is getting off topic. :P

All this talk about multithreaded game engines makes me start to want to attempt it, but I know I'd probably be pulling my hair out before very long.

brian.




---------------------
To unsubscribe go to http://gameprogrammer.com/mailinglist.html


Other related posts: