>>>Power and space yes, the question is by how much. E.g. PPC750 and esp. 603 consumed
>>>only a few watts and had a very modest non-cache transistor count by any standards.
>>>What do you think power and pipeline-length overheads are there due to ooo?
>>
>>And both clocked for lower than other chips made in the same process tech...
>
>This is not true at all, and in case you have forgotten something Jouni, please
>refresh your memories from references. E.g. here is some info from Motorola PowerPC
>603e microprocessor fact sheet (you should find one easily):
>
>200 MHz @ 0.35 um, 81 sq.mm, 4/5 W typ/max
>300 MHz @ 0.29 um, 42 sq.mm, 4/6 W typ/max

600 MHz @ 0.35um EV56
And intel got 300MHz @ 0.35 (klamath)

So PPC WAS lower clocked, due to fact it was short pipeline.
So it isn't really a proof that with OoO you can have both short pipeline AND clock it high.

I never claimed OoO in isolation would of been THE reason to get low clockspeeds, I just showed that the counter example as a short pipeline wasn't really a counter example, as its far slower clocked than

>PPC603 is a 4-stage machine, and for comparison with x86 (as usual, from sandpile),

>P5 (5 stages)
>200 MHz @ 0.35 um, 83 sq.mm, 6.5/15.5 W typ/max
>
>P6 (~12 stages eff.)
>200 MHz @ 0.35 um, 196 sq.mm, 43/47 W typ/max
>300 MHz @ 0.28 um, 203 sq.mm, 28/43 W typ/max


>So cut your "clocked far lower" BS, Jouni.

600MHz VS 200Mhz is far lower, and 300mhz is compared to other OoO designs of same process node. So it PPC WAS clocked far slower than other designs on given process node.

Cut it and I still want to see what's
>the overhead due to ooo in terms of pipeline stages, cycle time or power consumption
>is in these chips as you say. Back your claims somehow, please.

I claimed that it costs, but EXACT quantifying of its effects by looking at chips of different kind by different designs isn't ANY kind of proof or disproof as there is million other variables. You want EXACT figures which is something I cannot really give, but what I can give is simple.
Inorder pipeline.

Fetch
decode/register fetch (both parallel)
Execute
writeback.

Now if you want to do register renaming, you need to do it BEFORE register fetch operation. Also you need to run some scheduling logic somewhere preferable after register renamer. For inorder pipeline its mostly detecting if there is stall. However with good design that is NOT on critical loop between fetch->execute, but with OoO its part of the logic selecting which instruction goes next, with inorder its obvious which instructions goes next, the only question is that is there structural stall, and stopping first pipeline stages until the results are ready.

Basicly OoO requires extra work BEFORE some work that is done on both OoO and inorder machine, and some work AFTER the decode but before execute, that inorder design you could sometimes put in parallel with execute...
That means you have longer dependency chain in OoO pipeline.

Its power costs, is about 27% by EV6 pipeline power consumption diagram, just for selecting the next instruction. And power limits todays designs...

