A Glimpse Inside the Cell Processor

XenoPhage writes "Gamasutra has up an article by Jim Turley about the design of the Cell processor, the main processor of the upcoming Playstation 3. It gives a decent overview of the structure of the cell processor itself, including the CBE, PPE, and SPE units." From the article: "Remember your first time? Programming a processor, that is. It must have seemed both exciting and challenging. You ain't seen nothing yet. Even garden-variety microprocessors present plenty of challenges to an experienced programmer or development team. Now imagine programming nine different processors all at once, from a single source-code stream, and making them all cooperate. When it works, it works amazingly well. But making it work is the trick."

Comments

Oh yeah, I remember my first time

[llamalicious]

I was 17 and she was 26 and ... oh shit, wrong first time.

Re:Oh yeah, I remember my first time

[neonprimetime]

I was 17 and she was 26 and

Per chance, did you have a MySpace account, and your parents didn't know about your little shin-dig?

Re:Oh yeah, I remember my first time

[Rakshasa Taisab]

I'm not familiar with any 26 processors, surely you meant 286?

Re:eh

[Zediker]

"Console gamers get consoles because they can't deal with installing video card drivers."

Nope, console gamers buy consoles because they offer games that dont appear on the PC and/or dont have the money to buy a pc gaming rig. $1200+ (im talking building from the ground up with reliable and decent parts) to just start getting a decent computer together usualy isnt as justifiable as spending ($100:GC, $130:DS, $150:PS2/Xbox, $200:PSP, $400:360) for a console of some sort.

Sega Saturn Redux?

[ToxikFetus]

As TFA mentioned, this has the potential of becoming another Sega Saturn boondoggle. Will the developers learn how to fully utilize this incredibly complex architecture? Relying on the "octopiler" to efficiently map to the Cell architecture seems a bit optimistic and naive.

Re:Sega Saturn Redux?

[SSCGWLB]

I seriously doubt they will write efficient programs in the lifetime of this console. The level of efficiency they will achieve depends on a lot of things. I didn't see it in TFA, but I am assuming you cannot treat each SPE as an individual processor.

First of all, their dream of a general 'octopiler' is pure fantasy. I have written massively parallel MPI and Shared Memory applications and can testify to their complexity. Mapping an arbitrary piece of code transparently to multiple processor is a extremely difficult task. If the source is carefully written, it is possible to parallelize certain sections. This requires careful forethought and detailed knowledge of how the compiler works. If I where to guess, I would say they would use some type of middleware (a la CORBA) or libraries (a la MPI) to extend a programming language. That way, the programmer could specify sections of code that can be executed in parallel. This would help the compiler immensely and make much more efficient code. It would be really cool if the SPEs had some type of identifier, allowing you to task specific SPEs! I haven't read much about the CELL, so this may or may not be possible.

Overall, I bet the vast majority of the parallel code will be in carefully crafted libraries of CPU intensive tasks. These libraries will grow over time, making utilization of the SPEs more and more efficient. Until then, the main CPU and one SPE will execute the majority of the game with occasional help from the other SPEs.

~nate

Re:Sega Saturn Redux?

[jd]

Not sure it's that complex. If anything, it sounds rather limiting. Eight isolated physical coprocessors, each supporting two threads? Why not have one coprocessor that supports 16 threads that maps onto as many virtual coprocessors as desired? Basically the same circuitry, but can dynamically remap to the problem being solved, as opposed to remapping the problem to the circuits provided.

(Having the computer model itself to the problem reduces the complexity of programming and will make optimal use of the hardware. Having the program model itself after what the computer is tuned to do is merely an ugly hack and requires ugly compilers to specifically translate between the paradigms.)

The cell processor is designed around 1980s concepts of load-balancing while keeping to many of the rules of second-generation programming. Technology has moved on. That's not to say the cell is bad. It's a definite improvement over the 1960s concepts used in many modern CPUs. However, it is still 20 years behind the curve. C'mon, guys, this isn't the Space Shuttle, it's a microprocessor. There is no excuse for network and design technology to be so far beyond the best of the best that industrial giants are capable of doing.

Actually, it's worse than that. Modern multi-processor systems require specially-designed chipsets and become exponentially more expensive as you build them up. Single boards don't usually go beyond 16 processors. In comparison, people built single boards with 1024 Transputers without difficulty, with costs increasing linearly. So, in multi-processor architectures, we can't even match everything that could be done in the 1980s.

How does this affect those using the Cell? Well, that's simple. It doesn't offer enough of an added advantage and is different enough that coders will have difficulty making good use of it. That means that coders will have to be inefficient OR dedicated to that one chip, which has no guarantee of making any money for them. Coders won't bother, unless there is something out there that will make it a guaranteed success. I'm not seeing this killer demo.

Re:memory speed?

[Space cowboy]

You are misinformed.

This is the speed at which the Cell can read RSX's local memory. Memory bandwidth for the Cell itself is ~25 GB/sec. If the Cell ever wants to access the private RAM of the RSX (why ?) it *is* possible, but it's a lot more efficient to use the normal pathway through main memory...

Simon.

Not NINE processors, only EIGHT, since...

[Harry Balls]

...on the average, one of the slave processors is non-functional.
Read more about the yield problems of the Cell chip here:
http://theinquirer.net/default.aspx?article=32978/

Fabrication yield is estimated at only 10% to 20%, which is very low for the industry.

Re:The article's author is huffing crack here...

[argent]

I think the article's point was that once you get more and more transistors on there it becomes very difficult to design things to not end up overheating all the time and not use up insane amounts of power, not to mention just becoming extremely complex like x86 cores today.

I wasn't talking so much about the article as a whole, but the insane levels of hyperbole in the particular paragraph I quoted. "We're capable of putting more transistors on a chip than we can think of things to do with". That's not even vaguely true.

More transistors == more power, all else being equal, because it's all those junctions flipping state so quickly that uses the power.

As for the insanity if Intel's processors... that seems to be a perversion particular to Intel. In the past three decades that I've been following the industry, Intel has only managed to produce *one* sane CPU design, the i960, and they promptly caponised it by removing the MMU and relegating it to embedded controls lest it outcompete their cash cow.

The rest... from the 4004 through the 8080, the 8086 and its many descendants, iApx432, i860, and Itanium... have been consistently outperformed by chips with smaller transistor budgets built by companies with far fewer resources. They only occasionally broke past the midrange of the RISC chips, and were usually trailing back with the anemic Sparc. Where they have excelled has been marketing and in the breadth of their support... both hardware and business. IBM went with the 8088 because they could get them in quantity and they could get good cheap support chips for them: if you went with Motorola or Zilog or Western Digital or National Semiconductor you pretty much had to go back to Intel to build the rest of your computer anyway.