Multi vs. Single

More power!

That's what I really want! I'm not talking about the kind of power in which I can dictate other peoples lives, but the kind of power that can do trillions of executions per second. Personally, I don't care if those trillions of executions per second come from one massively fine tuned single processor, or if they come from little tiny, but speedy processors. I say it makes no difference, and yet a big buzz in the games industry lately has been the multi-threading or single-threading debate.

Come on people, and grow out of the 90s. The day has come and we are quickly approaching a barrier with physical limits as to the speed of future single processor machines, so it makes sense to start designing machines with multiple "cores" in them. Each core, essentially, it's own little mini processor.

There's a design flaw with this. If you have multiple cores all writing to the same chunk of memory, things can get very screwed up, very quick. If you wait until all requests have gone through to access the data, that's stalling your thread running on the core, and essentially bringing your program to a halt if this happens to frequently.

So with the good comes the bad. I can see in the near future having 16 cores on one chip, each with it's own dedicated cache and memory manager, but unless a lot of software engineers start to rethink their design philosophy, the fastest program will only be as fast as the single processor sitting on the core.

That's not good.

So I ask you developers out there to stop whining, and start learning. There are many ways to multithread, and reading about them all and learning the differences, the advantages and setbacks, for many of the common techniques used, and even going so far as reading how other people have addressed the problem, will help out creating your next title. After all, we still have the PS3 to worry about.

So get with the times... multi-threading is the way to go!

-Ken Noland