This sentence : "How many of you have looked at the CBE SDK"

Maybe i am mistaken (it could have been another poster), but i have read posts from you showing me that you envision the programming this CPU as if it was a "simple" multi-threaded one. "You give the sound to SPE 3 and 5, the AI to SPE 2, etc".

Distributed parallel programming is more complex. 

It was definitely another poster.

The fact that the SPEs can't directly address main memory precludes "simple" multithreading.  You can't just spawn a thread for something, you have to think carefully about how the threads will use data.  This is, IMO, a strength of the design as compared to a simple multicore CPU such as the Xbox 360's.

Precisely. Each SPE has very high computationnal power.The fact that each SPE can put / store datas very quickly to the local store of another, and that with 6 of them you can organize them (ring , linear or hypercube, etc.) make me say this processor was designed towards distributed parallel programming.

The possible rewards are potentially tremendous in what you can perform as calculation.

Problem is reaching global efficiency has proven theorically and practically very difficult on such systems. Have you looked how the algorithms for "sort" or "matrix multiplication" look like in such environnements ?

You said this is "a strength of the design". I prefer to say this is a very ambitious one.

 Edit : typos.

Actually, I wrote a Cell matrix multiplication as a case study.  :)  I didn't get 200 Gflops out of it like some case studies I've seen written entirely in asm, my goal was to write a readable program and gain some experience in this kind of programming, not completely max out the silicon.

The reason I say it's a design strength is because you can't just whip something together.  Now, people are going to take this to mean that it's difficult to program for.  My reasoning is that writing very efficient programs in a multi-core environment IS difficult.  You can easily whip something together in a shared memory system, but it's not going to perform well unless you think carefully about how the threads use memory, and how you're going to synchronize tasks.  You can't get anything done on the SPEs unless you think carefully about these things, so it sort of enforces efficient design by not letting you take the easy way out.  Note the "sort of" there.  :)  Obviously you can still hack something together, but just the fact that you have to write code to initiate a DMA transfer makes you stop and think, what's the best way to do this?  How do I efficiently get the data to and from the SPE?

You make as if this type of programming is fairly simple. I cannot agree there.

Listen, in a monothread environnement, a generally first attempt to make a sort (bubble sort) imply a complexity O(N^2).

I you step back a second and "think" a better way to make it (quicksort, radix sort, etc.) you can arrive fairly simply to a complexity of O(n*log(n)) or O(n/2*log(n^2)).

 In a distributed parallel one you can obtain even more efficient algorithms. For example, if you have a bitonic sort friendly environnement (which Cell is not), you can theorically obtain O(n). 

 But there are 2 conditions :

1) the total inter-processors communications needed must be inferior to a calculable value related to your algorithm.

2) You must not make any "mistake" both in your algorithm and in your implementation, because "you pay it cash" very quickly. 

This is on this point (2)) that i don't agree with you. Very clever programming designs imply great results.  It is not as simple as "thinking twice". I shall not insist enough how Distributed Parallel programming is different from Mono-threaded one. In my experience, you make easily mistakes that make your complexity explode ... If you have implemented a matrix multiplication on Cell, you do know that.

Can either of you two (oli2, Entroper) recommend a decent compiler for YDL 5.0?

Then why do they run so smooth? Oh well 30fps is good I guess.

Hehe.  "Bus error?  What bus error?!  There's no bus error in this code, I checked it!"  Yeah, I've been there.  :)

I'm talking more about optimization and tweaking, buffering memory reads, reducing bus contention, etc. than actual parallel algorithm design.  Still, I admit this kind of programming is not easy.  I do, however, think that a programmer working on a game engine for a major title on the Playstation 3 should be expected to be able to handle this sort of thing.  I don't want to get into whether it's the developer's fault or the publisher's.  The point I'm trying to make, though, is that Cell is not this unbearably cryptic design that only the smartest programmers in the world can crack, whereas on 360 you just plug and chug and out comes a fast game engine.

My view relyes more in this : programming efficiently on 360's processor is difficult. Programming efficiently on Cell is more difficult. The trade-off is eventually more "rewards" on Cell, but within the context i detailled in my previous posts.

edit : typos.