Support NeoGAF

[HTupolev]

Are they basically a wash when you consider Espresso advantages(OoE) and more cache vs the higher flops and more instructions per cycle(due to 128bit ect ect)?

You're not going to get a single straight answer.

If you come up with some kind of chaotic program made up of constant ridiculous unpredictable branches, espresso would quite possibly beat Xenon and CELL by a fair margin. On the other hand, if you're looking at a computationally-heavy section of code which carries out lots of parallel floating-point calculations, I wouldn't be surprised to see Xenon stomp on espresso (and depending on what you're doing, CELL might very well totally wreck both of them).

In the real world, the answer probably depends on the makeup of your game code.

 

[freezamite]

The PPE will perform very much like a Xenon core, yes. It really depends on the code when comparing to Espresso. In a float heavy workload, the PPE/Xenon cores would likely be dramatically faster. A branchy, integer heavy program could be close, with the PPE/Xenon's low IPC at a high clock rate plus SMT competing with Espresso's higher IPC and shorter pipeline, with Espresso coming out on top. Real applications will likely involve a mix of both kinds of code, however, so while Espresso could be faster running your gameplay loop and AI, if your game spends a lot of time waiting for the physics simulation on the FPU where Espresso is way slower that could be a big problem.

No, a branchy/heavy program will run dramatically faster on Espresso. I still fail to comprehend why you try to hide or minimize Espresso's strength while maximizing its weaknesses.
General purpose code will be much faster in Espresso, not only because of a pipeline 7 times shorter, but of course also because of bigger caches, less latency of the main RAM pools AND the MCM design.

 

[blu]

So how would the performance of Cells PPU compare to Espresso(is this basically the same thing as asking how 1 Xenon core would compare to Espresso? Xenon cores do seem to have more flops per core than the PPU)? Are they basically a wash when you consider Espresso advantages(OoE) and more cache vs the higher flops and more instructions per cycle(due to 128bit ect ect)?

You're looking for a definitive answer where there's no such an answer. You need a case-by-case (read: code case-by-case) analysis. Where it comes to real-world examples, none of the reputable multi-plat developers have complained yet about Expresson's fp/simd throughput, so take that as you will.

 

[JohnnySasaki86]

The PPE will perform very much like a Xenon core, yes. It really depends on the code when comparing to Espresso. In a float heavy workload, the PPE/Xenon cores would likely be dramatically faster. A branchy, integer heavy program could be close, with the PPE/Xenon's low IPC at a high clock rate plus SMT competing with Espresso's higher IPC and shorter pipeline, with Espresso coming out on top. Real applications will likely involve a mix of both kinds of code, however, so while Espresso could be faster running your gameplay loop and AI, if your game spends a lot of time waiting for the physics simulation on the FPU where Espresso is way slower that could be a big problem.

So it kind of is a wash in a way, by luckly for them physics looks like its moving over to the GPU this gen with gpgpu capabilities. Now where would number of characters/AI on screen at one time, or just multiple things happening simultaneously during gameplay(explosions, bunch enemies attacking, player fighting back ect ect), fall under as far CPU operations go? Is that more float heavy or more brach type code? I'm specifically thinking of the DF face off of COD, which said during SP Wii U framerate would take a big hit when multiple enemies appeared on screen and one time and blamed the slower CPU because of it.

You're looking for a definitive answer where there's no such an answer. You need a case-by-case (read: code case-by-case) analysis. Where it comes to real-world examples, none of the reputable multi-plat developers have complained yet about Expresson's fp/simd throughput, so take that as you will.

^Lol speak of the devil!

Actually there have been multiple multi platform devs(3 I think?) that have complained and called the CPU "slow".

No, a branchy/heavy program will run dramatically faster on Espresso. I still fail to comprehend why you try to hide or minimize Espresso's strength while maximizing its weaknesses.
General purpose code will be much faster in Espresso, not only because of a pipeline 7 times shorter, but of course also because of bigger caches, less latency of the main RAM pools AND the MCM design.

I thought MCM provide lil to no performance gain, and was primarily a power saving feature where as an APU does give u gains with regards to performance and latency.

 

[lostinblue]

So then what about being able to process multiple instructions per cycle vs hyper-threading?

Which produces better performance? Being able to read 3 and execute 2 instructions per CPU cycle, or using hyper threading?

Every processor with out of order execution is able to process multiple instructions per cycle, that's the whole point for it; hyper threading is a bonus to that.

Thing is, even with out of order filling the whole pipeline to be 100% efficient is a hard thing to do, so hyperthreading comes in handy as a second thread that uses up that extra unused space.

Also, is the how does Broadway stack up to the G4? That site had a G4 clocked at 1Ghz listed as performing at 15 Gflops. I would expect Espresso to have much better performance than the G4.

In Gflops? It's way worse than that; each Espresso core at 1.243 GHz should be towering on 4.9 GFlops; so roughly 15 GFlops for the whole thing.

In fact, 15 GFlops is too high for a G4 too.

Difficult to say (as always it depends on the application), but not really relevant since there are no single-issue CPUs around. Dual-issue has been around since the first Pentium (or was it Pentium Pro?).

Pentium Pro/P6 architecture for sure. Pentium 1 was still in-order.

By XCPU you mean Xenon or the Xbox 1 CPU (XCPU is another name for Xenon)?
Xenon not being out-of-order is one of the architectures' major drawbacks. Together with its short pipeline there is no doubt Gekko/Broadway/Espresso is more efficient per cycle for most code.
Pentium Pro/II/III however were out-of-order, too.

He meant the Xbox 1 CPU.

And why does PS4 Jaguar CPU have so many more flops than espresso? A single Jaguar core almost has as many flops as all 3 espresso cores. I realize ps4 CPU is clocked at 2ghz(heavily rumored to be).

Because of the AVX implementation alone. Although it would require two passes for real 256-bit floating point operations.

Edit: it seems like u touched on my question a bit in a post up above. 32bit SIMD vs 128 bit, instructions per cycle. Is there anything else? Id be interested how mathematically It compares.ike what's beig multiplied that makes jaguar have much more flops per core. Are they calculated the same way?

Pretty much, although the specifics of execution vary.

You also have notions of sustainable GFlops and peak GFlops, but it isn't something worth going into.

Anyway, they can easily do four 32 bit floating point ops (4x32-bit); whereas the Gekko is stuck on 2×32-bit.

Actually there have been multiple devs(3 I think?) that have complained and called the CPU "slow".

But they spent years optimizing their code for in-order dual-threaded execution; gekko is neither (OoE being pretty straightforward, but the 2-way SMT thing going on in there not so).

The more optimized code is for current gen platforms the worse it should be to port and expect it to perform well.

 

[blu]

Actually there have been multiple multi platform devs(3 I think?) that have complained and called the CPU "slow".

Criterion did a driving sandbox on the wiiu and said nothing about Expresso's fp/simd inabilities. Neither did Frozen Byte with their physics sandbox puzzle-platformer. On the contrary, the result of both devs' work is nothing short of excellent. So who are those devs that complained and what did they (try to) do?

 

[lostinblue]

I thought MCM provide lil to no performance gain, and was primarily a power saving feature where as an APU does give u gains with regards to performance and latency.

Not so.

MCM design means the GPU is less cycles removed from the eDRAM pool and GPU; that's huge for the link between them. Which is why when Microsoft did the XCGPU they had to gimp that link via the "front side bus replacement block" just so it didn't perform better.

If they also manage to have the main RAM pool less cycles away (on the X360 it was around 500 cycles away) it means a huge gain in efficiency. It's the small things, I mean, even the RAM, it's rated in ns, a saving of a few ns might seem trivial, but it's something that gets used every cycle that accesses RAM so in the end it piles up to be very significative.

Criterion did a driving sandbox on the wiiu and said nothing about Expresso's fp/simd inabilities. Neither did Frozen Byte with their physics sandbox puzzle-platformer. On the contrary, the result of both devs' work is nothing short of excellent. So who are those devs that complained and what did they (try to) do?

And both seemed to base themselves of the PC versions, which are more in line with the nature of the Espresso.

Just building a pattern here.


The devs that complained somewhat were the Tekken dudes whose engine is very optimized for PS3/X360 (with no PC build), the Warriors Orochi 3 Hyper dudes that are sloppy; and then 4A Games, the dudes that did Metro who said "Wii U has a horrible, slow cpu" only to backtrack and admit they didn't even mess with it, just looked at the specs, and DICE that said the cpu would shorten the platform life and aren't even making an effort (no Battlefield or FrozenBite) so I'm guessing they didn't even do any pre-emptive testing in there.

 

[Brad Grenz]

Criterion also had to lower the number of players in multiplayer for Most Wanted. Trine 2's physics occur in tiny, single plane environments.

 

[JohnnySasaki86]

Criterion did a driving sandbox on the wiiu and said nothing about Expresso's fp/simd inabilities. Neither did Frozen Byte with their physics sandbox puzzle-platformer. On the contrary, the result of both devs' work is nothing short of excellent. So who are those devs that complained and what did they (try to) do?

Yet all the improvements made to both of the games were mainly memory and gpu bound tasks. Texture resolution, ect. Memory amount is Wii U's biggest strength over the current gen consoles.

Anyways I don't remember the devs but one of them was japenesse. Maybe Ninja Gaiden dev? I dunno. But really that part of my post was the least important(I could careless what devs have come forward, as most would never say anything so it's a pointless thing to brig up, I was just trying to point out there indeed have been a few complaints), and I rather u focus on what I said above, and those questions please. I.e the real life example of COD and number of characters on screen at one time and whether that's a float heavy type of operation like physics.

 

