The PS3 has untapped potential, because said potential takes more thought and time (and hence, money) to take advantage of, in any cross-platform game engine. Now that many devs have shipped a PS3 title, I think we can, in general, expect the next round of titles to be much better, in terms of PS3 performance.

The 1st/2nd party exclusives Sony offers will always lead the pack, in this regard -- they never had to consider the 360 or PC in creating their engine architecture, and thus, from their point-of-view, the PS3 is practically as easy to develop for as the 360 is.  Its really crossplatform development that poses the challenge, and the PS3 is merely the odd man out, whereas the 360 and PC are very much the status quo, for PC-centric, or inexperienced developers.

As 3rd party engines develop, they will adapt to utilize the PS3 better, and some of those adaptations may actually make some engine architectures run better on the 360 as well -- simply because the principles necessary to make an engine fast on the PS3 also apply to the 360, but are avoided because they aren't "status quo" engine architecture, and thus would require devs to do more work on the 360, with performance gains much smaller than those seen on the PS3 (but gains, nonetheless).

Was that earlier quote a misquote from the Insomniac developer. I'm pretty sure there is no way you can describe a SPU as a CPU. I know you like hard facts MikeB but I honestly do not believe you can officially call a SPU a CPU. I'd guess it was probably a over simplified answer to a non technical interview.

No it's not a misquote and note I provided the source link.

And yes, you can easily decribe the SPUs as being CPUs, in fact I did so many times in the past (of course with information like provided below or else some vivid 360 fanboys will out insults, while they themselves are in fact ignorant on the subject).

The SPE is like a tiny system, which is able to function to a very large extend entirely independently. Part of the SPE is the SPU, which acts as the central processing unit of this micro system. This design structure is very different from common multi-core CPUs and provides some significant advantages.

Other IMO important quotes from that article are these ones:

I lost count on how many times I had discussions with vivid 360 fanboys with regard to this topic in the past (with sadly discussions usually turning towards very childish nature). I was basically saying something almost identical as to what the Insomniac devs stated above.

SPUs are CPUs. Seriously, if anyone doesn't understand this, and they call themselves a software engineer, they need to go back to school, and they need to do it now.

If you're not a software engineer, I strongly advise you to take the advice of actual software engineers who understand that the SPUs ARE CPUs, in every sense of the word. The SPEs are not capable of addressing main memory directly, and instead address their localstore (something like a L2 cache, but addressable, as I stated), and use 16 DMAs to transfer data in and out. That's it. That's the only real difference, other than the fact that they lack a branch predictor, and have incredible vector math operations and muscle, along with the bazillion registers needed for just that.

Since caching mechanisms are really just a convenient form of fast memory with what amounts to "automatic DMA transfers", the SPUs really just boil down to being full CPUs, without some conveniences -- but lacking those conveniences allows the chips to have WAY more cores. A good tradeoff, if you're willing to work around the conveniences.

Since the automation of the conveniences has never really been very efficient anyway, the hand-crafted code work that goes into making a SPE job also ends up making the SPE jobs brutally efficient.

The hand-crafted performance takes work (and as I said, you can do the same on the 360, if you put the effort in... its a shame all that wasted convenience logic goes unused though, when it could have made for more cores...), but in the end no highly-compiler-dependant, hardware-convenience-reliant chunk of code can ever hope to compare to well-written, well-designed "manual" code.

Can you buy most high-end sportscars with an automatic transmission? Would you want to?  Honestly, if you're into programming, writing an app on the PS3 is fun, because it rewards you well for doing hard work.  Squeezing "75%" of the performance out of the Xenon is easier than squeezing "75%" out of the Cell though.  Getting more is easier, and more fun, on the Cell however, and the end result on the Cell is just plain unmatched (by the Xenon), when it comes down to it -- both will still benefit from the harder effort, though, for certain.

(SPU == Synergistic Processing Unit... i.e. the processor+localstore.  SPE == Synergistic Processing Element... i.e the SPU, plus the 16 DMAs/bus interface, basically.)

Did I claim at any point to be a software engineer, I thought it was quite clear I'd heard different to MikeB and hence asked why they were considered CPU's.  It would seem my understanding of the defintion of CPU is different to the general view now which is its another word for processor or microprocessor. 

Perhaps the traditional understanding of what a CPU was in my case makes it hard to understand how it could be labelled as such.  Having done some more reading I think when combined as a package each SPE could be labelled a CPU indeed, what I don't understand is does the SPU actually have a instruction set (RISC) which is what in my terminolgy understanding is actually a element required for a CPU.  I now the SPE has a instruction set so perhaps it would be fairer to say the SPE is a CPU and the SPU a compnent of it.  Regardless I'm wrong questioning the last quote to a degree, but would my statement just now be a more correct defintion or have I just lost the plot (please be gentle).

