I don't understand why console makers are bent on being so power-conservative?

[futurefields]

Lots of PC games love +4ghz. Because the engines arent heavily multithread capable, they rely more on per core perf. Not sure how they get those games to run on 8 cores of netbook cpu.

Its going to be a whole new kind of "consolization" of games next gen, that's my prediction.

 

[futurefields]

BrightCandle sounds like he knows what he is talking about. And if I understand what he is writing correctly, these cpus are gonna be a headache.

 

[cmdrdredd]

At first they will probably be tough because developers are used to having more clock speed on a PC with higher IPC ratings. These require you to saturate multiple threads to get the benefit.

 

[JeffMD]

Brightcandle, can't say I know from first hand experience, but I tend to find that everything can be broken down smaller and more module like. Why can't you break threads down into, for instance crysis, one thread will be grass motion, one thread will be shadow mask, one thread will be physics, you should be able to break every AI actor into a thread, one thread will be tree motion, one thread will be calculating the surface of water. I would think if breaking things down and using slower cpu's were not possible, game makers would be crying out for hardware vendors to make faster clocks and less cores, no?

 

[smackababy]

Brightcandle, can't say I know from first hand experience, but I tend to find that everything can be broken down smaller and more module like. Why can't you break threads down into, for instance crysis, one thread will be grass motion, one thread will be shadow mask, one thread will be physics, you should be able to break every AI actor into a thread, one thread will be tree motion, one thread will be calculating the surface of water. I would think if breaking things down and using slower cpu's were not possible, game makers would be crying out for hardware vendors to make faster clocks and less cores, no?

Because you quickly get to the point where thread A is waiting for thread B, who is waiting for thread D, and thread C is running something thread D needs to get started. And with that, while it might be faster, the development time and complexity increases a lot; thus, more bugs, more time spent coding, more money spent on gaining a insignificant performance increase because thread A could have run A,B,D before C even finished if it had just run in a single thread.

 

[JeffMD]

I dont really see how being locked in individual threads would cause any difference in issues in code execution and wait states that we see now. A dormant thread is just..dormant. And a line of instruction that is waiting for another line of instruction behaves the same no matter where it is. I mean if you needed to code all your lines to execute and finish in synch then threads could mess that up, but what does that? One characters ai could be way more complex then another's (I don't mean the code, but the amount of work to be done. one actor could be tracking 5 targets and another only 1, the thread for the second actor should always finish early) .