[frankie_baby]

Criterion also had to lower the number of players in multiplayer for Most Wanted. Trine 2's physics occur in tiny, single plane environments.

They did lower the number of online players, we have no evidence however that they had to

 

[frankie_baby]

Yet all the improvements made to both of the games were mainly memory and gpu bound tasks. Texture resolution, ect. Memory amount is Wii U's biggest strength over the current gen consoles.

Anyways I don't remember the devs but one of them was japenesse. Maybe Ninja Gaiden dev? I dunno. But really that part of my post was the least important(I could careless what devs have come forward, as most would never say anything so it's a pointless thing to brig up, I was just trying to point out there indeed have been a few complaints), and I rather u focus on what I said above, and those questions please. I.e the real life example of COD and number of characters on screen at one time and whether that's a float heavy type of operation like physics.

Trine 2 had an improved physics model too

 

[freezamite]

I thought MCM provide lil to no performance gain, and was primarily a power saving feature where as an APU does give u gains with regards to performance and latency.

It depends on the architecture.
On both the WiiU and the Xbox360 the northbridge is located in the GPU die, so having the CPU closer to the GPU of course helps a lot when it comes to reduce latency from main-ram (or in WiiU's case, MEM2 RAM, because MEM1 is the 32MB of eDram on the GPU which of course will be extremely faster even when compared to MEM2).

 

[Brad Grenz]

Anyways I don't remember the devs but one of them was japenesse. Maybe Ninja Gaiden dev? I dunno. But really that part of my post was the least important(I could careless what devs have come forward, as most would never say anything so it's a pointless thing to brig up, I was just trying to point out there indeed have been a few complaints), and I rather u focus on what I said above, and those questions please. I.e the real life example of COD and number of characters on screen at one time and whether that's a float heavy type of operation like physics.