>>>As for pipeline length, quickly checking, PPC 604e had 6-stage pipeline (fetch, decode, dispatch, execute, complete, writeback), and PPC750 outdid 604e with 4 stages, apparently combining decode+dispatch and complete+writeback; consumed a few watts and ISSCC presentation reports 500 MHz in 0.2um process: http://isscc.org/isscc/1998/ap/FP15.htm
>>>What is the impact of OoO on the length of the pipeline?
>>>
>>>In case you don't like old slow chips, let's take Netburst. Power efficiency is
>>>not its hallmark, but still how much do you think it lost in clock rate due to being an OoO design?
>>
>>I think what I'm all going to reiterate, Everything is a trade-off. Power-efficiency vs clockspeed is a trade off.
>>Pipeline length vs clockspeed on given process is a tradeoff. Now OoO logic costs
>>some of that TOTAL to be traded between other variables. And better implementation
>>techniques give that total, and for better or worse, only people capable of estimating
>>that well are the people who made the original design for each design. Software
>>people are as good estimating hardware design trade offs as economists are estimating software design decisions.
>>And what worst, the thing that we see it takes lots of research to find other components
>>of the trade offs and we most likely never get most of them.
>>OoO logic costs. It costs as much power as FPU and integer pipelines combined, for EV6 example.
>>Which isn't huge percentage but if we take away first percentage of clock since
>>that is somewhat dependent on how much other things are going on chip and then count
>>its percentage from the rest of the thing its about third of peak power consumption.
>
>I never argued ooo is free in terms of power or die space, so please save your time arguing that it does.
>
>>Sure you CAN do either 600W 6Ghz OoO chip, or 1Ghz low power OoO chip, or Equal charasteristics inorder chip.
>>The 1Ghz version is going to have shorter pipeline than 6Ghz version, UNLESS they
>>use the long pipeline to scale down supply voltage, which is another possible trade off.
>>I'd say without being OoO last P4 would have gotten the clockspeed it was designed
>>for, instead of hampered by power consumption.
>
>Are you really arguing that the latest netburst chips were power-limited specifically
>"because of ooo"??? I don't believe this.
>
>And feel free to consider netburst @ 0.18um and 0.13um. Would you also claim they
>are somehow limited in terms of clock rate because of OOO? This I would find extremely
>questionable. More likely the machine's cycle time was tuned to the timing of ALU
>units and their bypass network; maybe L1d, or maybe both of them. That is to say,
>I don't believe that the machine's clock is limited by ooo, show some proof for that.

Intel showed its ALU components in technical papers running MUCH higher frequency than they ever got in P4. Its power consumption was about maximum that they could sell. And OoO costs power -> (begin speculation) Lots of got good overclocking with insane cooling, and insane power consumptions, if overall power consumption of chip could of been reduced by getting rid of OoO logic, they could of gotten the higher frequency at given power consumption level. Although, that wouldn't of gotten a good chip, just highly clocked.

>>Well It was old. But lets put it this way I couldn't find anywhere any other mention
>>about than both more aggressive implementation techniques was used with EV6 than before.
>>Anyway those lectures where LONG time ago...
>But this is what you need to back your own claims that OOO necessarily costs more
>than die space and power! I think it's obvious that netburst (and to a large extent,

This paper:

Power Considerations in the Design of the Alpha 21264
Microprocessor
Michael K. Gowan, Larry L. Biro, Daniel B. Jackson
Digital Equipment Corporation
Hudson, Massachusetts


It Practicly tells that without new techniques not used on EV56, EV6 would of consumed more than twice the power consumption of EV56 on given clockfrequency. Both 4 wide chips. Its OoO logic consumed 18%, but 32% of power was consumed from clock which is proportion to area and clocked elements, So overall its 27% of EV6 just for OoO logic.
Just two techniques mentioned in paper are enough to save 40 watts over comparable structures in EV56. So overall EV6 without additional new powersaving techniques would of costed 110W. And equally clocked EV56 on SAME process consumed 55W... Both 2 wide one inorder other Outof order. Probably some other improvements make up for the difference.
But OoO logic costs power 30% in this case. Another nice case is that ALL integer execution units combined costs 10% of the power, which is pretty much place where I would prefer doubling it...

>K8) delivered the proof OoO doesn't have to cost cycle time even at very high clock
>rates, EV6 has shown that it doesn't have to cost not only very aggressive cycle
>time (if only just a little, as I don't believe the different circuit design you
>refer to could deliver a massive improvement), but extra pipeline stages, and finally
>*at least* some PowerPC chips show that OOO implementation can be very efficient
>in terms of power and die space without becoming embarassingly low-clocking or low-performing.

The embarassingly slow is relative. The OoO mainly costs power. The effect on pipeline length etc... depends on level of OoO you are aiming for. But for simple I'd assume by my very limited design experience that it increases pipeline lenght by somewhat, or slight reduction in clockspeed, or you need could compensate it somewhere else.
BUT now's a big but, there are dozen or more variables that can give about same size difference to pipeline length OR clockspeed, and not everyone of them is visible to anyone but design team, so no its something in which you cannot proof NOR disproof just looking multiple different designs, its only visible when you start trying to put together OoO pipeline, from inorder.

As for power consumption papers show between 30-50% increase. Some of that comes from fact that it keeps other units more busy, some of the fact comes from extra logic in choosing which instruction to go.

Anyway I think this is just conversation between someone who knows little about processor design, and someone who knows even less...