ps3 easier to program for

[RancidWAnnaRIot]

Okay.. so what you guys are saying is that the Cell is very good at doing floating point math??

cause isn't that what DSP and physics chips are all about?? crunching floating point numbers??

 

[steviep]

Firewall, you couldn't be more than right. If the PS3 sells like hotcakes, even if it's a HUGE pain to develop for, developers see the money and learn it. But that requries the PS3 to sell like hotcakes.

But Slarti WAS right.

PS1 = dream to develop for
PS2 = big pain in the ass, but 100 million sold = developer support regardless
PS3 = bigger PITA, no way around it... middleware can improve that, but still PITA

So Sony really has to sell a lot of these things, or they WILL be in trouble this round.

 

[Slartibartfast]

Says who, you? I think there a lot more games available for the ps2 than there is for the ps1.

Says pretty much everybody, I've read that all over the place.

 

[Firewall]

eh, I stand corrected.

If they sell (which we all know they will), there will be nothing to worry about for sony fans.

It will be interesting though. Can a big price tag combined with competition from the 360 and nintendo combined with pain in the ass coding be enough to bring Sony down a notch or two? This should be what is up for debate and why.

 

[masher]

developers will have to cram all their game control, AI, and physics code into at most two threads...

Ah, this is where you got the little factoid about SPE's not being suitable for physics? As I've already shown, this is flat-out wrong. They will run physics ideally, and AI at a somewhat lower efficiency.

Don't bother suggesting that the PS3 can use its SPEs for branch-intensive code, because the SPEs lack branch prediction entirely.

SPEs lack branch prediction for a very good reason. Why does a normal cpu require it? Because current cpus have ultradeep pipelines with heavy latency, thus unpredicted (or mispredictd) branches cause costly stalls. The SPEs, however, have a short low-latency pipe and therefore don't have nearly the need for prediction.

SPE's still have a somwhat costly 18 cycle misprediction penalty. However, given their branch hinting support (which is often more effective than traditional branch prediction), and the fact that most SPE code will be loop unrolled (removing the majority of the branches), it won't impose a performance hit on the types of code the SPE excels at.

For branch heavy code that a) can't be unrolled and b) can't be hinted, the SPE will execute poorly. But it still runs..but with 8 cores running at once, the Cell has power to burn. Remember that Pentium-class cpus execute physics and multimedia code poorly...it doesn't stop them from running it.

 

[theNoid]

Due to the complexity of the Cell processor, its going to be MUCH more difficult to develop on. The GPU on the PS3 = 7800, and quite honestly.. nothing special so that will make things a bit easier. But ... the 360's chipset design is much much easier to develop on.

Nearly every developer has said this, accept those with Sony in their wallets.

 

[steviep]

Somewhat lower efficiency? Somewhat? That's a complete understatement. They are not "ideal" for physics, either, since physics code is quite branchy as well, and there is a very poor branch misprediction penalty on them. Can it run both? Yes, but it requires a lot of work, for not a lot of gain. Mark my words, the majority of game code on most titles (especially multiplatform titles) will run on the single PPE, on both the PS3 and the X360, since both main CPU's are essentially the same. 1st or 2nd party titles may be different, but the majority of 3rd parties won't bother with the SPE's, since they are quite inefficient for many things. They will help with media/graphical applications nicely, though, as they are far more ideal for that function. There's a reason, however, that Sony had to quickly ask NVidia to slap together a GPU for the PS3.

 

[|MaguS|]

Due to the complexity of the Cell processor, its going to be MUCH more difficult to develop on. The GPU on the PS3 = 7800, and quite honestly.. nothing special so that will make things a bit easier. But ... the 360's chipset design is much much easier to develop on.

Nearly every developer has said this, accept those with Sony in their wallets.

Actuall many developers agree that the Cell is easier to code for then the PS2, Is it harder then teh xbox and x360? Yeah but its easier then the PS2 which usually requires the programmer to use Assembly which the PS3 does not require at all.

The PS3 also has great documentation and middleware from the start which the PS2 did not.

 

[masher]