I wasn't really referring to you, with the software engineer comment, slowmo.  I was trying to fend off fanboys who like to spout BS reports from other misinformed sources.  Sadly many folks are misled to believe that the SPEs are somehow lacking in function, and thus they're not as capable as the Xenon cores, etc., which is silly.  They are different, yes, and from a utility perspective, the Xenon's cores are easier to use because they are very mainstream in design, although from a technical/performance perspective -- and a very realistic one at that, the SPEs clobber them with sheer numbers.

The truth of the matter is very complicated.  X360 engines, as I said, hit that "pretty good" mark faster, because you can hire just about anyone to work on them (which often equates to cheap/inexperienced devs), they never really need to understand the hardware fundamentals, and the Xenon cores aren't slouches at all.  They are 3x 3.2 GHz cores, and that's pretty dang hard to go wrong with!  

Those same green engineers will, at first, see the PS3 as only having "one" 3.2 GHz core, and a bunch of wierd thingers they don't understand.  "DMA? Hardware mutex?" They say, and they practically throw in the towel right there.  When they open their eyes, suddenly there are 7 3.2 GHz cores available on the PS3, with 6 of them with absolutely stunning math performance to boot, and they all have their own slice of "cache" (rather than having to share, like the Xenon cores), which performs spectacularly without the automated mechanisms needed to operate the thing, and handle all the conflicts that sharing, and generally bad (for performance, but great for code legibility) high-level C++ coding, causes.  The 8th core (PS3 is 1 PPE + 7 SPEs, remember) is used to perform some of the OS functions one of the Xenon threads normally has to handle, so, in a sense, there's another PS3 core as well -- you just can't change its function.

A SPE is a complete processor -- it is not a DSP, which is the wierdest thing I have ever heard them called (and I've heard it lots, including from Sony 1st party devs, like Guerilla in the OP! -- I'm not knocking you here).  Along with the DMAs/bus interface making up the entire SPE, its a complete package, and wholly integrated into the architecture, although, as you suggested, in a new, different way.  The SPEs share a blazingly fast ring bus, they can directly communicate with each other, main memory, and GPU memory at incredible rates, they have all sorts of spiffy hardware mechanisms in place for parallel algorithms, the list goes on and on.

As a professional* myself, having worked with both architectures at low levels, I can tell you that I certainly find one more entertaining than the other, especially since the rewards for good coding and design are so impressive.  I desperately hope that Sony has a "Cell2" or whatnot in the PS4, and that the PS4 does well next gen, because hell yes I'd like to work with an even fancier version of the PS3. 

From a business standpoint, you have to take a step backwards.  Better engineers?  They cost more money.  A LOT more money.  Sure, you game naturally becomes better -- and... how many great engines/games do we see flopping these days?  Sadly, a ton.  Engineering is far from everything.

If you can ship a game with 3 years of development, at "75 power units" on the 360, and "65 power units" on the PS3, are you going to take that, or ship it, perhaps, a year later with "89 power units" on the 360, and "90 power units" on the PS3?  Your goal is money of course, and not critical acclaim, although the latter certainly assists the former, especially when it comes to making a sequel.

How about an exclusive?  As a 3rd party publisher, are you going to take 4 years to make a 360 exclusive with "100 power units" performance, or 4 years to make a PS3 exclusive with "125 power units" performance?  Isn't it really just about installed userbase?  Frankly though, with ~40% of your users on the other console, why bother making an exclusive at all, when porting is so cheap, relatively?

As time marches on, 3rd party PS3 engines will begin to settle into their groove... and so will 360 engines (sooner, presumably, due to the 1 year headstart, but not due to "ease-of-use", as I said, since squeezing the best performance out of the 360 is just as hard as the PS3.. maybe even a little harder), crossplats become more and more attractive (since the cost-to-port gets cheaper and cheaper), etc.

I gotta stop rambling now.  Sooo far away from the point of the OP.  I guess my point is that, if you, as a game development house, are looking to really build an awesome game engine, and the usual limits, like money, time, etc. are less important (they're always a bit important)... its easier on the PS3 than the 360, plain and simple.  Most games factor time and money into the equation more heavily, and frankly, the 360 has got some game in that dept. that the PS3 cannot match... at least not until PS3 engines are already in existance, and the initial hurdles have been passed -- and then, its anybody's ball game.  There's no big mystery as to why the PS3 has a lot of new exclusive announcements all of a sudden (read: Sony 1st party devs... MS just doesn't have as many), and there are so many crossplats on the horizon.

EDIT: *Professional procrastinator, of course.  That's what I mean.

Excellent post Procrastinato, many thanks.

I'm not sure I agree with that logic.  I'll use a metaphor to show you what I mean.

I thought Differential Equations was the easiest math class I took in college.  I got an A pretty easily.  However, if you ask most people, that class is really hard.  So, who is right: me, or everyone else?

wikipedia told me that the ps3 is te hardest to delvop for.