It was the Dynasty Warriors dev who complained about the CPU. So did a Metro: Last Light dev and someone from Dice.

They did lower the number of online players, we have no evidence however that they had to

Good point. I'm sure someone just tripped and fell and accidentally lowered the player count.

 

[JohnnySasaki86]

Trine 2 had an improved physics model too

Yet just like Brad_Genz pointed out the physics occur on a 2d plane side scrolling adventure game. When it comes to CPU type tasks I've yet to see an improvement over the current gen console games, and mainly have only seen instances where performance is quite a bit inferior. COD sp with number of enemies on screen is perfect example.

I think a lot of its because devs haven't been able to move there CPU code over to gpgpu. Im sure if they did performance would be better than the current gen consoles. The gpu is obviously designed to offset the CPU weaknesses in a lot of areas(i also dont know how gogpu helps with any tyoe of cou related tasks besides physics?) Yet that doesn't change the fact it's indeed weak, and this is a Espresso thread.

Edit: . no one has answered my question yet on whether number of enemies on screen is float heavy CPU operation or more of a general purpose processing type operation. I think this type scenario is just as important physics and AI when it comes to real world performance and gameplay. We've seen Wii U struggle in this area in multiple games.

 

[frankie_baby]

It was the Dynasty Warriors dev who complained about the CPU. So did a Metro: Last Light dev and someone from Dice.



Good point. I'm sure someone just tripped and fell and accidentally lowered the player count.

The Japanese guy was misinterpreted and the other 2 are from devs not working on Wii u so they have a vested interest in it not doing well

Or how about they just correctly assumed the online player count would be lower so reducing the number would make it easier/better to get an online race

 

[frankie_baby]

Yet just like Brad_Genz pointed out the physics occur on a 2d plane side scrolling adventure game. When it comes to CPU type tasks I've yet to see an improvement over the current gen console games, and mainly have only seen instances where performance is quite a bit inferior. COD sp with number of enemies on screen is perfect example.

I think a lot of its because devs haven't been able to move there CPU code over to gpgpu. Im sure if they did performance would be better than the current gen consoles. The gpu is obviously designed to offset the CPU weaknesses in a lot of areas(i also dont know how gogpu helps with any tyoe of cou related tasks besides physics?) Yet that doesn't change the fact it's indeed weak, and this is a Espresso thread.

Just because its on a 2d plane doesn't make better physics any less better

 

[Brad Grenz]

The Japanese guy was misinterpreted

Sure he was...

and the other 2 are from devs not working on Wii u

Yeah, because they discovered the hardware was inadequate to run their games.

Or how about they just correctly assumed the online player count would be lower so reducing the number would make it easier/better to get an online race

Whatever helps you sleep at night, dude.

 

[JohnnySasaki86]

Just because its on a 2d plane doesn't make better physics any less better

No it doesn't, but we're specifically referring to how demanding it is as a processing task. The physics in Trine 2 are probably not as CPU demanding as something like what's in Uncharted 3 for example, or a lot of modern FPS like BF3 where shit blowin up all around.

The gpu guy wasn't really misinterperted. He was more saying that the CPU has a very low clock speed and therefor is slow from that point view. Which we all know clock speed isn't everything. But regardless he isn't the only one who made comments about the CPU. Once again debating about this is pointless cause 98% devs are not gonna come out say its horrible slow CPU. There sure haven't said its powerful, that's more telling right there than anything. They've made multiple compliments about the amount of memory and even a couple about the GPU.

Brad_Grenz can u plz answer my question regarding whether number of enemies on screen is a float heavy task like physics or not?

 

[lostinblue]

Yeah, because they discovered the hardware was inadequate to run their games.

Not really. Both have gone on record saying they just thought it wasn't worth the resources.

Not that it couldn't run, in fact both said it could (despite only having looked superficially at it).

This CPU is very different than PS3/X360 ones, that means you have to tackle problems in a whole different way. And yes, I mean problems, because PS3/X360 cpu's are a pain in the arse too, it's just that people are used to them now.


Of course most devs would prefer it to have the muscle to come on top with unoptimized PS3/X360 code (s certainly happened on previous generations with first generation/launch titles), but this is simply a different beast.

 

[Angel Whispers]

Sure he was...

He was. He even went on Twitter to say as much. Also, THQ had to take the Metro: Last Light comments back as they referred to a very early kit, NOT the final one. A lot of the Wii U negativity is actually very easy to disprove.

 

[frankie_baby]

No it doesn't, but we're specifically referring to how demanding it is as a processing task. The physics in Trine 2 are probably not as CPU demanding as something like what's in Uncharted 3 for example, or a lot of modern FPS like BF3 where shit blowin up all around.

The gpu guy wasn't really misinterperted. He was more saying that the CPU has a very low clock speed and therefor is slow from that point view. Which we all know clock speed isn't everything. But regardless he isn't the only one who made comments about the CPU. Once again debating about this is pointless cause 98% devs are not gonna come out say its horrible slow CPU. There sure haven't said its powerful, that's more telling right there than anything. They've made multiple compliments about the amount of memory and even a couple about the GPU.

