| Carl2291 said: Lol @ damage control in this thread. Is it illegal to say something good about PS3? Cell = Skynet. |
Not quite. The main problem of the PS-3 is something different:
The SPUs and the GPU don't work in sync with each other. On normal PCs or the Xbox 360 you have 2 types of code that has to interact with each other, on the PS-3 3. For Number Crunching purposes you normally only use 1 or 2 different SPU Programs, in games you have the tendency to use more and you might even have to reconfigure SPUs on the fly.
This makes development more complex and more expensive. On a multi core can share parts of the cache and use this to synchronize their work, you can't do this for the local caches of the cell (without big delays and the risk of major havoc due to the bus).
Additionaly the communication model of the cell is optimized for data performance, but it doesn't know anything about priority. For Number crunchers perfect, for a game console a problem. It is better to let SPUs run dry than to risk that low priority large volume data blocks high priority data. The timing not the pure data volume is the important thing for a game.
It is in fact common knowledge that different kinds of code might have totally deifferent requests on the architecture. In fact there are many programs where there is simply no way to let them run in parallel. This has nothing to do with inefficient code but with simple logical constraints.
It is VERY easy to loose the theoretical advantages due to some small, overlooked logical constraints. Sometimes theoretically slower code can run much faster due to less memory consumption or due to a bigger code independence.
In fact many programs have the simple problem that the programs evolve during the development! A very big problem for efficient development. In fact one of the principle advisories for the development on the cell demands that you should first implement everything on the PPU and latter migrate functions to the SPUs. For most number crunching jobs pretty easy, for the development of a Game a "No Go" Situation, the game designers have to be able to know how the game feels with a certain feature before they can decide on the proper course for the development!
You do hnot have an idea how often "efficient" Algorithms are scrapped due to too many bugs. Especially in parallel programming race conditions are pretty common and they can be a pure nightmare to debug. The old description you write 90% of the code in 10% of the time and the remaining 10% of the code in 90% of the time can grow dramatically, especially in projects where someone just had a good idea...
Especially in multi plattform games these things can become MAJOR issues. "Why are you not finished with this feature?" and you are easily forced to use a much simpler but less efficient approach to meet the deadline. The plattform itself is only one problem cost or timing constraints can be much more important.
