Xenon , Ps3 , Revolution ...

[London Geezer]

Lazy-ass stupid devs

[Devil's advocate]

Why don't you try then?

[/Devil's advocate]

I gave that up and project manage them instead!

LAZY-ASS!! You're one of those who delegate...

 

[Shifty Geezer]

A change to in-order only requires a change in mindsets. After all, programmers aren't born with an inate understanding of microprocessor structure - it's something they learn. When I did my degree, we learnt Modula2, then a different system in C, then another mindset for assembler and a completely different way of thinking for SML. Devs just need to learn a different way of thinking and designing that, once mastered, will be no more difficult to work with than existing methods (though I'm sure during the change many will spit and curse over why they can't use the way they've always used, what a load of crap this in-order is, change stinks, gimme back my Pentium, oh, hang on, now I see, wow! look at the speed of this thing, and wow, the structure's really logical, why the hell did we stick with OOO for so long, bloody Intel holding us back, always said Pentium was crap.).

I actually have suspicions that human beings are very adaptable...

 

[blakjedi]

blakjedi wrote:

Actually its a 3 dual core PPC in x2

Unless you're a developer/ insider, and know more than most people do, the Xbox 2/Xenon CPU system is *not* 3 dual cores, but a triple-core CPU. that's one tri-core CPU.

1 chip / die, with 3 cores in it.

not 3 dies/CPUs with 2 cores each, and not 1 die/CPU with 6 cores.


you are also confusing *threads* with cores. each core in Xenon CPU can do 2 threads, for a total of 6 threads, but there are only 3 cores, on 1 chip.


that, according to the leaked Xenon document and Xenon block diagram, and most other reports about Xenon CPU.

obviously that could be wrong, or could have been outdated, and maybe things have changed.

but never was Xenon's CPU system going to be 3 CPUs with 2 cores each. that is a BIG misunderstanding.

see, you can only see 3 cores one 1 chip. and btw, the 'VPU' in each core cannot be counted as a core itself. (just to nip that angle in the bud)

the VPUs are VMXs / SIMD units / FP units / AltiVec units, of some sort

(probably equivlanet to Gekko's SIMD unit and the VMX unit within the PPE/PU of the Cell Processor.

That was the best, most congenial explanation I have seen on this board. Thank you muchly and now I 've got it. I really thought it was 3 dual core chips with each core processing one thread. My fault.

 

[Fox5]

Why didn't MS use a Duron? It probably would have performed better since Durons weren't quite as crippled as Celerons. I think 128KB L1 cache plus 64KB L2 cache comes out to the same total cache as a Celeron, but L1 cache is better right?

Vague memory tells me that is, indeed, what AMD had bid as a CPU. Maybe it was an Athlon, but it escapes my memory. The Durons were quite strong, despite the reduced cache. A Celeron was not even comparable, performance-wise (referencing a very old Tomshardware article). It was suggested that there was utterly no compelling reason to pick a Celeron over a Duron, unless you plan to do some extreme overclocking (and 733 Mhz is certainly short of that strategy).

It was nearly in the bag that the XB CPU was going to be an AMD part. However, Intel threw in an offer that could not be ignored, and the rest is history. MS chose cost savings with the Celeron, and AMD's "performance" option was out the door.

I believe a Duron had about equal performance to an athlon at 200 mhz slower than the duron's clock speed. Not sure about the celeron, I think celeron at its worst was the 128KB p4 based celeron compared to a northwood, I think it got about half the performance per mhz, I don't think the p3 celeron was that bad.

 

[ERP]

^^ The point aaaaa00 is trying to make is that desktop CPUs take advantage of out-of-order CPUs because of unoptimised, crappy, spagetti code. But for a specialised games consoles, wasted transistors are not necessarily needed for out-of-order logic in a CPU. Finely tuned code can be crafted for in-order CPUs, thereby saving transistors for cost or increasing them for more performance.

In this case, all three consoles have a good chance of sharing tech from IBMs in-order PPC core for CELLs PPE, Xenons cores and Revs (but without the VMX units, IMO).

You could have finely tuned code on a console, but many devs don't.
Why should quality games be limited because the developers lack the programming talent or will to fight with an architecture?

I've worked on many conversions over the years, and I can categorically say that some of the best games and those people on this board would probably consider technically impressive (i.e. look good) are some of the worst written I have ever seen.

Quality of code and quality of game are rarely related.

 

[jvd]

I believe a Duron had about equal performance to an athlon at 200 mhz slower than the duron's clock speed. Not sure about the celeron, I think celeron at its worst was the 128KB p4 based celeron compared to a northwood, I think it got about half the performance per mhz, I don't think the p3 celeron was that bad.

The duron and the celeron used to trade blows but then the durons got the nforce mobo with ddr and the celrons were stuck on sdr 133 .... so the durons ultimately pulled away . Now which one would be better in the xbox who knows. I would guess that mabye the duron would be slightly faster due to its better fpu performance . But not big enough to make any diffrence.

 

[nelg]

I've worked on many conversions over the years, and I can categorically say that some of the best games and those people on this board would probably consider technically impressive (i.e. look good) are some of the worst written I have ever seen.

Quality of code and quality of game are rarely related.

Clean desk/Sick mind syndrome.

 

[Carl B]

It was nearly in the bag that the XB CPU was going to be an AMD part. However, Intel threw in an offer that could not be ignored, and the rest is history. MS chose cost savings with the Celeron, and AMD's "performance" option was out the door.

Yeah that's how I remember it also. It's very clear in my mind when I was reading about it - it was Internet bubble days and I was part of a start-up in Charlottesville. It was also the time when I began building my own systems and the birth of my anti-Intel'ism.

Anyway, if you remember Athlons were the talk of the town - kind of like a precursor to the Athlon 64 talk of today, pre-Northwood Pentium times. Well, The XBox was being developed around a Duron I believe, but Intel couldn't have this - for Microsoft, seemingly more powerful than ever back then, to choose AMD over it's WinTel partner in crime for it's new gaming console - that would have been the ultimate endorsement to the PC gaming community and perhaps consumers in general, "When it comes to our own sh*t, we choose AMD."

So, Intel lobbied hard hard hard, gave them an unbelievable deal, and got their chip in the XBox.

But regardless, I think that's a big reason behind why NVidia was ready to go in the chipset market with AMD so soon after - they had already done all their R&D for the Athlon/Duron with the XBox NForce, why waste it?

 

[ILUVMATH]

I believe a Duron had about equal performance to an athlon at 200 mhz slower than the duron's clock speed. Not sure about the celeron, I think celeron at its worst was the 128KB p4 based celeron compared to a northwood, I think it got about half the performance per mhz, I don't think the p3 celeron was that bad.

The duron and the celeron used to trade blows but then the durons got the nforce mobo with ddr and the celrons were stuck on sdr 133 .... so the durons ultimately pulled away . Now which one would be better in the xbox who knows. I would guess that mabye the duron would be slightly faster due to its better fpu performance . But not big enough to make any diffrence.

Well we have the Celeron M, which clock for clock is much faster than a Duron, so not all Celeron are slow per clock.

 

[jvd]

Well we have the Celeron M, which clock for clock is much faster than a Duron, so not all Celeron are slow per clock.

got a link to that chip ?

 

[ILUVMATH]

Well we have the Celeron M, which clock for clock is much faster than a Duron, so not all Celeron are slow per clock.

got a link to that chip ?

I am refering the Dothan/Banias Celeron M, with 512/1MB of L2 cache.
They also beats the Barton XP clock for clock, they are not much slower than the Pentium-M and the 1MB celeron M is about as fast the Banias Pentium-M.

http://www.intel.com/products/notebook/processors/celeron_m/

 

[Urian]

If my memory doesn´t fall to me in 1999 the x86 CPU had the next performance.

Pentiium3 100%
Celeron 60%
Duron 90%
Athlon 110%

 

[Fox5]

I believe a Duron had about equal performance to an athlon at 200 mhz slower than the duron's clock speed. Not sure about the celeron, I think celeron at its worst was the 128KB p4 based celeron compared to a northwood, I think it got about half the performance per mhz, I don't think the p3 celeron was that bad.

The duron and the celeron used to trade blows but then the durons got the nforce mobo with ddr and the celrons were stuck on sdr 133 .... so the durons ultimately pulled away . Now which one would be better in the xbox who knows. I would guess that mabye the duron would be slightly faster due to its better fpu performance . But not big enough to make any diffrence.

Well, xbox has ddr ram, but I believe it has very poor latency compared to PC ddr.

BTW, I noticed that the Deus Ex box has an AMD Athlon logo on the bottom(right next to a 3dfx logo).

Well we have the Celeron M, which clock for clock is much faster than a Duron, so not all Celeron are slow per clock.

I wouldn't say that quite counts, as the Celeron M is basically equal to the top of the line Pentium 3 ever released, even better since it uses DDR ram and has other tweaks.
A celeron M compared to a Sempron(athlon 64 based) might be a more equal comparison.

BTW, from some early benchmarks I saw(when the P-M's came out), the athlon xp with 512KB cache typically had a healthy lead over the Celeron M and Pentium 3 with 512KB cache.

 

[Megadrive1988]

blakjedi wrote:

That was the best, most congenial explanation I have seen on this board. Thank you muchly and now I 've got it. I really thought it was 3 dual core chips with each core processing one thread. My fault.

heh, no problem. ahhh... I hope you did not concider that a flame. heh. I too at one time thought that Xenon was getting 3 CPUs with 2 cores each ^__^

 

[Wunderchu]

I too at one time thought that Xenon was getting 3 CPUs with 2 cores each ^__^

same here.. heeh

 

[Kesler]

Sorry to be a newb but whats better

256MB main memory and 512MB on the GPU or

512MB main memory and 256MB on the GPU

 

[jvd]

i think a 256 meg system ram is a waste for this . Its not running a huge os and its not running many apps that it needs that much ram.

I would think a 512 meg umd is what will happen with both the cell and the gpu will have edram

 

[Gubbi]

A change to in-order only requires a change in mindsets. After all, programmers aren't born with an inate understanding of microprocessor structure - it's something they learn. When I did my degree, we learnt Modula2, then a different system in C, then another mindset for assembler and a completely different way of thinking for SML. Devs just need to learn a different way of thinking and designing that, once mastered, will be no more difficult to work with than existing methods (though I'm sure during the change many will spit and curse over why they can't use the way they've always used, what a load of crap this in-order is, change stinks, gimme back my Pentium, oh, hang on, now I see, wow! look at the speed of this thing, and wow, the structure's really logical, why the hell did we stick with OOO for so long, bloody Intel holding us back, always said Pentium was crap.).

I actually have suspicions that human beings are very adaptable...

Console CPUs are going in-order because console workloads in general have large regular data structures, and thus are fairly predictable in their memory accesses.

OOOe helps you when you can't properly determine instruction schedule or access patterns at compile (or assembly-programming) time. It really has nothing to do with the skill of the developer (Jaws!).

OOOe won't help you scheduling around main memory latencies, multi-threading and explicit prefetch/streaming will have to solve that.

OOOe will help you schedule around instruction latencies (5-7 cycles in CELL, probably as bad in Xenon) and on-die caches (up to 30-ish cycles). The instruction latencies won't be a problem for the majority of the workload in a console, since loop-unrolling/interleaving (explicit vertical threading) will help alleviate this.

But not all code fits this bill, and code with unpredictable access patterns will run alot slower on next gen console hardware compared to state of the art general purpose CPUs.

See the difference between SpecInt and SpecFp, SpecInt being alot more unpredictable than SpecFp. All the top dogs in SpecInt are OOOe CPUs (Opterons, Athlon 64s and P4s), whereas SpecFp is more execution unit (in particualr DP FP) limited and you see the in-order wide issue Itanium 2 is right up there with Power 5.

Cheers
Gubbi

 

[j^aws]

...
OOOe helps you when you can't properly determine instruction schedule or access patterns at compile (or assembly-programming) time. It really has nothing to do with the skill of the developer (Jaws!).
...

That's out-of-order!

But seriously in the context of my post, it was meant to highlight that devs aren't stupid. Experienced devs in console development will optimise code around the advantages of in-order CPUs and that easy development doesn't necessarilly equate to better games.

 

[Gubbi]

...
OOOe helps you when you can't properly determine instruction schedule or access patterns at compile (or assembly-programming) time. It really has nothing to do with the skill of the developer (Jaws!).
...

That's out-of-order!

But seriously in the context of my post, it was meant to highlight that devs aren't stupid.

Oh, I absolutely agree with you there.

Experienced devs in console development will optimise code around the advantages of in-order CPUs and that easy development doesn't necessarilly equate to better games.

The only advantage there is to a in-order CPU is higher operating frequency (note that higher frequency does not necessarily equate to higher performance) for a given power budget compared to an OOOE CPU.

As for easy development not equating better games: I just disagree.

Time spent on manually massaging data and code to run decent on a micro architecture with alot of quirks is time taken away from developing better (or more efficient) AI, LOD, whatever algorithms. - Given the same budget and schedule that is.

Of course there'll be a few studios that can sink the extra resources into development, but seen as a whole I think making it easier for developers is the way to get better games on average for a platform.

Cheers
Gubbi