Richard Cownie (tich@pobox.com) on 9/1/09 wrote:
---------------------------
>AM (@.) on 9/1/09 wrote:
>---------------------------
>
>>Actually, no, being OoO does not imply that a longer pipe is a necessary consequence
>>at all. Different OoO chips for different ISAs (PPC 603/604, R10k) had short pipes
>>(ca. standard 5 stages), IIRC Alpha team didn't grow pipeline from ev5 to ev6, keeping
>>it at 7 or so I think for int stuff, and while PPC603/604 were not stellar performers,
>>their dies and watts looked pretty good for the performance they offered. (*)
>
>But what I was talking about was comparing pipe length in
>terms of absolute latency, not just counting clock cycles.
>You can do anything in 5 cycles if you make the clocks
>slow enough ...

Okay, fine, please check the clocks of mentioned ev6 vs ev5 -- the former ended up being just a tad slower on the same process. Alphas were in-order for the first two generations and blew away anything else in terms of latency (not just ALU btw, L1 latency was excellent as well, so it should be clear they weren't sandbagging prior to ev6).

>And your examples are from the late 1990s,
>when everyone had relatively slow clocks and short pipes.

Well, IIRC Atom has 16-stage pipe with 2 stages for SMT, Core2 has 14-stage pipeline, right? In case you really meant not longer pipeline, but some limitations on clock rate or L1 latency for OoO designs, consider netburst, but then please don't change your argumentation back to pipe length again. :-)

>Googling around a little I get the impression that current
>and upcoming Intel designs look roughly like this (is this
>right) ?
>
>Nehalem 3.2GHz 4issue OoO 4cycle L1
>Atom 1.6GHz 2issue InOrder 3cycle L1
>Larrabee ? 2issue InOrder 2cycle L1
>
>Which is not to say that a slow/cheap/in-order design
>wouldn't be *better* - just that the win from out-of-order
>may be less when (for other reasons) you've got 2issue
>and a 2cycle L1.

actually, EV6 delivered a very visible performance boost over 4-wide 2-cycle-L1 EV5 on the same process and at roughly the same clock rate; the win vs. 2-wide chip would have been greater I guess.

The "win from ooo" has much more to do with the workload; take just about any array/stream processing task where one part of your working set sits cosily in regs and L1, while the other you can prefetch well in advance, and the win from ooo is about zero no matter how advanced and well-designed the ooo part is.

And speaking of LRB, I can't get my head around their choice of P54 as the basis; I don't believe P54 is more space- and power-efficient than 486 to deliver higher aggregated performance; and 386 core likely beats 486 as well.