The Quest for More Processing Power, Part Two: "Multi-core and multi-threaded gaming"
by Johan De Gelas on March 14, 2005 12:05 AM EST- Posted in
- CPUs
Threads & Gaming
Tim gave us some extremely interesting information. Yes, the extra computing power of multi-cores is welcome in the gaming industry. Better game physics, animation and intensive and accurate sound effects are made possible with more than one core.
The tools, which Intel advertises in almost any multi-core presentation, are next to useless for the problems that the developers face, as Tim explained. Auto parallelisation is a nice trick to increase the spec FP score, but it is next to useless for a real world application. The good news for Intel, AMD and others is that the CPU will play a much more important role again. Physics, Artificial Intelligence and animation can be improved significantly by being parallelised and using the extra capabilities in dual core CPUs. But there are limits to Thread Level Parallelism. While increased ILP (Instruction Level Parallelism, IPC) might require exponentional increasing efforts of the manufacturer, using more and more threads, or increased TLP (Thread Level Parallelism), requires exponentional efforts from the developers. Tim clearly emphasizes that only parts of the application can be economically parallelized. Increasing parallelisation, using more threads, is simply not feasible. There is a pretty hard economic limit to TLP.
Tim Sweeney resumes:
"You can expect games to take advantage of multi-core pretty thoroughly in late 2006 as games and engines also targeting next-generation consoles start making their way onto the PC.
Writing multithreaded software is very hard; it's about as unnatural to support multithreading in C++ as it was to write object-oriented software in assembly language. The whole industry is starting to do it now, but it's pretty clear that a new programming model is needed if we're going to scale to ever more parallel architectures. I have been doing a lot of R&D along these lines, but it's going slowly."
Facebook
Twitter
RSS
49 Comments
View All Comments
Pjotr - Monday, March 14, 2005 - link
"dual-cored GPUs are stupid. given the parallel nature of graphics, it makes more sense to just add another pipeline at very little design cost."Unless you hit a power and/or heat output wall.
Tell nVidia that parallell GPUs are bad, they alreay sell their SLI solution for dual-GPU computers.
silverwolf - Monday, March 14, 2005 - link
PPU, is the way to go.defter - Monday, March 14, 2005 - link
"Given the immense complexity involved, I expect dual cores taking a VERY VERY long time to catch on... even then it'll be a half assed job."Well ALL future consoles will use multi core CPUs. Thus if developers want to sell games, their games must take advantage of at least two cores :)
ceefka - Monday, March 14, 2005 - link
#12 That's how it looks, for now. "No one will ever need more than 8 cores." :-DMy dumb question, I was reading:
"Tim clearly emphasizes that only parts of the application can be economically parallelized. Increasing parallelisation, using more threads, is simply not feasible. There is a pretty hard economic limit to TLP."
Isn't a high IPC-count also a form of parallelism? If so, then beyond a certain count won't it be just as hard to take advantage of a high IPC-count.
sandorski - Monday, March 14, 2005 - link
Good article. Most of it was over my head, but the gist was most important. That being that Multicore is a big question mark for Gamers and other common users.I've always preferred Sweeney over others in the industry, he knows what he's doing without getting in everybody elses face about it. I also found it appropriate that he was interviewed on the subject since Unreal Engines have always internally manged 100's of Processes in order to work(I assume other Engines do the same, but my knowledge of hte Unreal Engines is more thorough than them).If anyone can figure out how to use Multicore in gaming my money's on Sweeney.
Calin - Monday, March 14, 2005 - link
Auto-parallelization is of limited use, and it can work only on small pieces of code. You might get a couple of percent extra speed, but no more (or no much more). Managing multi-threaded code interdependent code would be a nightmare.However, some "extra" speed can be recovered in case of multi processors (or multi core) from the reduced state (thread) change. Certainly not extra 24%, but more than a bit.
FDSatyr - Monday, March 14, 2005 - link
Good read - mainly for Tim's comments though! I really enjoy the way Tim isn't arrogant at all in the way he talks. Some fairly silly questions from A though! I still think threads are rubbish, that processes and better schedulers are the way forward. I think the next step - realistically impossible in the industry it may be - would be to create a fresh architecture, and put an x86/87 core on the same die. Ho-hum.mkruer - Monday, March 14, 2005 - link
My magic eightball says that after 4-8 cores, any other core that will be added will be near worthless.AnandThenMan - Monday, March 14, 2005 - link
Anand got owned by Tim Sweeney.AnandTech: Did you make use of auto-parallelisation compiler technology...
Tim Sweeney: Auto-parallelization of C++ code is not a serious notion.
Good article though.
overclockingoodness - Monday, March 14, 2005 - link
Oh my God - the Unreal 3 engine is beautiful. I get amazed everytime I look at it. I can't wait for games to be featured on Unreal 3 and the like engines in the future. So fine...