someone (someone@somewhere.com) on 8/29/09 wrote:
---------------------------
>David Kanter (dkanter@realworldtech.com) on 8/29/09 wrote:
>---------------------------
>[..]
>
>>Irregardless, the point I was making was that Atom's design was probably largely
>>driven by TTM. OOOE designs are more complex and there is less opportunity to
>re-use existing pieces of Intel projects.
>>
>
>I am tired of your silly rationalization of your pet theory.
>Why don't you just look at what *Intel* SAID about the
>reasons for the design decisions behind Atom's uarch.

Because I'm not sure that Intel gave the whole truth and nothing but the whole truth.

>Look at slide 9 in presentation EMBS003 from the August
>2008 IDF.
>
>It compares the power consumption breakdown for the
>Pentium M to the Atom. OOOE consumed 26% of the
>Pentium M's power budget.

There are more efficient ways to do OOOE than what the P6 core does. I mentioned a couple.

> The only function group more
>power intensive was branch prediction+instruction fetch+
>decode at 30%. In fact OOOE in Pentium M consumed
>TWICE as much power as the integer and FP execution
>units and datapaths put together.
>
>In Intel's own words:
>
>In-order core provides reduced power through the removal
>of OOO execution logic (ex: re-order buffer, complex
>scheduling logic etc.).

Public reasons and private reasons can be different.

>OOOE is used to achieve high performance on scalar
>integer workloads but it hurts perfomance/power vs an
>in-order design.

That's not totally clear to me. I have seen papers that argue that, but they didn't seem that comprehensive.

Also, just using SMT doesn't really relieve you of the need to use OOOE. SMT doesn't accelerate single threaded performance.

>It is close to a wash on branchy scalar
>integer code but a big loss for FP and streaming data
>codes.

OOOE is always useful to hide cache misses and exploit more MLP in a single thread.

Also, the style of OOOE you are discussing has weaknesses for particularly branchy code.

David