Jouni Osmala (josmala@cc.hut.fi) on 9/6/09 wrote:
---------------------------
>>>>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.

Logic reasoning and facts are hardly friends of yours, ain't they? You mention Alpha; it clocked at ~600 MHz in 0.35 um for both '164 and '264 (IIRC 575 MHz), same pipeline length, and it was way above *anyone else* in the industry, in-order or OoO, wasn't it?

Besides, as for Klamath, sandpile states very explicitly that it was fabbed in 0.28 um process. Is this wrong?

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

If sandpile is right, PPC603 clocked at *exactly the same* rate as both P5 and P6 on the same process node. And Alpha lost a little in clock rate (for unknown reason btw; could be thermals) going ooo while keeping #stages the same.

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

Isn't it possible to do at least some of ooo stuff (and maybe most of it) largely "in parallel" to an otherwise similar in-order pipeline? Because judging from same-length pipe for EV5 and EV6 it appears to me to be the case. And mentioned PPC603 had 4-stage pipeline (vs. 5 or more for several other in-order machines). What is/are the extra stages in PPC603 due to ooo?

BTW, you should be able to easily find a confirmation that PPC603 (which clocks at exactly the same rate as P5 and P6 if sandpile is correct about process) is a 4-stage machine: fetch, decode+isue, execute, complete+writeback. I wonder if you can find a source that states something different.

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

And I don't recall Alpha designers stating any other design objectives other than performance leadership.

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

Yes, there were such papers, but are you sure the papers you're referring to discuss Pentium4's ALUs for 0.18um and 0.13um as I asked, not later processes, or specifically designed ALUs, which may not be practical for a high-volume x86 chip at all?

And do you think 0.18/0.13 P4 could clock higher w/o going for a 3-cycle L1D even if it's not ALU-limited?

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.

You know, I can't help mention Itanium here. It never had a dynamic scheduler (it does have some pretty interesting logic in memory pipe, and this is one of the things I never really understood about Itanium -- having a "smart" ISA which allegedly alleviates the need for OoOE, and yet design cores which nooned would call simple or lightweight). And look at the clocks and power.

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

Okay, don't know if I read it, but will take a look nonetheless. Is there a copy I can grab off the 'net, for quick search doesn't help? If yes, then a hint will be good, no need to put a direct link.

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

So the difference is in power, something I never argued? I thought you could deliver some proof that EV6-style EV5 (otherwise identical) would have clocked much higher.

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

Then let me ask you something, Jouni. Are you a big believer in in-order for general-purpose processing, or some kind of UNbeliever in OoOE, despite all the facts mentioned in this thread and, I'm sure in tens of much more interesting and technically richer discussions at RWT and maybe other boards? Do you think that in-order (or maybe Itanium) will one day deliver cores which will make people mark OoO as a dead end in computer architecture and go back to in-order machines which will get wider and wider, higher- and higher-performing, as Itanium bonzos seemed to promise IIRC? What is it?

My take is quite simple, btw: in-order machines are good when dynamic scheduling is of little benefit -- various sorts of stream/array processing, when latency of loads doesn't vary much AND compiler can predict what they would be with high accuracy so it can build a good schedule resulting in small or no losses in execution compared to what an OoO machine would do. VLIW machines were a reality, and built for issue widths which Itanium didn't even touch so far (read up about Multiflow Trace). Besides, their designers didn't plan to conquer server space with them.

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

This is much more admitting and moderate viewpoint.

Actually, in case you really don't appreciate how efficient some ooo implementations are, why don't you take a closer look at said PPC603, namely its transistor budget, wattage and performance? Not necessarily for the sake of argument, but simply to appreciate it? Esp. how they compare with competitors. Design teams are different; merits of particular implementation styles should be judged by the best representatives for objectivity.

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

Not only that, but also between someone who bases his statements on facts and references and asks the other for proof, and someone who makes a lot of statements and repeatedly fails to back his claims. If I were a chip designer, I guess I wouldn't have much interest in discussion forums. Reminds me of an Alpha designer who is quoted as saying "you guys look all the same in my rear view mirrors" having appeared once on a discussion board...