Brad_Genz can u plz answer my question regarding whether number of enemies on screen is a float heavy task like physics or not?

Did I say the physics of trine 2 were more demanding than uncharted? No I didn't, the physics in trine 2 wiiu are better than the physics in trine 2 ps360 that's a fact

 

[JohnnySasaki86]

this is the point i was trying to make we have to wait until E3.... i dont think its fair on both sides. people are gonna bring up launch games and we know now that those games werent running on finished hardware. the people that did seem to have problems with the CPU were those who had early dev kits and just trhew 360 code on the Wii u and saw that the code didnt run well. these are things we know and have been discussed and dismissed so i dont think its fair to try and bring up those points as a way to say oh the Wii u has a "WEAK" CPU. its a different CPU that is clocker lower,and out of order. final devkits are out and there (at least from me) are gonna be no more excuses for Wii U come E3. what we see should give us a general ball park of (no matter how much discussion we do on the numbers) what the console is going to be capable of next generation.

Frankly when games do start running better it doesn't nessessarly mean anything regarding the CPU either. It's a "weak" CPU let face it people. All the facts are in front of us. Low clock, 32bit SIMD, 64but fpu, only 2 opperations ler cycle(albit more efficient ones), ect ect. Theres a lot less mysteries with cpu than gpu, and we dont need devs to come out and tell us.

When devs start using the gpgpu capabilities and other strengths of the GPU is when we'll see significant improvements. Essentially when devs start playing to the systems advatages and avoiding its weakness as much as possible(CPU). It's obvious why aspects like this couldn't of been implemented on 360/ps3 games cause it would probably be such a huge restructuring of the code(gpgpu).

 

[frankie_baby]

Whatever helps you sleep at night, dude.

Look it could be any number of reasons why the onlinew player number is reduced but the fact is you gave zero evidence that its the cpu causing the reduction

 

[JohnnySasaki86]

Did I say the physics of trine 2 were more demanding than uncharted? No I didn't, the physics in trine 2 wiiu are better than the physics in trine 2 ps360 that's a fact

Dude u completely avoiding the point of our comments! What were saying it doesn't mean shit cause it's not very demanding from a processing perspective. I'm not trying to say UC3 are better or worse, just more demanding. Tribe 2 having better physics is in no way proof that the wii u's CPU isnt weak, as it doesn't demand as much from a CPU as
other games would. The game is a side scrolling 2d adventure game. In this type of game maybe the amount of memory and gpu horsepower helped them here pretty easily, as it wouldn't take much to make improvements in this type of game.

I whole heartidly agree they are better than the 360/ps3 versions, and do affect the gameplay experience.

Edit: sorry for all the typos in my posts, typing on a auto-correcting iPhone does that'...Annoying.

 

[Brad Grenz]

He was. He even went on Twitter to say as much. Also, THQ had to take the Metro: Last Light comments back as they referred to a very early kit, NOT the final one. A lot of the Wii U negativity is actually very easy to disprove.

Man, it's almost like PR had to do damage control for a game they were still trying to sell at the time.

And considering the Espresso CPU is basically identical in core functionality to the Wii CPU AND the Gamecube CPU any "early devkit" excuses hold exactly zero water. I can't imagine a Engine architect at either DICE or 4A would even need to go hands on with actual hardware to know that 3 Gekkos at 1.2 Ghz would be inadequate for the experiences they're building.

 

[freezamite]

Man, it's almost like PR had to do damage control for a game they were still trying to sell at the time.

And considering the Espresso CPU is basically identical in core functionality to the Wii CPU AND the Gamecube CPU any "early devkit" excuses hold exactly zero water. I can't imagine a Engine architect at either DICE or 4A would even need to go hands on with actual hardware to know that 3 Gekkos at 1.2 Ghz would be inadequate for the experiences they're building.

Current game engines are coded around PS360 arquitecture, that's a fact, and it doesn't matter in that regard if the devkit was finished or not, because the engine of those games being ported is designed with the current gen of consoles architecture in mind.

WiiU has an architecture resembling the PS4 and of course the next Xbox much more than the PS3/360.

 

[JohnnySasaki86]

Man, it's almost like PR had to do damage control for a game they were still trying to sell at the time.

And considering the Espresso CPU is basically identical in core functionality to the Wii CPU AND the Gamecube CPU any "early devkit" excuses hold exactly zero water. I can't imagine a Engine architect at either DICE or 4A would even need to go hands on with actual hardware to know that 3 Gekkos at 1.2 Ghz would be inadequate for the experiences they're building.

Yes, which further supports my theory it's more about them not taking advantage of the gpgpu capabilities than coding to the architecture of the CPU. The CPU is weak, and they designed it this way based on what they were doing on the gpu side of things. Current gen consoles had a completely different philosophy. Ps4 is designed the same way, which really makes it a shame, cause it's still 8x weaker than Jaguar.

Now can u try to answer my question on whether or not a processing task like the number of enemies on screen is a float heavy task like physics?

Current game engines are coded around PS360 arquitecture, that's a fact, and it doesn't matter in that regard if the devkit was finished or not, because the engine of those games being ported is designed with the current gen of consoles architecture in mind.

WiiU has an architecture resembling the PS4 and of course the next Xbox much more than the PS3/360.

Yes but it makes a lot of sense that it's much more about coding to the gpu's strengths, then having anything to the do with opimizing for Espresso. The Cpu should still be very familiar.

