If there is a new article, PR, or interviews regarding Microsoft and the Xbox 360 then post it here. Do not start new threads with just a link to an article and no other reason for discussion. Too many threads are created with PR, articles, hype, and interviews that end up into arguments that do not contribute to the board in a constructive or positive way.
Official Microsoft PR thread
- Thread starter Sonic
- Start date
New E3 interview (bit late!) with Allard at CnVG (no direct links possible)
http://www.computerandvideogames.com/front_index.php?
Just skimmed through. No new information. Interestingly though Allard talks of XB360 having 3x the integer performance of PS3. I thought those statements were first attributed to the Major Nelson report that appeared just after E3 (IGN mentions they received it on the end of the last day IIRC), but it seems 'damage control' had latched onto this 'statistic' even during E3. Don't know when this interview was taken. May have been Friday and Thursday evening Allard and friends were sat around the pub table coming up with counter-propaganda to PS3.
http://www.computerandvideogames.com/front_index.php?
Just skimmed through. No new information. Interestingly though Allard talks of XB360 having 3x the integer performance of PS3. I thought those statements were first attributed to the Major Nelson report that appeared just after E3 (IGN mentions they received it on the end of the last day IIRC), but it seems 'damage control' had latched onto this 'statistic' even during E3. Don't know when this interview was taken. May have been Friday and Thursday evening Allard and friends were sat around the pub table coming up with counter-propaganda to PS3.
Shifty Geezer said:
Allard was probably a little tipsy >.>
not PR ,but the official X360 hd ,from seagate.
http://www.gamasutra.com/php-bin/news_index.php?story=5677
already posted ?
http://www.gamasutra.com/php-bin/news_index.php?story=5677
already posted ?
Shifty Geezer said:
You don't want to run branchy integer code on a SIMD architechture. A SPU on CELL has a 18 cycle branch misperdict penalty.
Since the CELL PU and Xenon PPE are the same thing (from what I've read), Xenon is going to have 3 times the integer power since it has 3 POWER cores vs CELLs single POWER core.
I don't dispute his logic, though I think his explanation of the need for integer is truely 'pants'!
If integer performance is so important, why add big streaming float units to XeCPU? Why claim 'XB360 offers 1 teraflop of targetted computer performance' without claim of it's reportedly more important integer capabilities? If 80% is integer work, why develop a CPU that's a 50/50 split for float and integer (only XeCPU isn't from what I know. It's integer performance has been reigned back to remove some silicon-hogging features to allow for more FPU work)?
This claim of the importance of integer capabilities for a games console had no place in MS's XB360 marketting campaign until AFTER PS3's float performance was shown to be greater...
If integer performance is so important, why add big streaming float units to XeCPU? Why claim 'XB360 offers 1 teraflop of targetted computer performance' without claim of it's reportedly more important integer capabilities? If 80% is integer work, why develop a CPU that's a 50/50 split for float and integer (only XeCPU isn't from what I know. It's integer performance has been reigned back to remove some silicon-hogging features to allow for more FPU work)?
This claim of the importance of integer capabilities for a games console had no place in MS's XB360 marketting campaign until AFTER PS3's float performance was shown to be greater...
Shifty Geezer said:
While the next-gen console CPUs are striving for parallelism, the languages used to program games are still sequential based.
Microsoft with it's huge software engineer base in compiler development probably gave a lot of advise on the design of the Xenon CPU.
Shifty Geezer said:
Just how much game code do you think relies on float performance and how much of it is just shuffling memory around in data structures.
Having worked on a few games I'll tell you that the majority of a games code falls into the latter category.
Games do make much greater use of FP resources than most desktop applications, but the majority of the code is still trivial memory shuffling, searches and sorts.
IMO the key to Cell being successful, isn't it's stellar fp performance (that's certainly enticing for devs) it's how well devs can make it work on the rest of the code. A lot of that is in the dev's hands.
If MS and Sony projected that future games were to be constructed in the same way as currently, why didn't they focus on producing 'super-data-shufflers'?
If Allard is right in that 80% is 'integer' work and 20% is float, it kinda confuses me as to why both MS and Sony took similar approaches. With this philosophy I'd have thought MS would have left the FPU to Cell and worked on a core optimized for data shuffling. As it stands they've reduced their int. performance to accomodate better FP performance, have they not?
What's your take on this ERP? Would XeCPU fair better by maybe losing a VMX or two and adding features to enhance data-shuffling performance?
If Allard is right in that 80% is 'integer' work and 20% is float, it kinda confuses me as to why both MS and Sony took similar approaches. With this philosophy I'd have thought MS would have left the FPU to Cell and worked on a core optimized for data shuffling. As it stands they've reduced their int. performance to accomodate better FP performance, have they not?
What's your take on this ERP? Would XeCPU fair better by maybe losing a VMX or two and adding features to enhance data-shuffling performance?
Because cell was a much larger vision and is supposed to do a lot of general purpose things, rather than being tailor made for a game machine?
Even PS3 isn't a game machine really, but an entertainment vortex that also runs realtime simulations that some people catagorize as games.
Shifty Geezer said:
FWIW I'm not sure either one was designed with percieved game developer needs in mind. I'm not going to voice my opinion here because I'd end up insulting both parties.
Having said that because of the way that console development works, you dictate the shape of the software when you design the hardware. By adding a lot of FPU power you'll start to see more emphasis on things that use it, mostly graphics and physics. Not necessarilly a bad thing.
But right now if you were to dissect even tasks that you would swear are FPU bound (say collision detection) your going to discover that it's the cache misses that are making it expensive. Think of it this way, 1 cache miss costs upwards of 500 cycles in that time I can do 12000flops on XB360, how many pieces of data really require that amount of work.
Now going to a segmented memory model, locking sections of your cache or prefetching the data can reduce these costs. But they all require developer work and suitable datastructures just how much of say a 4megabyte codebase to you think people pour over worrying about how best to optimise it?
harking back to an example I've used here before. The last time I doubled the speed of a piece of code was on a particle system that had resolved collisions with terrain, I did it not by changing the algorithm to use fp ops, but by rearranging the data structure so that the most common case had one cache miss instead of two (and that was with prefetching optimisations already in).
A "few"? Feeling modest tonight aren't youERP said:
Anyway I don't disagree with the comparison in terms of code-SIZE, but we all know that has little relevance to actual utilization. Most code still spends 90% of the time in 1% of the codebase, whether it's limited by FPU or not.
Fafalada said:A "few"? Feeling modest tonight aren't youERP said:
Anyway I don't disagree with the comparison in terms of code-SIZE, but we all know that has little relevance to actual utilization. Most code still spends 90% of the time in 1% of the codebase, whether it's limited by FPU or not.
I think this used to be true, but having worked on some larger code bases as of late (the executable for my current project >6Mb, and very little of that is static data), it really is death by a 1000 cuts. Nothing in particular is slowing it down, it all is.
ERP : Youre comments suggest greater overall performance would be obtained with lower peak rates but higher memory performance. You make a good case, but I can't see why both parties have failed to take this into consideration and optimise for super-low cache misses, high-speed recovery, and goodness knows what else to help. Have they both become the victoms of their own marketting campaigns, brainwashing themselves into pursuing bigger but increasingly irrelevant numbers?
Similar threads
