How many developers are using all 3 cores for X360?

[scooby_dooby]

The guy was talking about the difficulties in working with multithreading, saying "Doing physics on one core" seems like such a relatively easy thing to impliment to many, but in practice - it's really, really challenging.

He wasn't talking about harnessing all cores but giving an example that even something 'relatively straightforward' as moving the physics onto a seperate core isn't easy. And he said it was less easy on PS3. He wasn't talking about the difficulties in writing for SPEs, but the difficulties in multithreading, and so presumably his observations on PS3 are 'it's harder to multithread on Cell'. It'd be a pointless comment if what he meant was 'multithreading is hard. Even moving one thread like physics onto a separate core isn't easy. And PS3's SPE's are a pain to write for.' In that case the comment on PS3 is totally out of context. Ergo he's commenting on the increased difficulty in parallising workloads on PS3, and I don't know why that would be harder. Unless perhaps his concerns were the memory management? But it's expected XeCPU needs pretty low level management to so I still can't see any difference in inherant difficulties to getting the two systems to multithread.

You quoted WHAT was hard, but ignored the WHY.

"it's really challenging to have different code running on different processessors simultaneously, keeping it all in sync, and then debugging/optimizing on top of it all... looking at a 6-part call stack (one per thread) is NOT a trivial, non-intimidating reality to debugging for any developer that's going to actively use all 6 threads."

The point is, the more threads you have going on the harder and harder synchronizing that data besomes, and the longer and harder it becomes to debug.

By increasing thread by 50%, from 6 to 9, it's obviously going to be that much harder to keep everything synchronized and in check.

THink back to Gabe's comment about how one line of code could kill the entire engine, and the debugger tells you nothing! Now picture that with code running on 9 different logical processors! Debugging must be ridiculously hard when you try and have 9 threads purring at the same time.

 

[Mefisutoferesu]

Gabe's never even touched multi-threaded code. He's no more a judge than I am with my college education. Well, OK, I'm overestimating my worth, but you understand what I'm saying.

That said. You're again missing the point. All things are NOT equal. The implementation of multi-threading on the PS3CELL is not equivalent to the XeCPU implementation. More over as ERP said, we've no real definition of what "easier" is. Remember, more is always better NOR harder. Until we have a better understanding of how devs are threading things we can't say it will or won't be harder.

Personally, from my view the CELL design seems more naturaly oriented towards multi-threading. Wheather that translates or not, who knows.

 

[scooby_dooby]

Of course he's touched multi-threaded code, that's a compeltely ridiculous assertion. Did you forget the interview where he spoke of multi-threading his game engine, and seeing a 50% imrpovement?

You're probably thinking of the interview, where he put himself in the shoes of a junior programmer, and said something to the effect of "I've never touched multi-threaded code before...etc" He didn't mean the he, himself, had never done any! Just that the vast majority of his team, and junior developers have little to no experience, and he was speaking from that perspective.

Sure all things are not equal, but the X360 cores are the MORE flexible, so I really don't see how the Less flexible, SPU's, which there are 7 of, plus the addition of a dual threaded PPU core, is NOT going to be quite a bit more tedious to work with than 6 threads on 3 identical general purpose Cores.

I think Sony would like you to believ that, but if it's really the case then that basically means CELL is superior to everything out there, not only is the potential sky-high, but it's actually EASIER to multi-thread for than a convential approach. I don't buy it.

As for coming up with a metric, that's sort of impossible isn't it? We could come up with any metric in the world and it couldn't be proven or tested against. Basically it comes down to how much TIME will it take developers to create bug-free multi-threaded code, how that work required factors into the overall project timeline, and budget, and in the end will determing how much power they can pull out of a system in the time/budget that they have available.

So the metric would be time/budget required to produce equivalent results on both machines, i.e. all processors running simultaneously, which we have absolutely no way of comparing.

 

[Mefisutoferesu]

Yes, that's the interview I was thinking of. I recalled it as him speaking for himself and the team, sorry.

That said though, has Gabe had time to actually work with both PS3CELL and the XeCPU? Yes, multi-threading on a PC is a pain in the butt according to Gabe, but what's multi-threading like on the consoles? I can see the Xbox being a somewhat similar experience, but not CELL. Unless he's actually had time to check it out, he isn't the authority on CELL multi-threading by a long shot.