come on for real? im not saying the espresso CPU is a powerhouse but now we are saying early devkits dont count? look at the PS4 running the Unreal 4 engine which look visibly worse than the PC version of the demo... what have the defenders been saying... "ITS NOT RUNNING ON FINAL HARDWARE/DEVKITS". so why in the Wii U situation when developers went hands on with early devkits it doesnt matter? Criterion even said this in their interview some developers went hands on with early devkits and didnt like what they saw. they had the advantage to wait until the final devkits were out and (correct me if im wrong) they pretty much accomplished NFSMWU in about 4 months time? like i said im not trying to make excuses for Wii U but its funny that every other home console in history has been given the benefit of developers needing time with final hardware to get to know how to use its strengths(every console will have a weakness as its a closed system) except the Wii U. it amazes me!

Actually an Epic enigne programmer went on record and said the demos are much more similar technically than it appears. The lighting was a lot different because of the placement of the sun was changed and they had to blend it together with the new scene. So it wasn't apples to apples comparison. Also said tesselation was currently broken in the build but would be fixed in the future.

He said the only differences was a slight reduction in the particles and removal of SVOGI. Textures, resolution, physics, ect were all identical. There's a thread posted on gaf about it.

 

[Brad Grenz]

Look it could be any number of reasons why the onlinew player number is reduced but the fact is you gave zero evidence that its the cpu causing the reduction

It's called the process of elimination. WiiU has more RAM, a faster GPU, a faster disc drive... It's not hard to see where the weak link is. Unless you have your head in the sand, that is.

Current game engines are coded around PS360 arquitecture, that's a fact, and it doesn't matter in that regard if the devkit was finished or not, because the engine of those games being ported is designed with the current gen of consoles architecture in mind.

WiiU has an architecture resembling the PS4 and of course the next Xbox much more than the PS3/360.

The whole point of OoOE on a CPU is it automagically runs the same code faster. The problem isn't that current engines are "coded to the PS360 architecture". The problem is that they assume some base level of performance and the WiiU's ancient CPU design can't keep up. And unfortunately the GPU is not fast enough, tightly integrated enough, nor efficient enough at GPGPU computation for that to be a realistic solution.

 

[frankie_baby]

Yes, whh further supports my theory it's more about them not taking advantage of the gpgpu capabilities than coding to the architecture of the CPU. The CPU is weak, and they designed it this way based on what they were doing on the gpu side of things. Current gen consoles had a completely different philosophy. Ps4 is designed the same way, which really makes it a shame, cause it's still 8x weaker than Jaguar.

Now can u try to answer my question on whether or not a processing task like the number of enemies on screen is a float heavy task like physics?



Yes but it makes a lot of sense that it's much more about coding to the gpu's strengths, then having anything to the do with opimizing for Espresso. The Cpu should still be very familiar.

Maybe I'm wrong but wouldn't number of enemies on screen require running multiple AI routines and AI is general code not floating point based so espresso should smoke ps360 in that regard

 

[NBtoaster]

It's called the process of elimination. WiiU has more RAM, a faster GPU, a faster disc drive... It's not hard to see where the weak link is. Unless you have your head in the sand, that is.

It could also be a problem with the Nintendo's network or stricter bandwidth requirements or EA not wanting to spend as much on servers...etc.

 

[freezamite]

Yes but it makes a lot of sense that it's much more about coding to the gpu's strength, then having anything to the do with Espresso. The Cpu should still be very familiar.

It's not a matter of it being familiar or not. Espresso's fp capabilities are much more limited than current gen offerings, so throwing code designed with current gen in mind is highly inneficient.
The CPU on PS3/360 had a role, on the WiiU it has another and completely different role, so it's not fair to compare them based on current games optimized around PS3/60 arquitecture.

Espresso is designed around general purpose code efficiency, while Xenon/Cell were designed with high FP code performance in mind, they're not directly comparable at all.

The whole point of OoOE on a CPU is it automagically runs the same code faster. The problem isn't that current engines are "coded to the PS360 architecture". The problem is that they assume some base level of performance and the WiiU's ancient CPU design can't keep up. And unfortunately the GPU is not fast enough, tightly integrated enough, nor efficient enough at GPGPU computation for that to be a realistic solution.

This has nothing to do with having OoOE or not. This base level of performance in CPU you said is assumed to be the minimum base, it's in fact higher than most of the modern PC CPUs you'll find even on gamming PCs.
The WiiU design is tailored towards certain performance requirements, and the PS360 to completely different ones.

To throw games made with PS3/60 requirements on mind in the WiiU is a quick way to re-utilize previous coded engines and re-sell some games, and this is possible because the WiiU is powerful enough to deal with this hindrance (having the games coded with a different architecture on mind) and still delivering those games with good-enough performance.

 

[frankie_baby]

It's called the process of elimination. WiiU has more RAM, a faster GPU, a faster disc drive... It's not hard to see where the weak link is. Unless you have your head in the sand, that is.



The whole point of OoOE on a CPU is it automagically runs the same code faster. The problem isn't that current engines are "coded to the PS360 architecture". The problem is that they assume some base level of performance and the WiiU's ancient CPU design can't keep up. And unfortunately the GPU is not fast enough, tightly integrated enough, nor efficient enough at GPGPU computation for that to be a realistic solution.

Again you're argument is completely flawed as you are only looking at hardware

As for that second point its wrong on so many levels but i'll let someone more technically articulate explain

 

[blu]

