Each core can retire 2 instructions per cycle but it's not the same as multithreading.

It has SMT and MESI/MERSI, don't deny factual evidence that you can find on your own.

Otherwise Xbox 360 and PlayStation 3 games wouldt work at all.

Gaf says different. The pipeline is so short that it doesn't need SMT.

Just had a look at Marcan's findings which basically confirm what I've said. It doesn't have SMT, it has SMP (Simultaneous Multi Processing) support, and the fact that it has MESI/MERSI support would also point to it not having SMT.

The Wii U has been designed and built from the ground up to be efficient, it's CPU having MESI/MERSI support with SMT would be throwing a bloomin great big spanner in the works.

Again, Expresso is a completely custom chip. It's not 3 x Broadways duct-taped together. The 950 line that the chip is based on are single core chips that don't clock over 1GHz. Whilst it isn't a completely different animal there are quite a few important differences.

I confused SMT with SMP... :P

I know for MESI/MERSI... Even before Marcan.

That instructions per cycle is fairly low, but not really unexpected, even Jaguar can do 4 instructions per clock and that's the worse CPU AMD offers, still it's only one part of a puzzle.

The WiiU doens't have multi-threading, nor does it need it, nor is multi-threading a linear increase in performance, it's just a way to gain more efficiency out of idle compute resources on a per core basis, not such a problem for a core with a tiny pipeline.
With my 6 core, 12 threaded processor I might gain an extra 30% performance improvement if I am *super* lucky and the application can utilise every single thread, my processor is also far wider both in the back and front ends with significantly more caches and interconnect bandwidth.

The *major* difference is the Out-of-Order execution.
Basically what occurs is that with an in-order design, if a calculation cannot be performed for what-ever reason straight away, the CPU idles, wasting clock cycles.
Out-of-order however will just schedule another instruction to be performed instead and if there is no delay for the old idle instruction, that will be performed straight after, it's an efficiency boom for the WiiU. (Seems to be a major focus of the console, efficiency.)

If a GPU or CPU has idle pieces of silicon, that's not efficiency, it's waste, the WiiU's CPU is indeed efficient compared to the Xbox 360 and Playstation 3, even if it is still an incredibly poor performer like every console ever built, they simply don't take CPU performance seriously, good enough is well, good enough I suppose.

Yup, I'm fully aware of how out-of-order execution works. That's one of the main reasons why quick and dirty ports have had performance issues, because the PS3 and 360 code is designed around in-order CPUs as I've mentioned a few times on here. Xenon and the Cell having to handle sound and both consoles being 'CPU heavy' as opposed to all 3 current gen consoles being 'GPU heavy' in terms of floating point work are also important factors.

Developers will find it a great deal easier to port between the Wii U/PS4/One than it currently is to port between the Wii U/PS3/360.

The Litmus Test is going to be Project CARS, I think a good few people are going to be surprised at what the Wii U is capable of even at this early stage of its lifespan.

Seeing Super Mario 3D World, Mario Kart 8, Bayonetta 2, X and SSBU in action certainly put my mind at rest with regards to the technical quality of eye candy the Wii U is capable of producing, particularly with the amount of polys that Super Mario 3D World and Bayonetta 2 are pushing in 720p native resolution at 60fps with v-synch enabled.

PS3/360 both use the same central PPE design, just in different layouts. (The primary "controller" core for Cell's SPEs is more or less a single core Xenon)

Espresso, on the other hand, is from the PPC750 family of processors.

If you forcefeed code designed for one CPU setup onto a substantially different one, the results will obviously not be optimal.

I'm sorry but it's not obvious.  You don't have something concrete, only a guess that it's so substantially different that porting results are not optimal in a meaningful way.

http://www.eurogamer.net/articles/digitalfoundry-2014-secret-developers-wii-u-the-inside-story

"Code optimised for the PowerPC processors found in the Xbox 360 and PlayStation 3 wasn't always a good fit for the Wii U CPU, so while the chip has some interesting features that let the CPU punch above its weight, we couldn't fully take advantage of them."

"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."