A glimpse inside the CELL processor

SPE being "dual threaded-ish" is news to me....

Like the central PowerPC processor, each SPE is a dual-issue machine but unlike the PPE the two execution pipelines are not symmetrical. In other words, each SPE can execute two instructions simultaneously but not two of the same instruction. The SPE's pipeline is "unbalanced," in that it can execute only arithmetic operations on one side (either fixed- or floating-point) and only logic, memory, or flow-control operations on the other side.
 
dskneo said:
SPE being "dual threaded-ish" is news to me....

Careful not to confuse issue width with thread-ishness. The SPEs have always been said to be dual issue, as far as I remember.
 
Guden Oden said:
The original pentium was dual-issue as well I seem to recall, to some extent at least.

it was. to a full extent - i.e. all those n-issue architectures have their co-issue limitations, and so did the p5.

dskneo, as it was laready mentioned, co-issues and threads are spearate things. the difference between super-scalarity (the old classic term for multiple-issues architectures) and SMT being essentially in the presence of multiple concurrent contexts in the latter. no multiple contexts - no SMT, no matter how many instructions a CPU can co-issue.
 
Last edited by a moderator:
I just read a week ago in an article on programming the Cell that this dual issue is used to make sure you can stream data effectively, i.e. execute the code while you load the data, so you get a fully optimised stream pipeline. I figure that's what this is all about?
 
Nice article. I think I understand the Cell a little better now.

I'd like some people's opinion on whether or not we'll ever see a significant performance increase in this chip versus what's in the 360. It looks like it has a world of potential, but the question--as the author of that article succintly stated it--is whether or not programmers will invest the time it takes to "bring it to life."
 
elementOfpower said:
Nice article. I think I understand the Cell a little better now.

I'd like some people's opinion on whether or not we'll ever see a significant performance increase in this chip versus what's in the 360. It looks like it has a world of potential, but the question--as the author of that article succintly stated it--is whether or not programmers will invest the time it takes to "bring it to life."

The talent in this industry has shown they can harness most CPU, if not all CPUs or techs thrown at them. Will dev ignore the Cell because its difficult? Well did they ignored the EE/PS2 when most stated it was very difficult??
 
Jov said:
The talent in this industry has shown they can harness most CPU, if not all CPUs or techs thrown at them. Will dev ignore the Cell because its difficult? Well did they ignored the EE/PS2 when most stated it was very difficult??


You can always ask if dev will think it is worth the extra work/money.
 
Jov said:
The talent in this industry has shown they can harness most CPU, if not all CPUs or techs thrown at them. Will dev ignore the Cell because its difficult? Well did they ignored the EE/PS2 when most stated it was very difficult??

I think that would be more an issue of, would they have ignored the EE/PS2 if it wasn't so popular?

I'm guessing they would of.
 
^Exactly.

As of now, developers are offered a console (the 360) which is already popular and extremely easy to program for compared to what the Cell will be.

When the PS2 came out, it only had to compete with Dreamcast. When the PS3 comes out, it will have to compete with the 360 & Gears of War, with Halo 3 on the horizon.

I think Sony really has their work cut out for them but I hope they pull it off again this gen. They had better get a few more titles on the release list that look worth buying, though. Right now, Fall of Man is the only one worth picking up.
 
elementOfpower said:
^Exactly.

As of now, developers are offered a console (the 360) which is already popular and extremely easy to program for compared to what the Cell will be.
Sorry, but the multithreading on the 360 aint much different than on the PS3. There are even some drawbacks on the 360 which have to be solved by complicated means (e.g. communication between threads is hardly doable, whereas the same is supported "in hardware" on the Ps3).
The compiler is a Metroworks, same on the 360 (afair).
And OGL aint much different from DX. So it's not really fair to say 360 is "extremly easy" to program for, but if it's the case, the same would apply to the PS3 :)


When the PS2 came out, it only had to compete with Dreamcast. When the PS3 comes out, it will have to compete with the 360 & Gears of War, with Halo 3 on the horizon.

I dont think Halo 3 will be out for a long time tbh... And Gears aint that technical wonder that one might expect (speaking of framerate and AA).
When i bought my 360 last year in November, all of the launch games had some technical drawbacks, like bad framerates or no AA. Currently i cannot see this happen on the PS3, as titles seem to be much more advanced and technical superior over what the 360 is to offer, so im really looking forward to it :)
 
Jesus2006 said:
When i bought my 360 last year in November, all of the launch games had some technical drawbacks, like bad framerates or no AA. Currently i cannot see this happen on the PS3, as titles seem to be much more advanced and technical superior over what the 360 is to offer, so im really looking forward to it

Developers, developers, developers, developers, developers, developers, developers, developers, developers, developers!

One "could" take it to be the case that Sony is cherry-picking what they're showing to the public. ;)
 
Jabjabs said:
I think that would be more an issue of, would they have ignored the EE/PS2 if it wasn't so popular?

I'm guessing they would of.

Isn't it obvious if the PS2 was not selling as well as it did, most develops might have invested their resources elsewhere?

