PS3 Cell processor info ... good read.

[Jammrock]

Some expert type person took a look at all of the patents submitted for the Cell processor, which will power the Playstation 3. Look like a very interesting processor:

http://news.zdnet.com/2100-9584_22-5563803.html?tag=zdfd.newsfeed

Processor info in a nutshell:

- Cell will be a variation on multi-core processing, broken up into "software cells."
- Each core processes an individual task, instead of each core processing a portion of a task like traditional MP units do.
- PS3/Cell will have distributed processing built in. This means that if you have 3 PS3's connected on the same network, the PS3s can distribute processing tasks to be handled by the other PS3s (think Beowulf cluster computing in the Linux world).
- Copyright protection will be integrated into the Cell silicon itself, which could make pirating games nigh on impossible.

The Cell processor and all the goodies are supposed to be unvieled at some big trade show in San Fran on Monday.

Jammrock

[GT98]

lets see if it lives up to the hype...

Isnt there a rumor or something that MS is using the some processor or is it just that IBM is building the chip for both MS and Sony???

[Jammrock]

The rumor is that IBM is pitching the same CPU to both MS and Nintendo. That and with both MS and Ninendo using ATi for graphics the rumor was that the guys of both boxes could be identical.

[Nowhere]

I've found this page to be a good read.

[J1NG]

I can see a few Europeans not liking the PS3, especially the ones that can't or don't have the ability to import foreign ones in, if this protection works.

Who really wants to wait 6 stupid months for a game to be played to death by the rest of the world before you can play it? Especially if it has online abilities? Who really wants to play XYZ, the best game of Summer 2006, in March 2007?

Anyway, back to topic. I think Sony are slightly missing the mark here. Sure, it might have more power than the rest, more so even (possibly). But the problem is. If they're touting, "Want more power to do ABC (in the future)? Buy more and put together!" This is not Console area. It's a PC style upgrade architechture (well, graphics card and cpu style anyway), that we all well know is expensive to the consumer. And won't sit well in the long run. Well, that's my opinion anyway.

J1NG

[DGhost]

it's an interesting architecture, but the problem I see is that unless you are doing a shit ton of things at the same time or a task that can easily be broken down amongst many processors it is not going to be that much better. or synthetic benchmarks.

the average games are not that parallel in nature. Certain parts are and could be handled really nicely by this, but most consoles already have multiple dedicated processors to handle different tasks such as audio, graphics, etc. it depends though - are they using it for graphics processing as well as general processing?

i honestly have a hard time seeing situations where the need to have that much parallel computing available in a single box is useful, shy of running a game that includes HDTV quality stream decoding as part of it while hosting the server for a multiplayer game *and* recording your favorite TV show and encoding it into MPEG2 or MPEG4 at the same time.

I dunno. Parallel architectures have been available relatively cheaply before in our history. Dual proc boxes were acctually relatively affordable a few years ago (before the P4 and the Opteron). It really never has taken off in software development and even the Itanic never got around the problem of having to have multiple things going on at the same time in order to hit peek efficiency.

I dunno. One thing that was mentioned in an article is the idea of being able to use JIT compilers and emulators with it. Yes, but you will still run into problems. It seems like a horrid kludge to throw that much processing power at a problem.

I dunno. we will have to see.

[Nowhere]

But the thing is this "paralell" physical units can act as a "chain" (from what I understand...)

[DGhost]

Not if you are executing a series of instructions where the input depends on the output of the instruction in front of it. you cannot break that down and run it in parallel. this has been the biggest problem with parallel processing - there is only so much that you can run in parallel.

The only real way to solve this is to design algorithms so that they can take advantage of multiple processors (ie, generation of fractal geometry), or to make two different threads that do the same thing on different data sets (ie, encryption cracking by defining different ranges of keys to break).

this kinda goes into the whole "ye canna break the laws of physics, captain!" discussion.

graphics has been able to sidestep this issue because of the fact your screen contains so many pixels and each one has to be computed seperately of each other. 3d accelerators are massively parallel math processors - the 6800 Ultra is capable of operating on 16 pixels at a time, with how many pixels accually being rendered per second being based on how much math is required to compute each pixel when running pixel shaders.

the cell processor seems ideal for graphics processing, however Sony seems to be using a dedicated graphics processor inside the PS3 as well. It might be able to help offload some of the work (geometry processing?), but it is debatable how nessicary that is.

Microsoft seems to have realized that some parallel ability inside a console is useful, especially when you get into people hosting their own gaming servers (the XBox has been notoriously bad for hosting large games) and when you get into advanced audio/graphics/physics processing. However they also seemed to realize that as of right now there is no large demand for a massively parallel computer and seem to have balanced the XBox 2 accordingly.

dunno though, just my $0.02

[Nowhere]

Originally posted by DGhost
Not if you are executing a series of instructions where the input depends on the output of the instruction in front of it. you cannot break that down and run it in parallel. this has been the biggest problem with parallel processing - there is only so much that you can run in parallel.
...

Well that's what I've meant, the cell will be able (well, at least according to one read above...if I understand it correctly) to use its many APUs NOT ONLY in, limiting, parallel mode, but also in a way where each APU executes one stage of series of instructions, all APUs working on one set of data "flowing" through them (so in practise this would be, I think, some kind of very effective parallel processing - only without the limiting need of waiting for previous stage to complete - because data will be constantly flowing between APUs - panta rei )

[DGhost]

Originally posted by Nowhere
Well that's what I've meant, the cell will be able (well, at least according to one read above...if I understand it correctly) to use its many APUs NOT ONLY in, limiting, parallel mode, but also in a way where each APU executes one stage of series of instructions, all APUs working on one set of data "flowing" through them (so in practise this would be, I think, some kind of very effective parallel processing - only without the limiting need of waiting for previous stage to complete - because data will be constantly flowing between APUs - panta rei )

