Slashdot Mirror
First-Gen Xbox 360 Games Single-Threaded?
Scott Gualco wrote to mention a report at The Inquirer indicating that, despite the 360 itself being capable of multi-threading, first generation 360 titles will be single-threaded. From the article: "Every new machine has a nasty first set of games as the programmers work up to speed on the hardware. In this case, the up side is that there is about 6x the CPU power available and coming to a console near you in the second generation of games. The scary part is that everyone tells me that the PS3 is harder to program for than the Xbox360, and the tools are nowhere near the quality of Microsoft's. That means that even with an extra six months of design time, the initial PS3 games may be worse." Commentary available at Joystiq.
AI, Music, player input, networking, "worldkeeping"... hell, even rendering is parallelizable.
Games are far more threadable than you think.
first generation 360 titles will be single-threaded ... the initial PS3 games may be worse
They'll be half-threaded?
If I have been able to see further than others, it is because I bought a pair of binoculars.
I'm suddenly reminded of that Anandtech article from a couple months back about how developers were:
1) Not enthusiastic about using multiple threads and
2) Very disappointed in both the 360's and the PS3's single-threaded CPU performance.
It was pulled pretty quickly, and the story is that the article was pulled to protect the anonymous source.
Threading only makes sense if one of three conditions is true- either it allows you to do complex calculations early, a condition needs rapid handling, or the task is truely massive but can be handled with low communication by multiple threads. Very few things in games follow one of these.
Music has no advantage to multithreading it. You decode it to wav and send it down to the OS to play (yes, there is an OS, even on a console these days). Its not even like the DOS era where you had to set up the DMA to interrupt you at the half buffer point to fill over the used data. Perhaps if the games were generating music this would make a difference, but they aren't- they just play pre-created files and add in a sound effect occassionally. You could uncompress on another thread, but thats not much of a gain, as levels/areas tend to just have 1 song you load upon loading the game/level/area.
Player input is so rare an occurence (remember, we're at machine speeds here) that it doesn't make sense to give it its own thread. We're talking about something that occurs 2-3 times a second, to a GHZ processor. You'd have a thread with nothing to process 99.9% of the time, and who's time to process is extremely low priority (rememver, a long time to a CPU is a fraction of a second).
Networking- maybe. Of course, networking really is just another type of IO, and after already dealing with a network latency, a few more ms to wait won't be noticable. So there's little advantage to it having its own thread. And the actual sending is interrupt driven by the OS, so you don't need a thread to handle writing.
Worldkeeping and AI do make sense for complex AIs. Allowing decision making to occur on the player's turn would increase AI ability, allbeit at a cost in complexity (you'd have to guess at what the players turn would do). Good for turn based strategies like Civ and RTW. Not commonly done, though. Even Civ4 didn't multithread their AI off from the rest, and if there's any game that requires computational power its Civ.
THe other problem is that all of these things are very tightly coupled- rendering, for example, requires input from networking, IO, AI, every time they make a decision. Music needs to know what AI is doing and what the player/network players are doing. Etc. Compare this to a multithreaded server or computer app, where threads basicly just take a request and go off, just telling the main thread when they're done. Games would require a lot more interprocess communication, and that makes multithreading hard. High cost, with very low returns.
Now client server games are another matter- I'm sure MMO servers have multiple threads going. But notice how different that use case is- multiple loosely coupled computations, vs few highly coupled ones. ANd no rendering thread that basicly needs to know everything at all times.
I still have more fans than freaks. WTF is wrong with you people?
This has been discussed on Evil Avatar for awhile now. It seems that for Oblivion at least, that statement isn't entirely true
Gavin Carter: The game's code takes advantage of the multithreaded nature of the Xbox 360 and multithreaded PCs to improve just about every aspect of the game. The primary function is to improve framerates by off-loading some work from the main thread to the other processors. We do a variety of tasks on other threads depending on the situation - be it sound and music, renderer tasks, physics calculations, or anything else that could benefit. Loading also gets spread across hardware threads to aid in load times and provide a more seamless experience for the player.
That's not to say that writing software for multiple cores is easy. It's actually extremely hard to synchronize the various tasks that run on the different cores. I suspect that most early games will run slowly on a single core or somewhat inefficiently on multiple cores. It will be quite some time before developers can figure out how to use all of them efficiently enough.
The developer's dream is a single processor console that has a very fast CPU. Unfortunately that's hard to manufacture, so they're stuck with something less than ideal that can be made cheaply with today's technology.
This seems like the easiest place to cut corners.
I guess I thought the place where most 360 (and Xbox) games cut corners, was, you know, gameplay. It's pretty easy to make a game with flashy graphics on hardware like this, and especially since your graphics programmers and artists are jizzing all over the place with their HD textures and such, but it's a lot harder to make a game that's actually good. I'm not saying this stuff won't sell, obviously it will (it's new and shiny, we love that), but the quality (and fun) will probably suffer until at least the 2nd generation of games.
When you look at the state of the world, how can you not become a radical, liberal anarchist?
Of course it's not true.
In case it's hard to work out, here's an alternative (and, I suspect, wholly correct explanation):
You've had real 360 dev kits for not very long - you've had to limp along with some half-way house that probably emulates many things until then. Your game is a launch title. This means it has a hard deadline. Either you launch when the Xbox launches, or you don't. This is a pretty binary state of affairs.
You're under intense time pressure. Most of the tools you're using are new/revised, and you have to create assets that are a different level of detail/effort than the previous games you've made, so you need to learn a lot of new tricks again. While you're updating the game engine itself, of course. Everything's changing.
Now, do you want to add to this volatile mix a bunch of multi-threading stuff for core game mechanics, with all the new code/mechanisms this will entail, and issues produced by multi-threaded access to game data, sync issues, race conditions, etc. and jeopardise the launch date of the game?
Or do you want to do the best you can in the time you have available?
I know which I'd choose.
(Aside: I see a lot of comments about audio, etc - of course multi-threading for stuff like audio playback is a no-brainer. Trust me, that's not the sort of thing that game devs are talking about when they say multi-threading games is hard. Conversely, multi-threading audio playback is not exactly a huge win anyway. The chipsets on these consoles do all the hard stuff - all the audio playback engine is doing is filling buffers and updating playback parameters. Exactly how long do you think that takes anyway?)
Ah, I see. Mr... Anonymous, is it? Thanks for the insight. And I guess you would know, since you've developed on every console in existence. Except dreamcast and xbox, and any before the past 10 years.
That's pretty funny, because there's this programmer out there named John Carmack who kinda disagrees with your views. Although, who the heck is that Carmack guy qnyway anyway? He's only written about a half-dozen 3D game engines from scratch and designs rockets in his spare time. He clearly doesn't have your level of expertise, what with your unknown work on these unspecified games at your unnamed employer.