Criterion also had to lower the number of players in multiplayer for Most Wanted. Trine 2's physics occur in tiny, single plane environments.

Most Wanted's online limitations could be result of various things, not necessarily physics sim cutbacks (eg: all single-player events feature the same number of vehicles as the other versions, and that is computed on the same host). As re Trine - whether the sim is in 2D, 3D, or 5D is of no relevance - it's about how precise your simulation is set up to run. That said, I'm not saying Trine2 appears to be too taxing, just that Frozen Byte are of the developers who'd have hit this or that limitation on the platform and could have spoken.

The whole point of OoOE on a CPU is it automagically runs the same code faster.

That's quite simplistic, not to say naive. Out-of-order would unconditionally speed up the same code iff the other CPU has exactly the same resources, but is in-order. You do realize that's quite a hypothetical statement to make, right?

 

[JohnnySasaki86]

It's not a matter of it being familiar or not. Espresso's fp capabilities are much more limited than current gen offerings, so throwing code designed with current gen in mind is highly inneficient.
The CPU on PS3/360 had a role, on the WiiU it has another and completely different role, so it's not fair to compare them based on current games optimized around PS3/60 arquitecture.

Espresso is designed around general purpose code efficiency, while Xenon/Cell were designed with high FP code performance in mind, they're not directly comparable at all.

True. I understand. But it doesn't change the fact that them off loading stuff to the gpu for gpgpu tasks is the biggest architectural change they didn't take advantage of. Like you said the CPU has a different roll, as does the GPU. I would say it may be more accurate to say it has less of a role, where the gpu role is more prominent(which is why they said "yea we can save here by sticking a weak ass CPU in"). Same with PS4 in comparison to its GPU. The silicon budgets are definitely more focused on the GPUs and memory this time around.

What I'm trying to imply here, is that as the games start performaning better, it doesn't nessessarly mean there optimize and using the CPU better but just that there using the gpu more efficiently and in its proper role. The facts state that the cpu is very weak by today's standards, and while with its own advantages and disadvantages, it's not a big leap over Xenos, and is likely pretty close all things considered. I don't think there's any denying this fact. And when the games start performaning significantly better in the future it doesn't change this.

 

[tkscz]

Sure he was...

Actually, he was. Him and the Tekken dev.

Yeah, because they discovered the hardware was inadequate to run their games.

Well According to the Need For Speed devs, most developers didn't even try to use it, just looked at the numbers and assumed it was too weak.

Whatever helps you sleep at night, dude.

Same to you buddy.

 

[freezamite]

True. I understand. But it doesn't change the fact that them off loading stuff to the gpu for gpgpu tasks is the biggest architectural change they didn't take advantage of. Like you said the CPU has a different roll, as does the GPU. I would say it may be more accurate to say it has less of a role, where the gpu role is more prominent(which is why they said "yea we can save here by sticking a weak ass CPU in"). Same with PS4 in comparison to its GPU. The silicon budgets are definitely more focused on the GPUs and memory this time around.

For one part yes, this is true, but then there is the fact that on general purpose code, the Espresso is way stronger than the Xenon.
Core by core, Xenon's performance was said to be only 20% higher than Broadway when running a general purpose-single threaded program (an emulator).
Remember that Xenon's L2 cache is shared between all the execution threads, so the more concurrent threads you have the less cache you have available per core.

Espresso is 70% faster than Broadway, with much more cache memory than both Broadway and Xenon and thanks to the MCM design, also much closer to the northbridge than both of them.

When dealing with unpredictable code (branchy algorithms) performance penalizations are much more severe on X360/PS3 than on Espresso because of a huge number of factors, so it's not only that the WiiU has a more GPU-centric design, it's also that the Espresso is ok at what PS3/60 are absolutely atrocious, and it's bad at where PS360's processors are absolutely great.
But this is also inaccurate, because even between PS3 and 360 CPU's there is a lot of difference.
Xbox 360 has 3 times the PS3's strength when it comes to general purpose code, while PS3 is much more powerful in FPU code thanks to its SPE.

 

[JohnnySasaki86]

For one part yes, this is true, but then there is the fact that on general purpose code, the Espresso is way stronger than the Xenon.
Core by core, Xenon's performance was said to be only 20% higher than Broadway when running a general purpose-single threaded program (an emulator).
Remember that Xenon's L2 cache is shared between all the execution threads, so the more concurrent threads you have the less cache you have available per core.

Espresso is 70% faster than Broadway, with much more cache memory than both Broadway and Xenon and thanks to the MCM design, also much closer to the northbridge than both of them.

When dealing with unpredictable code (branchy algorithms) performance penalizations are much more severe on X360/PS3 than on Espresso because of a huge number of factors, so it's not only that the WiiU has a more GPU-centric design, it's also that the Espresso is ok at what PS3/60 are absolutely atrocious, and it's bad at where PS360's processors are absolutely great.
But this is also inaccurate, because even between PS3 and 360 CPU's there is a lot of difference.
Xbox 360 has 3 times the PS3's strength when it comes to general purpose code, while PS3 is much more powerful in FPU code thanks to its SPE.

Gotcha, I totally understand what it's more suited for and it's strengths, but it's still weak when it comes to what it's actually "good" at, by today's standards or even 2-3 years ago, therefor removing ps3/360 from the argument. A 4 core Jaguar, which is a low end low power laptop CPU, which has the same strengths amd weakness, should destroy the WiiU cpu in all area, no? Let alone ps4's 8 core version, which has heavily modified systems to bypass the typical cache systems(dont even mnow how to describe what Cerny was talking about here).

