Thanks for your input, I found your post interesting. I didn't really expect to find someone else replying to me that knew what they are talking about, haha.

Anyhow, you do make some good points. However, I still hold my belief that the Core processors are not true parallel systems. Yes the chips actually have separate execution cores, but they are still programmed for, for the most part, sequentially. And like you said, the cores do not have their own cache, and the instruction window does most of the work load division for the cores on the chip. The potential performance yield increase in this architecture is no where near as great as with processors like the Cell, where the SPU work loads are generally programmed for by people, as opposed to determined after the fact the best they can by a chip. The division of execution is a reaction, not an preemptive effort. Now, I do realize that OS's do divide threads for execution, but usually that's when you have 2 or more separate programs running at once. That's fine and all, but I'm concerned with better parallel execution of single programs, particularly games in this discussion.

An analogy off the top of my head is that it is as if an event planner organizes a series of events, (some depending on others) sequentially. Then someone down the line realizes some of these events can be done in parallel and parallelizes them the best they can. Instead, had the planner designed the events to be more parallel from the beginning, the potential timeliness for finishing all the events would have probably been much greater.

Here is a good article I read that you will probably be interested in:
http://arstechnica.com/arti...

Note how it says, "The end result is that each SPE is like a very small vector computer, with its own "CPU" and RAM."

My take is that, the software must balance the work load between the SPU's, whether through parallel threading, task specific SPU's, or a combination of both. It is not done for you through analysis of instructions in an instruction window on the CPU - which as the above article states, can also become a problem for memory to CPU latency. My whole argument was that the cell is more like having separate CPU's with their own cache, and without the assistance of a instruction window. If you don't program for it, you might as well only have the one POWERPC Core.

I guess in the end what I was trying to say was, programming for the Cell is more like programming for systems before the multicore processors existed on the market -- when research labs in colleges had multiprocessor computers with many boards in them, each having it's own CPU and memory. And don't get me wrong, I'm not saying multicore processors are bad, they are easy to program for and do have performance increases over traditional single core processors. I just like the Cell for it's potential and the change it may bring about to the software community.

I am not sure if I understand your "instruction window does most of the work load division". No, on a multicore there is no HW which does that. I think, what you are referring to, is a HW threading within the CPU (like even the CELL does within the PPU core). No, multicores are more like two separate entities, really like 2 (or more) cpus. The only difference between previous SMP systems (symmetric multi processor systems) and multicore is, that multiple cores are on one die and the caches are shared (where in the other case, each cpu is physical separate and has separate caches, plus some CPU-to-CPU interconnects).

No, if you spawn two or more threads on a multicore, they are running in parallel. They really do. However, usually the load is balanced thru the OS, not the application. Also, a thread can be shifted from one core to another on the fly while preempted. In that sense it is simply not deterministic, something what the CELL (and the SPU) is, simply because it is 100% SW controlled.

Say, on multicore, you would do geometry processing in one thread, and pixel pushing (shading, rasterizing or what not) in another. It would very much be appreciated, if both threads will stay on their own dedicated HW (CPU), because it simply doesn't makes sense to have sequential execution on one core in this case, and even worse, if you would partition the rendering into tiles, it would be nice to let each tile render at the same time - guaranteed. Something, which is easily possible on the CELL, but needs special thread priorities or locking on a multicore (I don't even know if that's implemented in the OSs out now - not that I know it would work in pthreads, e.g.).

Your analogy with SPUs being separate vector computers is pretty much OK with me. However, they have no real IO except the interconnects within the CELL (the DMA engine) and a HW messaging system (the mailboxes).

But OTHO they are also very close to real multi core cpus. The own RAM has its benefits but also is a challenge. For example, even code needs to reside in that very memory. Which limits the execution size to 256KB and, obviously no jumps out of that bounds. There is no loading from out of cache (well, this SRAM is kind of cache memory and registers at once. The SPUs don't have registers, but you could see the whole 256KB as registers).

Insomniac has solved the code size problem thru what they call "code streaming" in an article, which basically states "code is just data", and the code, when needed is streamed from XDRAM (like a SW driven cache).

The cache analogy is not 100% accurate. Usually caches have some logic, which assures data integrity across its "clients", say, in case of 2 cores, if one core fetches data from main mem, and stores that in the cache, the second core would "see" these data automatically (coherent cache). Not so on the CELL. Each SPU has to take care that the contents of it is in sync with the rest of the system. (Well, there are also non-coherent cache systems out in the wild, I think ARM is one of it, and then its also a chipset feature, not just a CPU feature).

Also, some libraries try to implement a preemtive code scheduler for SPUs. Nice thought, however, because the SPU does not have registers, it needs a well thought (static?) memory layout within the SRAM. E.g. on preempting a new thread, you might want to save the current thread state (this is a context switch). Now, because the SRAM (considered as registers) is so big, it does not make sense to put the whole mem on to the stack, but probably a sub set. What you end up with, is basically a SW driven CPU, which does loading of code and data transparent on the fly when the SPU kernel would need to re-schedule a thread.

But all that is pretty interesting, IMO. Something to play with. To explore, to learn. Somebody came up with a complete new idea. Sure this is challenging. But the basics haven't really changed. If you want to program performance effective, you gotta understand the basics. Even VB or .Net or C# or what not should not hide that away - sure, for some application, why not. I'm happy that somebody found the courage to break out of the just mainstream thinking. How boring would that be. (Eventually this will happen, though, I fear).