Somewhat lower efficiency? Somewhat? That's a complete understatement.

An SPE suffers from an 18 cycle misprediction penalty, the P4 Prescott suffers from a 30 cycle penalty. Branch-heavy code is rarely more than 10-20% branch instructions. An SPE predicts correctly roughly 50% of the time, a Prescott predicts correctly 95+%.

Work the math. You'll find you're quite wrong. On branch-light code, SPEs peform far better. On branch-heavy code, moderately worse. Multiple SPEs, though, will outperform a single core, even on the most branch-heavy code known.

They are not "ideal" for physics, either

I've been doing computational physics since graduate school. A SIMD based vector processor such as the Cell is ideal for most physics simulations. In fact, many algorithm libraries simulate such a model in software, effectively turning traditional cpus into a Cell-like architecture.

Computational physics on a Cell processor doesn't simply outperform a traditional cpu...its an order of magnitude or more faster. The only thing known to outperform this architecture are algorithmically-customized ASICs.

 

[Axoman]

I've been doing computational physics since graduate school..

So the computational physics you work on is exactly the same as in game physics?

 

[Slartibartfast]

The only thing known to outperform this architecture are algorithmically-customized ASICs.

mmmm....algorithmically-customized ASICs....

Uh, I need to go change my pants now.

 

[steviep]

Since they're so great with "computational physics", we should all ask Aegia to switch the design on their PhysX card to a cell based CPU. Hell, why not put them in our desktops? Oh yeah, it's because they are horrible general purpose CPUs that would get eaten alive in most areas by any current Intel or AMD CPU.

On branch-light code, SPEs peform far better. On branch-heavy code, moderately worse. Multiple SPEs, though, will outperform a single core, even on the most branch-heavy code known.