Your still not directly addressing what I'm saying either. Which is, as devs start having the gpu do more and the CPU less, as in moving certain compute tasks over to the gpu, the Wii U's performance should increase dramatically. Which means the statement, " we got to wait for future games to see what this cpu really do!" is kinda pointless and it's still weak at the end of the day, and would be more of a sign of devs using the gpu properly.

 

[freezamite]

Gotcha, I totally understand what it's more suited for and it's strengths, but it's still weak when it comes to what it's actually "good" at, by today's standards or even 2-3 years ago, therefor removing ps3/360 from the argument. Your still not directly addressing what I'm saying either. Which is, as devs start having the gpu do more and the CPU less, as in moving certain compute tasks over to the gpu, the Wii U's performance should increase dramatically. Which means the statement, " we got to wait for future games to see what this cpu really do!" is kinda pointless and it's still weak at the end of the day, and would be more of a sign of devs using the gpu properly.

Well, Espresso has an extremely short pipeline design, so it's performance per clock will probably be higher than anything currently on sale when it comes to general purpose code.
But with that being said, it's not even a matter of using gpgpu, but to simply use the GPU for what it's meant to.
Nearly every PS3/60 game uses it's CPU to do GPU-related tasks, because it was the best way to utilize them.
Once the games are made around the WiiU specifically (first-second party offerings and some third party exclusivities) both it's GPU and CPU will be used in a more intelligent way, and both of them will offer superior performance compared to what they are doing now.

Since the WiiU is a GPU-centric console, the CPU of course is a more modest part, but it still can deliver when it has to.

 

[JohnnySasaki86]

but when you say that to the majority of GAF they will say its GPGPU capability isnt that powerful and its going to be limitied by what it can do. im more concerned about what i SEE on screen than about how its achieved. what i mean is to say the Wii U CPU is weak is like a non issue. like i dont believe its CPU is going to be a problem. more so is the gaming age we live in. developers are more adapt to customizing and tailoring engines and code to cover whatever(all console have them) weaknesses a console might have. i get what you are saying the CPU would be the weaker part of the system but in all i see the system being more than capable and "COMPETENT" devs having little issues with the "SO CALLED" weak CPU.

Yea I mostly agree. Within its own architecture, the weak CPU is a non issue, if they use the other parts of the system properly. But your bringing up a whole nother arguement, which I don't want to get into as far as being "capable" and "competent" in the grand scheme of things, and when u look at the system as a whole and are taking into account when it's been released; I don't want to turn this into anymore of a system wars thread than it already is. But suffice to say my final statement would be, Only time will tell.

Well, Espresso has an extremely short pipeline design, so it's performance per clock will probably be higher than anything currently on sale when it comes to general purpose code.
But with that being said, it's not even a matter of using gpgpu, but to simply use the GPU for what it's meant to.
Nearly every PS3/60 game uses it's CPU to do GPU-related tasks, because it was the best way to utilize them.
Once the games are made around the WiiU specifically (first-second party offerings and some third party exclusivities) both it's GPU and CPU will be used in a more intelligent way, and both of them will offer superior performance compared to what they are doing now.

Since the WiiU is a GPU-centric console, the CPU of course is a more modest part, but it still can deliver when it has to.

Why do you imply the way they did things this gen were inefficient? Specifically in regards to graphical tasks done on Cell. I remember when Killzone 2 released in 2008, the things they were doing on Cell were pretty unheard of at that time. The post processing effects and what not. I feel like some of the biggest advancements made this gen, when it comes to games looking pretty, was due to post processing effects and other graphical effects done on the CPU's. Games like GOW3 and UC3 are other great examples. Post processing AA another good example. That IQ in gow3 is still pretty darn amazing. Anyways my point is, I thought it worked out pretty well in the end.

 

[Captainsweatpants]

I guess that's sarcasm, but in case it's not /disclaimer

It's not like Broadways and Bobcats are publicly available for anybody to test that..

It was sarcasm.

 

[freezamite]

Why do you imply the way they did things this gen were inefficient? Specifically in regards to graphical tasks done on Cell. I remember when Killzone 2 released in 2008, the things they were doing on Cell were pretty unheard of at that time. The post processing effects and what not. I feel like some of the biggest advancements made this gen, when it comes to games looking pretty, was due to post processing effects and other graphical effects done on the CPU's. Games like GOW3 and UC3 are other great examples. Post processing AA another good example. That IQ in gow3 is still pretty darn amazing. Anyways my point is, I thought it worked out pretty well in the end.

This is why I say that you can't directly compare different architectures. Those were examples of an inefficient way to utilize the CPU of the WiiU, and at the same time it was the best way of working on PS3/360.
Those tricks you speak of, they are great for the PS3, but they will kill the performance on the WiiU. On the other hand, you will be able to run some algorithms on the WiiU's CPU totally impossible to run in Cell (given the time they have to be executed).
If you grab code optimized around PS3/360 (and even this code had to be adapted between Xbox360 and PS3 to achieve the same results) you will have a bad optimization on the WiiU.

 

[Earendil]

You guys are wasting your breath...

 

[krizzx]

I'm specifically thinking of the DF face off of COD, which said during SP Wii U framerate would take a big hit when multiple enemies appeared on screen and one time and blamed the slower CPU because of it.

The was the result of the game being poorly ported and poorly optimized.

ZOE 2nd runner runs better on the PS2 than it does on the PS3 and 360. Final Fantasy Tactics runs better on the PS1 than on the PSP. Epic Mickey 2 runs better on the Wii than it does on the Wii U... Samurai Warriors 3 on the Wii runs better than Warriors Orochi 3 Hyper on the Wii U.