Felability does not equal ease of multithreading. By that logic it's even easier to multithread on the new P4 or AMDs, not necesarily true.

An deven if it turned out that CELL was indeed easier to multi-thread that doesn't mean it's superior to everything out there. It barely makes it into the top 500 super-computer list, and only technicality (more powerful per core, not overal). Besides, do you have any reason to prove it's not? Think about it, the 1st idea to come to ones head with multi-threading is to just stick a bunch of more core on. Sony was even presented this idea, yet they chose not to. THere must be abenfit somewhere. More over, just because CELL might be better for multi-threading doesn't make everything all sunny-sunshine... double-edged sword as someone said.

As to a metric, I'm not even going to pertend to try and come up with one. Not enough skill in my part, but again. If we're talking as you say then the PS3 will only be required to multi-thread 6 threads, so 2SPE and 1PPE. However, what's wrong with that? Well, a lot of power goes to waste, so you more SPE in and all of a sudden it's not a fair fight. Just random thought on my part.

 

[scooby_dooby]

Well when he spoke about how the SPU's are very prone to bad code, or stalling out, and how the debugger was virtually useless to find the problem, which required a senior programmer to come in and sort it out. It sounded like he was speaking frm direct experience.

And we know he is developing on X360.

So I'd say yes, he knows what he's talking about. He may not be some super-freak japanese wizard programmer like some of the PS2 dev's, but he at least has experience with both systems. And his comments make the PS3 sounds anything BUT easy!

Also, I'd assume it would be much easier to multi-thread on a curren P4 or A64, because even if the actual splliting of the code, or overall dissemination of the code was more complex(less obvious), the fact you only need to synchronize a mere 2 threads would make debugging much much easier. just a logical guess on my part though,

 

[Guden Oden]

Sure all things are not equal, but the X360 cores are the MORE flexible, so I really don't see how the Less flexible, SPU's, which there are 7 of, plus the addition of a dual threaded PPU core, is NOT going to be quite a bit more tedious to work with than 6 threads on 3 identical general purpose Cores.

"More flexible" and "less flexible" are really non sequiturs in this case, the SPUs are not less flexible than the xCPU cores, they just work differently.

Besides, you don't have to spin off 7 threads on cell to run stuff on all SPUs, you could run just ONE thread sum total on all SPUs by handing off partially computed results from one SPU to the next via the internal bus. That's why people said threading works differently on cell, something you happily ignored trying to prove a somewhat flawed point.

Both chips try to combine high computational ability with low manufacturing cost, which invariably's going to mean compromises, and they both compromise in different areas. Neither's going to be free of bottlenecks, and there's really no point in trying to glorify one over the other. Especially when we have no identical software running on both platforms to use as some kind of basis for an objective comparison...

 

[mckmas8808]

Scooby you are confusing me here. First you say this.

As for coming up with a metric, that's sort of impossible isn't it? We could come up with any metric in the world and it couldn't be proven or tested against. Basically it comes down to how much TIME will it take developers to create bug-free multi-threaded code, how that work required factors into the overall project timeline, and budget, and in the end will determing how much power they can pull out of a system in the time/budget that they have available.

But then you say this.

So I'd say yes, he knows what he's talking about. He may not be some super-freak japanese wizard programmer like some of the PS2 dev's, but he at least has experience with both systems. And his comments make the PS3 sounds anything BUT easy!

So are we going to take what ONE dev says and just exclude what anybody else has to say?

 

[Shifty Geezer]

Well when he spoke about how the SPU's are very prone to bad code, or stalling out, and how the debugger was virtually useless to find the problem, which required a senior programmer to come in and sort it out. It sounded like he was speaking frm direct experience.

Has this MS employee also used the Sony PS3 dev kit and found that they too don't have debug resources to find these problems? Ease of developing mutlithreading code involves a lot more variables than just how many cores/threads there are. The presence of more threads on Cell may present more chance for things to get difficult with synchronisation etc., but as it works differently that may not really be the case.

Though symmetrical cores offers the possibility of lifting code from one core and dropping it into a new thread, which is perhaps easier then developing an Apulet to do the same and maybe offers a 'quick fix', designing true multithreaded games fro the ground up is still going to need the same considerations across the platforms.