The question was "will devs ignore the Cell's potential due to the difficulty in programming it"? As with the PS2, its not the difficulty that will determine which games will go the PS3, its a matter of the potential return in their investment. Thus, it depends on how well the PS3 sells.
 
Jesus2006 said:
(e.g. communication between threads is hardly doable, whereas the same is supported "in hardware" on the Ps3).
Except on XB360 you wouldn't work that way. There's no point. In Cell it's an advantage to keeping RAM access minimised and exploiting internal BW, helping to overcome limited instruction space for a SPE program but dividing the program across more than one SPE and passing the data over. On XeCPU you'd just have a core run the program directly, using the data itself. Why would you want to pass data from one core to another - that's not what the processor was designed for. Each core handles a different (set of) task(s) to the others.

And Gears aint that technical wonder that one might expect (speaking of framerate and AA).
It doesn't matter whether it's technical or not, if it looks impressive and sells consoles to the mainstream. If Joe Public sees GOW, flaws and all (whatever they might be) and gets blown away and sees XB360 as a mighty console that can do great games and he wants one, it's done its job.
 
I expect PS3 will go through a similar cycle as PS2 with regard to developers taking best advantage of its capability over time (I do expect it will sell well enough to warrant the attention!). But asides from that, some of the best efforts on PS2 came out of first and second party developers. Naughty Dog, SCEA Santa Monica, Team Ico etc. etc.

Shifty Geezer said:
Except on XB360 you wouldn't work that way. There's no point. In Cell it's an advantage to keeping RAM access minimised and exploiting internal BW, helping to overcome limited instruction space for a SPE program but dividing the program across more than one SPE and passing the data over.

That's hardly the primary motivator for decent thread communication mechanisms, I wouldn't have thought. There are ways to fit larger pieces of code into LS than would otherwise fit also. Some tasks you might think are "seperate" or "different" on a high level can often have dependencies that could be more obviously solved with threads communicating with one another (or less obviously solved by other means).
 
Last edited by a moderator:
Jesus2006 said:
I dont think Halo 3 will be out for a long time tbh... And Gears aint that technical wonder that one might expect (speaking of framerate and AA).
When i bought my 360 last year in November, all of the launch games had some technical drawbacks, like bad framerates or no AA. Currently i cannot see this happen on the PS3, as titles seem to be much more advanced and technical superior over what the 360 is to offer, so im really looking forward to it :)

What does technicality have to do with how the game looks like or better put, what is the point of technicality if it does not translate to good looks? GoW looks phenomenal, opinions are of course subjective, but when it comes to graphics I see little that can compete with GoW during the fall, even if some games might have more advanced techniques used in them. I rather play good looking games rather than more advanced and technically superior games.

And going by the launch line up is never a good thing to do, especially the xbox360 one. The PS3 has had the great advantage to have much better dev kits out for much longer, compaired to the xbox360 which had final dev kits very close to the launch, and espcially as the GPU in the xbox360 is not as conventional as the RSX in PS3, making things a bit harder...
 
Shifty Geezer said:
Except on XB360 you wouldn't work that way. There's no point. In Cell it's an advantage to keeping RAM access minimised and exploiting internal BW, helping to overcome limited instruction space for a SPE program but dividing the program across more than one SPE and passing the data over. On XeCPU you'd just have a core run the program directly, using the data itself. Why would you want to pass data from one core to another - that's not what the processor was designed for. Each core handles a different (set of) task(s) to the others.

Hm, so each Core basically works as a separate processor independent from the others? And when you want to do some synchronization you have to access the ultra slow main RAM? I don't think that each working on its own task will work in a modern multiprocessing environment since you have to do alot of synchronization tasks every single frame (sound/physics/ui/ai ...). There is not much you can do independently, except for maybe playing some music in the background :)
 
You might want to rethink that. What exactly are you going to be passing data between SPE's for? Calculate AI on one SPE, pass the results to another SPE to work out physics on that object, and pass those results to another SPE to work out sound? Many dependencies require a 'world view' which means working in main RAM, storing object properties, positions, collision meshes, audio samples, and for tasks that need a world view, each SPE will have to access this RAM. The inter-SPE connectivity is there for sharing tasks, having one SPE perform part of a task, and pass the results onto another SPE to do another part of the task. Where a task can be linearly divided amongst multiple cores, it works. On the whole thought, these CPU's are about running independent tasks concurrently, each a separate processor working from RAM. There's very few tasks, especially in a game, where you will be desperate to pass data from one core to another as quickly as possible - though of course in an architecture like Cell where you have the option to do that and can beenfit from it, you will. It's just not a requirement though, and certainly not a major drawback.

Some tasks you might think are "seperate" or "different" on a high level can often have dependencies that could be more obviously solved with threads communicating with one another (or less obviously solved by other means).
Just write the data to an address in RAM from one core, and read it from that address in the other. It's cached in L2 and readily available. I'd also like to know what independant activities in a game could be aided by working across cores internally. How can physics on one core and AI on another work better passing data between rather than working on their own? Or whatever other tasks there are.
 
Back
Top