Modern big out-of-order cores, with big caches and shorter pipelines, have a high baseline of performance, and have less room for optimization except in the use of newer SIMD (like newer SSE, AVX, etc. on x86 architectures). Does Espresso have special SIMD that developers are underutilizing?

Here's an example of the optimization problem:

- A 360 core has a theoretical IPC of 2.0 but baseline IPC of say 0.5 @ 3.2GHz for a total 6.4 Giga inst theoretical, 1.6 Giga inst baseline per second.
- A Wii U core has a theoretical IPC of 3.0 but baseline IPC of say 2.0 @ 1.25 GHz for a total 3.75 Giga inst theoretical, 2.4 Giga insta baselineper second.

Cool, the Wii U's cores are 4 times better on baseline (that's a much better architecture).  It should make sense that this is so, otherwise Wii U could not use such a low core clock frequency and still match or beat the 360.

But oh oh - look the Xbox 360 has 300% room to optimize between average and peak, while the Wii U has only 50% room. This is called diminishing returns.  Further typical CPU optimization, is likely to yield more speedup for the 360 than the Wii U.

Since Wii U is running closer to it's ceiling as baseline, further increases take more work.  Also a 0.1 IPC improvement becomes a 20% improvement for X360, and 5% improvement for Wii U.  5% improvement from 20fps is just 21fps .

Then there's the SIMD story. Theoretical max for 360 would be 3.2 Giga SIMD vector instructions, and theoretical max for Wii U probably 1.25 Giga. Again, use more SIMD - benefit 360 more than Wii U. Diminishing returns for Wii U .

Edit:

From the article you quoted:

"However, some code could see substantial improvements that did mitigate the lower clocks - anything up to a 4x boost owing to the removal of Load-Hit-Stores, and higher IPC (instructions per cycle) via the inclusion of out-of-order execution."

4x boost in IPC, spot on with what I was saying.  Think about the diminishing returns I mentioned, it's obvious.

"we did have to cut back on some features due to the CPU not being powerful enough."

So they would have to improve just to match the PS3/360?

Doesn't address the dev comments about PS3/360 code not being well suited to Espresso. 

I'm not claiming its a juggernaught, but badly optimized ports (like Splinter Cell or Arkham Origins) are likely an inaccurate measure of its strength.

Like PS4/Xbone, Wii U focuses on (GP)GPU and memory over CPU, while PS3/360 are leftovers of an era where CPUs were more prioritised.

Agreed, though devs have yet to really offload work to the GPU on any of PS4/Xbone/Wii U in their first years, and while the Wii U is mostly in a commercial position to receive ports from PS3/360 (if that) it's unfortunate to be lightweight on CPU compared to those.  Things would have been so different if devs were porting games with ease, and reviewers were consistently giving the Wii U thumbs up over PS3/360.

Same article:

"There was even some discussion on trying to utilise the GPU via compute shaders (GPGPU) to offload work from the CPU - exactly the approach I expect to see gain traction on the next-gen consoles - but with very limited development time and no examples or guidance from Nintendo, we didn't feel that we could risk attempting this work.

If we had a larger development team or a longer timeframe, maybe we would have attempted it, but in hindsight we would have been limited as to what we could have done before we maxed out the GPU again. The GPU is better than on PS3 or Xbox 360, but leagues away from the graphics hardware in the PS4 or Xbox One."

In fact I think you know that aside from the line that said they couldn't take advantage of everything, this article was extremely damning of the Wii U including "it is unlikely that we would ever release another Wii U title.".

Anyway thanks for the debate.

I am quite happy with the quality of Nintendo games on the platform, but I don't expect miracles like some fans do.

ICS you also need to take into account that Wii U has way more cache so it can could have twice as much of sustained performance before cache forced to flush existing code to aquire needed one... Thats for core zero and two while core one has eight times the cache when compared to cell while xbox 360 has a 50% more cache than cell.

Yes, I agree (I think I mentioned bigger caches).  And this is not something you need to optimize for - it's just there and automatically makes more code run at higher IPC.  The cost of cache misses is greatly amortized.

If devs want more juice out of Wii Us CPU then they should use scalar/superscalar code and use Wii U GPU edram that it can access to reduce lantencies/time for further performance benefits.

Quoting random jargon doesn't add anything to this.

People that think showing pics of a game that has a dark/gritty/"realistic" art style vs. pics of a game with a more simplistic/colorful/cartoon art style is somehow "proof" of one piece of hardware being better than another, always have and always will be laughable. As in funny as hell.

ICS... That reply is unneeded.

We know that RAM of Wii U is apparently clocked at frequency of 1600Mhz, but we do not know CAS latency of it to further evaluvate the system. PlayStation 4 has GDDR5 RAM clocked at 5500Mhz(?) thus it has an atrocious CAS latency which isnt good for the CPU yet HSA/hUMA architecture counter it since less time is taken for data to reach CPU because it can access RAM that is being allocated for GPU and vice versa thus there is no need to copy data from RAM allocated for GPU to CPU/System like in UMA architecture in standard devices.

I wonder what CAS latency is for PlayStation 4s RAM since Naughty Dog in their presentation revealed that it takes 200 cycles before data reaches CPU L2 Cache/GPU thus in comparison estimate cycles for Wii U.

Just we are going in circles, and IMO you're spreading misinformation.

Since you've started taling about CAS latency you should search and see that CAS latency on PC makes little to no difference in real world benchmarks.