PS3 issues with programming, why not put 1 program per chip?

[oROEchimaru]

Often during the development, new reports say it is more difficult to program for the ps3 since it uses a cell ship, and 8 of them... meaning programmers have to adjust to program for multipchips and a new language (however hopefully this pushes the demand for multi-core applications)...

anyways... why not program the software to run applications on seperate cores, rather then stringing the cores together for each application?

In theory, each application could ber faster with 8 cpus working on each one... but, if each cpu has 1 program... then there is less time with queing... i am not sure how much cache they have on each chip either.

however this would only apply to o/s type software... not games. what i mean is, have one cpu working on browser, one on media, one on messanger, one on file software, then the other 4 aimed at the o/s...

if they are going to make a home pc like system in the future (which it seems this is sony's plan with the ps3)... why are they choosing to multicore simple software?

 

[Demon_of_The_Fall]

The PS3 does not have 8 cores.

It has 1 normal Power processor and 7 or 8 "SPE"s. These SPEs are not proper processor cores and require a real processor to feed them stuff to do.

Also, your idea of dedicating each core to a separate app is entirely pointless. One of the main ideas in having an OS is that it handles allocating your CPU time for you. People who talk about dedicating a core to a task just don't make any sense to me.

 

[oROEchimaru]

hmm... well the reason it makes sense to me... is it would reduce queing time.... 7 fold...

1 task, in each cell... allows you to access the task when needed though at a slower rate.

8 tasks in all 8 cells, means you have to wait to get information from all the chips, not just one... so more delay

but... in the end...when your actually using the software, it is better to have more cpus designated to improve performance.

i am refering to small applications, not something big like a game that would benefit from multicore cpus... but instant messanger, im not sure if it needs 8 cpus... rather then 1 (main) + 1 cell..

 

[Lazn_Work]

The Cell processor used in the PS3 is a beast of a single cpu.

The SPEs in the Cell are not full CPUs, they are glorified MMX/SSE units. So basically you have a G5 CPU with 7 multivec units.. Not 8 cpu's. (FYI to decrease production costs, the Cell that the PS3 uses was cut back from 8 SPEs to 7 SPEs, only 6 of which are available to developers, one is reserved by the OS for itself)

These SPE's are totally incapable of running a program by themselves. They can't even do a memory request, so how can they possibly run a program that interacts with the network, a much more complex task (like an instant messenger) when they can't even read memory by themselves.

Here is some good info for you: http://en.wikipedia.org/wiki/Cell_(microprocessor)

 

[defakto]

Also, it's important to note that programming in an smp environment (not refereing to the ps3 architecture here, but smp in general with dedicated processors) is much more difficult because multiple threads need access to the same information. The problem lies when on is accessing and one it changing. SMP adds a lot of complexitity, it's finally getting to the point where games are supporting multiple cores more and more, but there are previous games, quake 2 for instance, that had smp, but removed it due to stability and performance issues.

 

[IanG]

Also, it's important to note that programming in an smp environment (not refereing to the ps3 architecture here, but smp in general with dedicated processors) is much more difficult because multiple threads need access to the same information. The problem lies when on is accessing and one it changing. SMP adds a lot of complexitity, it's finally getting to the point where games are supporting multiple cores more and more, but there are previous games, quake 2 for instance, that had smp, but removed it due to stability and performance issues.

Yeah, this is the main problem with multithreading as I understand it. You could run 7 separate programs, but what if one of those programs needs a piece of information from another program? It has to wait for it, so is sitting idle. Now what if it wants an updated piece of information from another program (for simplicity, say the location of a target you're shooting at.) It could look it up in memory, but what if the other program hasn't updated that information in a while? It'd be pulling bad data, so although it looks like you'd make a headshot, you really miss.

This is just one problem, and part of the reason I'm glad to not be a professional programmer. If it was really that easy, people would already be doing it.

 

[defaultluser]

jroe52, let's clear things up.

The real question you are asking is: why are we moving toward multi-core chips when you can only parallelize a subset of operations you normally perform on your PC / game console?

The reason is: up until now, we've been able to add complexity to the hardware (called Instruction-Level Parallelism, which is the measure of dependencies between multiple sequential instructions). ILP allows modern single processor cores to execute three or four instructions per clock cycle for a single task. ILP manages many dozens of instructions in-flight at once, all to improve thoroughput and get around data dependencies.

There's only one problem: the hardware complexity required to add additional execution pipes is incredible once you reach a certain threshold, and the performance improvement goes down because you can only find so many independent instructions that you can re-order.

So, the solution is to use multiple processor cores, and move the problem out of hardware and into software. Unfortunately, that's not a good solution either, because only certain kinds of problems can take advantage of all that parallel processing power. But it is the best solution because software and memory are relatively cheap, whereas complex hardware is always expensive.

Software: expensive to design and implement. Cheap to copy.

Hardware: even more expensive to design and implement, expensive to manufacture and test each chip.

Once people learn the tricks of the trade, we will see more benefit from multiple cores. Until then, theses multi-core behemoths are mostly marketing gimmicks. At least be thankful that all your major operating systems are already multithreaded, or else this would be even less beneficial.

 

[note235]

beneficial post

 

[object88]

There's only one problem: the hardware complexity required to add additional execution pipes is incredible once you reach a certain threshold, and the performance improvement goes down because you can only find so many independent instructions that you can re-order.

Sorta. The real problem comes in branching and heat. The hardware has to guess which condition will succeed, and start sending instructions based on that branch. If the guess is wrong, not only are the post-branch instructions wasted, but the pipeline has to refill from the alternate branch. This is what effectively killed the NetBurst architecture (with its 31-instruction deep pipeline)-- the pipeline also required a huge cache and logic overhead, creating heat problems. A longer pipeline only benefits if the time spent in actual stages in the pipeline is shorter, so you have to raise the clock, again, creating heat problems.

If you keep the pipeline relatively shallow (which AMD did), you alleviate many of these problems (even with a slower clock).

So, the solution is to use multiple processor cores, and move the problem out of hardware and into software. Unfortunately, that's not a good solution either, because only certain kinds of problems can take advantage of all that parallel processing power.

Don't drink the Kool-Aid. Any program that has a GUI can take advantage of parallel processing. Which is a freaking huge number of applications. All BeOS applications had at least two threads-- one which handled GUI tasks, and the other which handled logic. That's why BeOS applications rarely had GUI freezes, even when the CPU was chugging away at full tilt.

And there's no reason why applications for other OSes can't do the same. I'm a Windows developer, and even my simple applications are multi-threaded for exactly that reason.

On top of GUI applications, consider any application which handles requests (databases, web servers, file servers, etc.). Then add compilers, graphics rendering engines, and so forth. Plus your number-crunchers (Folding, Seti). The number of applications which don't benefit from more than one processor is small. Say, command line applications like "dir" / "ls". Hell, even command-line applications such as "grep" can benefit, if they're operating on more than one file at a time.

... but what if one of those programs needs a piece of information from another program? It has to wait for it, so is sitting idle. Now what if it wants an updated piece of information from another program ... It could look it up in memory, but what if the other program hasn't updated that information in a while? It'd be pulling bad data...

This is just one problem, and part of the reason I'm glad to not be a professional programmer. If it was really that easy, people would already be doing it.

People are doing it. There are a wide variety of synchronization and data locking techniques available, which have been around in the CPUs and OSes for years.

What is not easy is making it ultra fast-- as in bleeding edge fast. And that's a very small set of applications, such as highly detailed large scale real-time simulators. If you're not real-time, the application just runs a little slower, and you have to wait an extra few seconds for synchronization overhead on top of hours of actual processing time. These types of applications (i.e., Castle Quakenstein 17: The Doom Of Carmack) are actually a relatively smallish set of overall applications.

Please, continue thinking this is a hard problem to solve. I won't have to worry about you competing for my job, and I'm not even a game developer. Parallelism and finding use for multiple CPUs and threads is easy, and has been in use (in mainframes, for example) longer than personal computers have been around. Getting people to recognize its usefulness seems to be the problem.

And yes, I am having a shitty day, thank you.

 

[RogerTheEngineer]

Excellent post, object.

I'm also a programmer, although not on your level, and I've often wondered why so many people complain about difficulty in multithreading. It takes a bit of thinking to break down tasks, but the payoff in the long run is great. I've thought for a while that people are just too lazy to make the change, and now I'm starting to think that I may be right.