Yeah, and how many programmers do you think will be using 7 SPE's? As you said, on their own, the SPE's perform "moderately worse" (I'd say a lot more than moderately) in any branch-intensive code. And what kind of code is branch-intensive? That's right, physics and AI... 2 of the core components to any game.

 

[Charles]

When the developer finally talks about the important bits, the pseudo C code for the Cell, he basically says "If you can do 8 threads on a PC you can do it for Cell"... Well DUH? Of course you CAN utilize the entire cell . The hard part is actually doing the 8 different threads.

Well, all modern PC CPU's handle 4 threads...

And that's all he's saying. That it's about as easy to program for the PS3 as it is for a PC.

And if you say that's hard, what are you doing programming if you can't even make a program that makes full use of my 2 year old hyperthreading processor? Take a course at IT tech for heaven's sake.

 

[Charles]

So the computational physics you work on is exactly the same as in game physics?

Probably not. It's highly likely that computational physics is much more complicated than game physics. Hence, if 7 SPE's can do graduate level physics well, they will mow down game physics.

And if somebody says something about "well game physics may perform WORSE than computational physics." If that's the case, then I'm sure Epic et al would start doing the more complicated computational physics to get better performance.

 

[Slartibartfast]

Well, all modern PC CPU's handle 4 threads...

The only modern desktop cpu that handles 4 threads are the dual-core intel's with hyper-threading, and just because it can doesn't mean anything uses it. Multi-threaded games are pretty much non-existant, and most multi-threaded apps have to do with rendering (just ask the smp forum about it). The OS can have different processes/apps run off of different cores, but multi-threaded apps aren't exactly commonplace.

 

[steviep]

Actually, the way that the PPE in the Cell and the Xenon handles multiple threads is quite different from the way a P4 would... This article refers a lot to the Xenon's PPE, but it is essentially the same CPU as the main core in the Cell, so for all intents and purposes we are also talking about the Cell's main PPE here (the X360 just has 3 of them instead of 1 + 7 SPE's, with more cache than the PS3).

The basic idea behind both Cell and Xenon is to make the execution core less complex by stripping out hardware that's intended to optimize instruction scheduling at runtime. Neither the Xenon nor the Cell have an instruction window, which means that these two processor designs largely forget about instruction-level parallelism. Instead, instructions pass through the processor in the order in which they're fetched, with the twist that two adjacent, non-dependent instructions are executed in parallel where possible.

This static execution scheme is pretty much the same one used in older, less complex designs, like the original Intel Pentium. Static execution is simple to implement and takes up much less die space than dynamic execution, since the processor doesn't need to spend a lot of transistors on the instruction window and related hardware. Those transistors that the lack of an instruction window frees up can be used to put more actual execution units on the die.

Of course, you can't just eliminate the instruction window and replace it with more execution units without doing something to make up for the lost instruction window. The whole point of an instruction window is to complement an increased number of execution units by extracting more instruction-level parallelism. So in order to take advantage of a large number of execution units without an instruction window, you have to rethink how you organize the processor.

...This TLP strategy will work extremely well for tasks like procedural synthesis that can be parallelized at the thread level. However, it won't work as well as an old-fashioned wide execution core + large instruction window for inherently single-threaded tasks. In particular, three types of game-oriented tasks are likely to suffer from the lack of a out-of-order processing and core width: game control, artificial intelligence (AI), and physics. Each of these three tasks tends to be relegated to a single thread, and each tends to have some inherent ILP that can be exploited by a large instruction window and a robust, multipipeline integer execution unit.

...The Xenon's 1MB L2 cache is much smaller than what you'd expect for a three-core CPU; ideally, the more cores you have sharing a cache the larger you'd like it to be. In fact, it's even more accurate to say that the more simultaneously running threads you have sharing a cache the larger you'd like it to be, and in this respect the Xenon's 1MB L2 looks even worse. Each of the Xenon's cores is two-way multithreaded, which means that up to six threads will have to share the same 1MB L2 cache. However, there are two good reasons for the relatively small size of the Xenon's L2.

...Rumors and some game developer comments (on the record and off the record) have Xenon's performance on branch-intensive game control, AI, and physics code as ranging from mediocre to downright bad. Xenon will be a streaming media monster, but the parts of the game engine that have to do with making the game fun to play (and not just pretty to look at) are probably going to suffer. Even if the PPE's branch prediction is significantly better than I think it is, the relatively meager 1MB L2 cache that the game control, AI, and physics code will have to share with procedural synthesis and other graphics code will ensure that programmers have a hard time getting good performance out of non-graphics parts of the game.

Furthermore, the Xenon may be capable of running six threads at once, but the three types of branch-intensive code listed above are not as amenable to high levels of thread-level parallelization as graphics code. On the other hand, these types of code do benefit greatly from out-of-order execution, which Xenon lacks completely, a decent amount of execution core width, which Xenon also lacks; branch prediction hardware, which Xenon is probably short on; and large caches, which Xenon is definitely short on. The end result is a recipe for a console that provides developers with a wealth of graphics resources but that asks them to do more with less on the non-graphical side of gaming.

 

[JAW]

quake 4 and cod2 just finally got "beta" support for HT/Dual Cores. (2 threads)

WTH is writing 8 threads in the game industry?

yea quake 3 had smp support, but when enabled it wasn't anything to get excited about.

 

[Charles]

Since they're so great with "computational physics", we should all ask Aegia to switch the design on their PhysX card to a cell based CPU.

Cell based CPU's are better general purpose CPU's than the PhysX card is. You can program AI/game control/graphics on the Cell while PhysX only does... well... PhysX.

Hell, why not put them in our desktops? Oh yeah, it's because they are horrible general purpose CPUs that would get eaten alive in most areas by any current Intel or AMD CPU.

Well, actually they'd probably stomp all over AMD/Intel CPU's based on various media processing benchmarks (which is what most people use their desktops for these days... and if you say it's going to word process slow... well... ok fine) But the main reason we won't put them in our desktops is because there's no community support for it. We're more likely to see them in proprietary hardware (Cell phones etc, pun not intended).

Yeah, and how many programmers do you think will be using 7 SPE's? As you said, on their own, the SPE's perform "moderately worse" (I'd say a lot more than moderately) in any branch-intensive code. And what kind of code is branch-intensive? That's right, physics and AI... 2 of the core components to any game.

I dunno. If I were programming for the PS3, I'd use the 7 SPE's. I mean, when I program for multithreaded computers (aka, pretty much all computers nowadays) I use as many of the threads as they'll let me have. In my CG lab when we do realtime graphics simulations, we have an ancient render farm with 50 PIII 800 mhz cpus. I'm allotted 12 for my simulations and I wish I had more. They really burn time off of the runs.

 

[steviep]

Media processing, sure. That's what Cell does well. I can play my movies and process my textures nice and fast. But try running Windows and you'll see how quickly it chokes, even if it is properly ported. As I said, a game is not just graphics processing, there is a lot more going on that makes the game fun. AI, game control, and graphics can be done better and easier on any of today's out-of-order CPU's with dynamic execution (i.e. P4/AMD) than it can be done on the PPE's in the Cell/Xenon. What the PPE is good for is media processing, as you said. Anything else, it's quite inefficient. To quote some game developers on the 3.2ghz PPE: "it performs like a 1.6ghz chip on unoptimized code" (see Quake 4 for the X360 for a good example of unoptimized code and how well it runs).

You must be the only programmer in the world who wants to meet EA's deadlines to make a game on 8 threads, right?

 

[masher]

So the computational physics you work on is exactly the same as in game physics?

Good question. I haven't coded any games, but physics is physics. I would expect the most common use of in-game physics to be n-body kinematics, rigid-body dynamics, possibly some simple fluid dynamics, and collision detection. All of these save the last are highly suited to a Cell-type architecture.

Since they're so great with "computational physics", we should all ask Aegia to switch the design on their PhysX card to a cell based CPU.

Are you intentionally being dense? Aegia built a custom ASIC; physics algorithms are hard-wired into it. It can't be programmed for other tasks...but for the ones its built for, its untouchable. Cell SPEs are programmable for all tasks...but they shine in certain areas.

Ultimately, a "Cell-type architecture" will mean just this. 20 years from now, your typical desktop CPU will have a thousand or more cores...many of them customized for specific tasks, rather than being general-purpose processors.

WTH is writing 8 threads in the game industry?

You realize, of course, that you're not required to use all the SPEs in the Cell. Furthermore, you don't need to spawn independent asynch threads to use them all. SIMD. Single Instruction, Multiple Data. In the massively parallel machines I've used in the past, you could set a single-threaded simulation that would use all 1000 processors; the division was done automatically at the compiler level. I can't imagine Cell being any different.

 

[prozpris]

Where do people get such misinformation?

This board seems full of people who seemingly spout off nonsense with the thinking that people don't bother to fact-check. Unfortunately, your real-world knowledge and education on this subject is no match for them.

 

[Slartibartfast]

This board seems full of people who seemingly spout off nonsense with the thinking that people don't bother to fact-check. Unfortunately, your real-world knowledge and education on this subject is no match for them.

*pries prozpris' lips from masher's butt*

 

[prozpris]

*pries Slartibartfast's lips from steviep's butt*


Now we're both free

 

[Slartibartfast]

*pries Slartibartfast's lips from steviep's butt*


Now we're both free

LOL I'm not that bad, am I??

 

[prozpris]

LOL I'm not that bad, am I??

No you're not. I actually think you are a good poster. But we're hijacking this thread. lol.

 

[Slartibartfast]

No you're not. I actually think you are a good poster. But we're hijacking this thread. lol.

haha thanks, no offense with the first one btw, I just can't resist an opportunity to be a smartass

 

[steviep]

This board seems full of people who seemingly spout off nonsense with the thinking that people don't bother to fact-check. Unfortunately, your real-world knowledge and education on this subject is no match for them.

Yeah, like AnandTech and ARSTechnica (where I've read, and quoted) are a huge source of misinformation. I'd just as easily trust them far more than I trust some dude who claims to know it all on a forum.

 

[prozpris]

Yeah, like AnandTech and ARSTechnica (where I've read, and quoted) are a huge source of misinformation. I'd just as easily trust them far more than I trust some dude who claims to know it all on a forum.

I do not doubt the validity of your sources, as I too read those sites. I do doubt people who suddenly think they are experts on a subject because they've read a few articles.

 

[steviep]

Please show me where I claimed that I was an expert. I have no doubt that you'll have trouble locating that sentece. I didn't have to look hard to find others who claimed they were experts, though. And that's where the beauty of internet forums lies

 

[OriginalOCer]

From what I gather listening to interviews and reading whitepapers (sometimes just summaries of whitepapers), Both the CELL and Xenon are hard to program for but MS is doing a really amazing job on the devkit and developement enviroment side of things (whereas Sony is being typical Sony and just winging it).

By far the easiest system to program for of the next gen consoles will be the Revolution, which is essentially a PC and just built up from an already well documented platform (the gamecube). It's (supposedly) going to have ONE fast Out-of-Order Processor and one fast GPU. The OoO Proc is going to be what allows the Revolution to compete 5 years down the line.... Hell even Carmack said 'I wish Sony and MS just put in one fast OoO proc and one fast GPU instead of the multicores', Even if the Revolutions CPU is only 1 - 1.5GHz it will hold up surprisingly well.

whoa... went on a bit of a rant there. Bottom line, what I've gathered from people in the know (John Carmack, Gabe Newell, Hideo Kojima, etc.) is that Sony's system is harder to develop for and by MS having a really great developement enviroment it only furthers their differences.

peace,
OriginalOCer

 

[prozpris]

And that's where the beauty of internet forums lies

Yes, they are full of irony.

 

[DukenukemX]

By far the easiest system to program for of the next gen consoles will be the Revolution, which is essentially a PC and just built up from an already well documented platform (the gamecube). It's (supposedly) going to have ONE fast Out-of-Order Processor and one fast GPU. The OoO Proc is going to be what allows the Revolution to compete 5 years down the line.... Hell even Carmack said 'I wish Sony and MS just put in one fast OoO proc and one fast GPU instead of the multicores', Even if the Revolutions CPU is only 1 - 1.5GHz it will hold up surprisingly well.

Which is one of the many reasons why I feel Nintendo may end up on top.

People have said a lot of bad thing about the GameCube and look at these new console systems today. Nintendo first used a PPC CPU and now both Sony and MS use a CPU with PPC cores. Nintendo used a graphics chip made by a professional company and now both Sony and MS seek ATI and Nvidia to make graphics chips.

Though what might hurt Nintendo is how long it'll take them to release their new console.

 

[masher]

Yeah, like AnandTech and ARSTechnica (where I've read, and quoted)

Quoted and misquoted. Your sources are usually correct; it's your interpretation of those sources that is at fault.

Without tool support, Cell will be a difficult processor to code for. This goes without saying. However, your stepping from that into nonsensical statements like "its a pita" or "SPEs can't run physics" is where you stumble.

 

[steviep]

The SPE's will do my laundry for me if I learned how to program that correctly. That's not the point I was trying to make. The point is that according to everybody who is not on Sony's pocketbook, the Cell and its surrounding SPE's are indeed a PITA! That is not nonsensical! I'm not programming on them, so I cannot tell you from personal experience. But neither can you. You can just go by what you read and perceive. I've posted some of what I've read and perceived, and others have done so as well. The general consensus is that the 7 SPE's are NOT very efficient at some of the tasks that Sony claims they will be useful for. There is also consensus that the slow in-order PPE's of the Xenon/Cell are not only a step backward, as Carmack pointed out, but that at least (according to most developers) MS is providing a nicer middleware work environment - as OriginalOCer so elequently put it. Sony needs better dev support, especially if they wany people to USE the SPE's for something. As it stands right now, the multiplatform ports (which will make up the bulk of games next-gen) will likely mostly use 1 core on each system, and that's it. Anything beyond that would likely require too much work, time, and money.

The G5-class OOO PPC CPU inside the Revolution should provide a nice contrast to the ass-backwards PPE's in the other 2 systems, especially if it has a lot of cache in stark contrast to the others.

 

[NulloModo]

The most CPU intensive code in games is graphics, and the GPU will handle that. In modern games the vast majority of the resources go to rendering polygons and textures, the CPU has it easy. BF2 is somewhat CPU limited, but it was just poorly coded.

Physics, AI, and all the rest will be fairly easy for the Cell to handle, and lets face it, no matter how hard it is, developers will learn. It is all about who has the marketshare, MS has it now, but guess what, no one else has a player on the field. The PS name alone will sell millions. The Xbox was better than the PS2 when it comes to tech specs and ease of coding, the PS2 still sold over twice as many units. The Rev will be the easiest to code for, but again, name sells. Like it or not Sony has hands down the best marketing machine in the industry right now, and that is what pushes units. It isn't what machine is best, it isn't what machine is easiest to code for, it is what machine has the most hype behind it.

 

[steviep]

That's the key, Nullomodo. No matter how much we talk about which system is easier... developers will go to where the money is. If that happens to be the PS3, then SPE's be damned, lack of Sony support or documentation be damned, they will teach themselves to program them to do my laundry

 

[masher]

according to everybody who is not on Sony's pocketbook, the Cell and its surrounding SPE's are indeed a PITA! That is not nonsensical!

Calm down. Now who is claiming Cell is a "pita"? In this thread alone, we have programmers from Epic, Volatile, and Guerilla all saying the Cell is easier than they expected. Those are people actually using Cell SDKs today. We also have your quote from Carmack, calling Cell more difficult than Xenon. And a five month old interview with Gabe Newell, complaining about code portability. Both big industry names...but neither with any direct Cell experience. And neither of them calling the Cell "a pita" either.

So where are you getting this nonsense about SPEs not running physics code? Or their inability to run branch-heavy code? Or any of the other stuff you're spouting?

 

[steviep]

Physics code can run on my calculator. I'm trying to suggest that it's not a very practical task to get them to run physics code. Here's ARSTechnica again:

At any rate, Playstation 3 !!!!!!s shouldn't get all flush over the idea that the Xenon will struggle on non-graphics code. However bad off Xenon will be in that department, the PS3's Cell will probably be worse. The Cell has only one PPE to the Xenon's three, which means that developers will have to cram all their game control, AI, and physics code into at most two threads that are sharing a very narrow execution core with no instruction window. (Don't bother suggesting that the PS3 can use its SPEs for branch-intensive code, because the SPEs lack branch prediction entirely.) Furthermore, the PS3's L2 is only 512K, which is half the size of the Xenon's L2. So the PS3 doesn't get much help with branches in the cache department. In short, the PS3 may fare a bit worse than the Xenon on non-graphics code, but on the upside it will probably fare a bit better on graphics code because of the seven SPEs.

 

[NulloModo]

That's the key, Nullomodo. No matter how much we talk about which system is easier... developers will go to where the money is. If that happens to be the PS3, then SPE's be damned, lack of Sony support or documentation be damned, they will teach themselves to program them to do my laundry

Exactly, and you and me, and anyone with half a brain knows that Sony will have the best market share this round. The Sega Saturn comparison earlier hardly fits... the Saturn came off of multiple rounds of Sega failures, the 32X, the SegaCD (which I owned and loved, but it was still a bomb), and the gamegear or whatever Segas handheld was. Sega released too much too fast and didn't stick with it and support it. The PS3 could be a dog, and people will still buy it up. If it truly sucks then they might lose the next round, but I'd be willing to bet my life savings that Sony still as the highest unit sales this round.

The 360 is pretty cool, I would not have touched the original Xbox, but I admit I picked up a 360, despite my MS misgivings (like the OS, but still bitter about IE taking out Netscape which was much better IMO). Hell, since the DOA franchise moved to Xbox I don't really have a choice....

 

[masher]

Here's ARSTechnica again:

Let me quote the conclusion from your link. I'll bold face the relevant parts you seem to have missed:

In short, the PS3 may fare a bit worse than the Xenon on non-graphics code, but on the upside it will probably fare a bit better on graphics code ...​

In summary, Ars Technica rates Cell vs. Xenon a technical draw. So once again I ask-- where are all the experts calling Cell "a pita"?