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.

Re:Surely this isn't true

[Anonymous Coward]

I wouldn't be surprised if it were true; first generation games do not have the luxury of time or access to working, complete, hardware. What you're given is performance estimates which are garbage (with the exception of the Gamecube and Dreamcast in the last generation), 'similar' (ie very different) hardware, and an exec who thinks it is possible to produce a game that is '10 times beter than half life 2 in 18 months (with 10% the budget).'

How do they do it then?

You licence existing technology (Unreal Engine,Doom Engine, etc.) which for the most part have focused on a single threaded environment, and create content that runs at a 'acceptable' rate on the crappy hardware you've been provided (ie. 20-30 FPS) and hope that the real harware will provide better performance.

Re:Cutting edge stuff!

[Yocto Yotta]

You should of hyperlinked the word "new" to a site that talks about how long multi-threading has been around. That actually would have done the trick quite well. Your welcome. =)

Re:'everyone' tells you, do they?

[Rayonic]

I wasn't aware that everyone had PS3 development kits.

Don't act silly, he clearly means 'everyone who has a PS3 dev kit'.

You're right that the dev kits are still beta, but you have to realise that the launch titles are being developed right now.

Re:Surely this isn't true

[AuMatar]

Its what the threads are doing that makes it complicated. I would bet your 800 thread app there is doing request based threading- the threads each handle one type of request, requests are parallel, and requests only need to talk to the requestee at 2 times- at the begining and end of a request. That type of multithreading is trivial.

Games don't have that luxury. Every subsystem needs to share data with every other subsystem. High degrees of coupling means high degrees of communication. They're also going to be updating the same objects (both for efficiency and due to that high degree of coupling). This is a locking nightmares.

On a side note- the locking mechanism in Java is poor. Firstly, it defies the most important concept in multi-threading- lock the data, not the code. Java locks code, via the synchronized command. But what you really want to do is lock the data- keep only 1 person accessing a given piece of data at a time. Doing this by functions requires a lot more code to be locked than need be, and confuses what is actually being protected (thus increasing the likelyhood that bugs will come when you add new methods or change what internal data existing methods touch). Secondly, it has no real locking on a scope less than function. Thirdly, its not possible (unless its changed since last I touched Java, which has been a few years) to say, lock method A and B of a class with one lock and C with another. Or use the same lock on 2 instances of a class. THis is easily doable with semaphore(s). Not allowing this requires a lot more locks, which lowers efficiency even more.