Lol @ damage control in this thread.

Is it illegal to say something good about PS3?

Cell = Skynet.

 CELL IS PERFECT

Saying Cell has ins and outs is damage control? Is it illegal to say that PS3 is not the best thing since sliced bread?

Let's use an analogy. Cell is like a dragster. In straights (Developing with a very big budget, time and dedication, when it's not so important the economical side, but the technical side: 1st party mainly) it's the fastest car without any doubt, but in the majority of occasions, in the rest of circuits (3rd party games) it's very hard to use, and when you go off road (ports), it's a torture to use.

.....what???

1) OOE will make the highly branchy code you are talking about run slower. The purpose of OOE is to avoid wasting cycles on memory loads. The problem is if your code branches the wrong way an OOE architecture has to undo either undo all the damage it did, or just stall at every conditional. Either way you were better off without it.

2) Define AI. I don't think any games are using neural networks. Not that they require loads of branching anyway, in fact they are probably one of the inherently least branchy things I can think of which is why people do them on GPUs or even better FPGAs. But, Neual networks are non-rigourus silliness any way:P FSMs can easily be done with matrix multiplies. All graph operations have matrix analogs. Back in the day when I wrote an RTS the unit AIs were modeled as a particle swarm.

Now I assume you are talking about decision trees, but there are invariably better ways of doing clustering (which pretty much all AI boils down to) than that. And yes people who work with decision trees tend to write inefficient code. Hence LISP.

3) Just because there are conditional statements doesn't mean you actually need to branch. You can use masks and guards as I did in that sample code 1-2 nights ago in the Xenon vs Cell thread.

I was gonna reply to you...

But CGI saved me the time

Believe me, I'm not offended. Maybe it's that I'm a bit tired of the use of "damage control" whenever someone says something that is politically incorrect. And in this context, it's saying Cell isn't a chip for everyone and everything. Maybe I shoudn't quote.

1. Uhm... And how will in-order execution handle very branchy code? What will happen when prediction fails? Anyway, you are right. OOE tries to kill latencies.

2. Well, I know that neural networks won't work with just about anything more complex. Just commenting on MikeBs comment about Cell simulating human brains. And yes, I was talking mostly about decision trees. Just think about decision tree + more than 256kb memory for decisions. Cell would have hard time with that kind of AI. And using/not using decision trees it really depends on game.

(Well to be honest, I prefer HFSM myself usually.)

3. Can you provide link. I am just too lazy to search it.

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.