A port will generally run no better than it does on the lead platform it was developed for. To do so would require a complete overhaul of the code which most devs are not going to spend money on. We have a few exceptions to that on the Wii U. Those are Trine 2 Director's Cut, NFS Most Wanted U and Deus Ex Director's Cut. Those are "good" ports.

That is why the exact same flaws exist in the exact same places. The 360 version of Tekken Tag 2 slows down whenever Raven using his double teleport kick. it does it the exact same way when he uses it on the Wii U version.

No problems of that nature are "truly" the result of pure hardware incapability. At least not in modern times. A game with extensive physics could just have them scaled back or a game with lots of particle effects could have them reduced or changed to an effect that works better on the hardware. Most devs aren't going to do that though. Generally, they'll just try to cram into the console in "good enough" working form and if you are lucky, they will shave off whatever didn't work well from simply porting the code. Thats as good as most ports tend to get amongst hardware with different architecture.

Also, DF talks a lot of rubbish. They can't know what is causing a problem without actually analyzing the code. Too many people take their guesses as fact. Those same problems existed in the PS3 version, but they didn't blame its CPU. The 360 was the lead platform for COD just as it was for Red Dead Redemption which also performed significantly better on it than the PS3.

 

[joesiv]

Most Wanted's online limitations could be result of various things, not necessarily physics sim cutbacks (eg: all single-player events feature the same number of vehicles as the other versions, and that is computed on the same host).

It could also be as simple as network throughput, from what I gather anecdotally, the WiiU doesn't seem to be very quick on the network side of things. it's feasible that it was scaled from 8 to 6 just to help the networking subsystem from being overwelmed. But that's just speculation.

 

[cartman414]

I believe they will... i hate to be a downer but we have to face facts. No one is going to be able to tell what this console can do from the numbers. we dont know enough and its too customized. we all are gonna have to wait until E3 to see high profile games(smash brothers, 3d mario, Retro's titles, more of X, Bayonetta 2, and whatever else they have up their sleeve) to compare what it can do more than ps360 and how it compares to what we will see from sony ps4 and microsoft 720. it sucks but we will have to wait.

It's about PPC being near that brick wall of power efficiency, which is what Nintendo's after the most.

Wouldn't it be funny if Nintendo suddenly went with Intel next time?

 

[blu]

It could also be as simple as network throughput, from what I gather anecdotally, the WiiU doesn't seem to be very quick on the network side of things. it's feasible that it was scaled from 8 to 6 just to help the networking subsystem from being overwelmed. But that's just speculation.

Of course.

 

[krizzx]

This is why I say that you can't directly compare different architectures. Those were examples of an inefficient way to utilize the CPU of the WiiU, and at the same time it was the best way of working on PS3/360.
Those tricks you speak of, they are great for the PS3, but they will kill the performance on the WiiU. On the other hand, you will be able to run some algorithms on the WiiU's CPU totally impossible to run in Cell (given the time they have to be executed).
If you grab code optimized around PS3/360 (and even this code had to be adapted between Xbox360 and PS3 to achieve the same results) you will have a bad optimization on the WiiU.

Speaking of which, exaclty what types of code would the Expresso be able to handle better than the Cell and Xenon?

 

[Brad Grenz]

It could also be as simple as network throughput, from what I gather anecdotally, the WiiU doesn't seem to be very quick on the network side of things. it's feasible that it was scaled from 8 to 6 just to help the networking subsystem from being overwelmed. But that's just speculation.

That in itself would be incredibly troubling, but you don't have player scaling down in other games that I'm aware of.

 

[efyu_lemonardo]

I guess Dolphin emulation of Wii U is eminent?

Sorry if this is slightly tangential, I looked through the thread and didn't see anything that immediately jumped out to me as trying to answer it.

I still find it an interesting question, even if I don't think it is close to being imminent...

But is there anybody who could add some thoughts on this?
Basically what I'm wondering is if it's possible to estimate the amount of work it would require to go from running 3 simultaneous emulations of Broadway at ~170% speed to running an Espresso emulator at something close to real time?

As a complete layman, I can't help but wonder if this couldn't be done on a powerful home PC in a few years..

 

[freezamite]

Speaking of which, exaclty what types of code would the Expresso be able to handle better than the Cell and Xenon?

Everything not floating point related. The more branches you have in your code, the greater the difference.
It also has much more cache memory and much less latency to RAM pools, so it's impossible to determine how performs Espresso in comparison to Xenon exactly unless we had some direct examples from the scene.

For you to have a reference, Broadway performed (in general purpose code) only a 20% less than a Xenon core, without multi-threading.
Considering that Xenon shares the 1MB of L2 cache between all of his cores, the performance per core wouldn't scale linearly when using other cores for your code.
The difference would be HUGE in favour of Espresso.

Sorry if this is slightly tangential, I looked through the thread and didn't see anything that immediately jumped out to me as trying to answer it.

I still find it an interesting question, even if I don't think it is close to being imminent...

But is there anybody who could add some thoughts on this?
Basically what I'm wondering is if it's possible to estimate the amount of work it would require to go from running 3 simultaneous emulations of Broadway at ~170% speed to running an Espresso emulator at something close to real time?

It's not that easy. You still have much more cache memory on Espresso to bump it's performance, and that's not to speak about the GPU.
How are you planning to emulate the 32+3MB of eDram it has?