even if it was broken down into stages, each APU has to wait until the APU working on the preceeding stage is done. if the input is not a constant, it *has* to wait until the value is computed before it can operate on it. The only exceptions of this is when using branch prediction, and even then it generally only operates on cases where there are only two branches - ie, true/false pairs.

most of the APU's would still sit idle because you cannot get around that fact.

it would have to be running very computational intensive tasks that can be easily executed in parallel to itself for it to even come close to it's full potential. think encryption, video encoding/decoding, rendering, etc. the end result is that the Cell architecture needs to be running lots of different intensive tasks at the same time for it to yield anywhere near the level of performance that article hypes it up to be.

future games are going to become multithreaded over times, but what this would demand is ridiculous. you would need seperate threads for audio, graphics rendering, graphics data, physics, the game server, the client, input, disk access, network, etc etc. the thread syncronization issues would be a bitch, and it would be very touchy in terms of performance. the positive side is that if you wanted to do it, you could do different threads for each audio stream, and quite possibly one for each model that is being rendered.

[Nowhere]

Originally posted by DGhost
even if it was broken down into stages, each APU has to wait until the APU working on the preceeding stage is done. if the input is not a constant, it *has* to wait until the value is computed before it can operate on it. The only exceptions of this is when using branch prediction, and even then it generally only operates on cases where there are only two branches - ie, true/false pairs.

most of the APU's would still sit idle because you cannot get around that fact.

I wonder how much can be gained by optimazations...I mean, at the beginning no one know how to program ps2 effectively either

it would have to be running very computational intensive tasks that can be easily executed in parallel to itself for it to even come close to it's full potential. think encryption, video encoding/decoding, rendering, etc. the end result is that the Cell architecture needs to be running lots of different intensive tasks at the same time for it to yield anywhere near the level of performance that article hypes it up to be.

Of course...but look at it this way - the tasks you've mentioned are, I think, the ONLY tasks in which current cpu's struggle...so if cell will not be slower in other, "traditional" tasks (for which there is enough cpu power already), but shine in those where fast processing is not taken for granted today...

future games are going to become multithreaded over times, but what this would demand is ridiculous. you would need seperate threads for audio, graphics rendering, graphics data, physics, the game server, the client, input, disk access, network, etc etc. the thread syncronization issues would be a bitch, and it would be very touchy in terms of performance. the positive side is that if you wanted to do it, you could do different threads for each audio stream, and quite possibly one for each model that is being rendered.

So...let the programmers learn

P.S. I think I would be much more sceptical about cell if it was only made by Sony & Toshiba...but this has also IBM behind it...

[Marshmallowman]

I have a feeling we will be seeing a lot more parallelisation everywhere.

Simple fact is silicon really is very close to operational limits, hence dual core from AMD and intel.

Programmers will have to program differently, or maybe compilers have to compile differently but either way concurrent processing will be the way of the future (for a while at least)

[Wombat]

No, not really. I've worked on multi-core processors. The thing is, many, many tasks cannot be parallelized. People are already optimizing the hell out of things that they can, but some things are atomic and/or serial.

"Silicon is really close to operational limits" has been said every day since around 1997.

[spadnos]

Originally posted by DGhost
even if it was broken down into stages, each APU has to wait until the APU working on the preceeding stage is done. if the input is not a constant, it *has* to wait until the value is computed before it can operate on it. The only exceptions of this is when using branch prediction, and even then it generally only operates on cases where there are only two branches - ie, true/false pairs.

most of the APU's would still sit idle because you cannot get around that fact.

If you have a task that can be split into stages that take roughly equal time to compute, then this "sequential parallelism" would be a great boon. N processors won't speed things up by a factor of N, but you might get 0.8N. With 8 or 16 processors on a chip, you can get pretty good increases in overall computation speed even with idle time on several APUs.

it would have to be running very computational intensive tasks that can be easily executed in parallel to itself for it to even come close to it's full potential. think encryption, video encoding/decoding, rendering, etc. the end result is that the Cell architecture needs to be running lots of different intensive tasks at the same time for it to yield anywhere near the level of performance that article hypes it up to be.

future games are going to become multithreaded over times, but what this would demand is ridiculous. you would need seperate threads for audio, graphics rendering, graphics data, physics, the game server, the client, input, disk access, network, etc etc. the thread syncronization issues would be a bitch, and it would be very touchy in terms of performance. the positive side is that if you wanted to do it, you could do different threads for each audio stream, and quite possibly one for each model that is being rendered.

Consider the other part of many games - the AI for computer characters. Imagine an LOTR game that simulates the epic battles (like they did with MASSIVE for the movies) - each of thousands of actors makes its own decisions based on its situation (with something more complex than "head for the player and kill him" logic), and is rendered with high polygon counts, all in realtime.

It would be pretty damn cool. There are a lot of places to find parallelism, it's a matter of finding the right split for the particular architecture.

A similar set of decisions are made for splitting processes in multi-threaded apps - on Linux, a separate process is pretty lightweight, so you don't have to make multi-threaded apps, you can just spawn several copies (with a shell script or similar). On Windows, creating a separate process is huge compared to a thread, so it's generally more efficient to make applications take care of their own threading.

If the Cell processor can change the rules enough, then the optimal answers may be way different than what we "know" now, and the speedups may be impressive.

Or not. YMMV

- Steve

[Jammrock]

By the time silicon becomes obsolete someone will have created something smaller, faster, better. Maybe carbon tubing, or some variation, will take over.