Tim S: Yeah, well, programming for multicore architectures is hard. If programmers had our way, we’d just program single-thread application forever, because it’s much easier.
But it’s also clear that there’s an irreversible hardware trend towards multicore, because that’s the only way to deliver maximum power economically. You just can’t make ever higher gigahertz rates—at some point your CPU becomes a microwave and melts your computer. Multicore is here to stay.
What we’ve found in this generation—and here are some scary numbers—is that writing an engine system designed for multicores, that can scale to multiple threads efficiently, takes about double the efforts as single threaded.
It takes double the design effort, implementation effort, lifetime support effort, debugging…all the costs metrics multiplied by a factor of two for multicores. That’s pretty expensive, but ends up being bearable.
Whereas, some of the other hardware trends are even worse than that, like programming for Cell, we found, had a [five-times] productivity divisor. It’s five times harder and that really starts to hit…you have to question whether it’s economically viable for mainstream developers to put real effort into it at that point.ç
And then GPUs are trying to take a non-graphics algorithm and run it on the graphics processor currently. Given the limitations of those languages, we found that the multiplier there is 10x or more, which is well out of the realm of economic viability.
But in the next generation, we’re going to likely see CPU architectures with tens of cores, maybe even approaching a hundred. At that point, anything in your engine that is not multithreadable becomes an insurmountable bottleneck—everything needs to multithread.
I disagree in the last part, is unlikely, why, most of the code can't run without several changes in dual or quad cores, and the inustry is moving to put some Accelerated Processing Units in the CPU rather then 80 cores in one socket...
BTW, Second dev to put some "buts" in the whole Cell thing...
