Jouni Osmala (josmala@cc.hut.fi) on 9/20/09 wrote:
---------------------------
>>>Hennessey & Patterson
>>>Computer Organization & Design.
>>>Think where you add register renamers & logic to chooce which instruction goes
>>>next to its pipeline. The only way for you to actually understand the underlying
>>>issue is to learn how to design inorder & OoO Pipele. Start reading it, and you
>>>understand eventually what I claimed is true. It adds time between IF->EX if you
>>>abstract time as pipeline stages you should acknowledge the clockspeed effect on
>>>time, then start thinking about alpha, for its time.
>>>
>>>The 4 stage pipeline is standard risc pipeline,
>>
>>http://en.wikipedia.org/wiki/Classic_RISC_pipeline
>>
>>just in case your memory is failing that much.
>>the OoO logic could be added to it without adding, pipeline stages,
>
>I told you to look at THE book that is used to teach computer design.
>That is not I deny is possible, but THAT cost clockspeed if you don't add the extra
>stage. The basic idea is simple ANY logic that increases number of gate delays
>between instruction fetch and execution either cost cycle time OR pipeline stage.
>And you haven't shown any way to design OoO pipeline without affecting the distance.
>The inorder pipeline can do parallel decode and register fetch, in classic risc
>parallerising, it requires checking RW dependency to previous instruction in same
>cycle, which can be done mostly parallel to register fetch & decode, and only one "and" gate required after that.
>
>Now OoO pipeline, register rename is done before register fetch.
>Also Other dependencies are
>decode->movetoReservationstation->issue from reservation station. These low level
>things couldn't done parallel. And just are serial work, that isn't split on 603
>to multiple stages which limit its clockspeed.
>603 the limiting problem isn't power its gate delays,

"the OoO logic could be added to it without adding, pipeline stages" is part of your own earlier post, I only gave you a refresher wrt classic RISC pipeline.

so you couln't just assume
>it could clock higher with that design without changing design.

I very much can, because many different references will tell you it was power-optimized. If you don't believe IBM on this, or its official power rating are a hollow sound to you, I doubt anyone can help.

So yes, 603 surely as hell can clock higher, its low power provides the headroom. And hey, I'm still waiting for you to come up with at least something in-order which would sortof justify what you said so far.

There's reason why
>apple got stuck so low clockspeed while having low power when amd and intel went
>to 1 ghz and consumed more power. (G4 also was limited by gate delays)
>
>
>>>but at that point you add TIME by delay.
>>>BUT still you would have to deal with a problem of having register renamer and
>>>THEN have to load registers. And need for instruction selection logic. If you understand
>>>what register renamer does you would understand that you cannot do that parallel to register fetch.
>>>
>>>The problem you have is that at this level you have abstracted a lot. You look
>>>1990's designs in a way that liming factor for clockspeed would be same as in 2000.
>>
>>I don't think I do. Anyway, feel free to compare 90s with 90s -- this is what I asked you in the homework.
>
>Z7 vs 603.
>I don't take home work from you.

You don't get it at all, do you? :)

I specifically leave out of discussion the clock-rate/power aspects of e200 cores, because process and design objectives matter a lot indeed. Feel better now?

e200 was mentioned b/c it could be useful in this in-order vs OoO context as perhaps the closest in-order PowerPC to 603. And e300 core which grew out of 603 is still 4 stages all the way to 90nm. I will give you some references now so in case you're totally incapable of finding information yourself (or just lazy), you'll at least deal with some facts:

http://www.freescale.com/files/abstract/overview/FTF_BN112.pdf - around p. 34-40 have some info on cores, pipelines and clock rates.

http://www.freescale.com/files/32bit/doc/white_paper/POWRPCARCPRMRM.pdf - p.12, ditto.

http://www.ip-extreme.com/downloads/Power_e200_Brochure_1.0.2.pdf

http://www.freescale.com/files/32bit/doc/white_paper/E200CORELCNWP.pdf - also some e200 data.

>>>Its not just power, its gate delays. Nowadays gatedelays are not the dominant factor,
>>>and you need to increase pipeline length just to keep wiredelays from dominating everything.
>>>You cannot compare things many processgenerations apart without acknowledging the difference.
>>>
>>>MY question is this, how can you put register renaming parallel to register access?
>>>I couldn't find a way, thats all thats is needed for increase the delay form IF to EX.
>>
>>IF-EX is not even what I called you on, although I'm *very* curious if you can
>>find a -- presumably -- chip built for performance that beats a low-power OoO chip
>>in terms of IF-EX delay. Go for it Jouni! See if you can back your point with some
>>facts in a challenge that's obviously made much easier for you than it could be!
>
>
>You where asking about strawman

Says the one who seems to have remarkably little respect to facts (NetBurst, Klamath, 603 being "in-order", etc. etc.). Did I forget any of your strawmen?

of having less than standard risc pipeline stages.
>What I'm all about telling its about TIME. There's plenty of reasons why inorder
>alpha EV5 clocked 4 times higher than 603 at same process.
>That means EVERY pipeline stages take one quarter of a time of 603. So basicly
>EV5 pipeline does take 1/2 of time of an 603 before the execution stage.

Dude, you compare a chip whose main (and arguably only) goal was performance to a chip in whose design apparently both power and cost were hard design constraints. Wow, you almost outdid yourself this time around.

So is that really the best in-order vs OoOE example you can come up with to "prove" your points? :)

>>And apart from IF-EX, you wrote:
>>"... However, with equal clock generation hardware inorder system would clock higher."
>
>In original context it simply means, if OoO chip had electrical design improvements
>same improvements could be applied to inorder design also. There was either
>A),B) OR C) If C chosen, then inorder design with C) is faster than original inorder
>design and higher than the resulting OoO chip with C.
>If however C&A are happening then both can clock as high, I didn't mention that
>since it was just a trivially deductible fact.

And yet your only "example" to back this up is EV5 vs 603? :) You weren't serious with that comparison, right? Or were you?

Let me clue you in a little: clocking scheme in Alpha didn't change just with coming of OoO; it evolved in EV5 and kept evolving for EV6. Perhaps more important for you to understand the underlying issues is that so did the misprediction penalty, from 4 to 5 in EV5.

See? You're basically barking up a wrong tree, when you blame certain things on OoO; and I think that's exactly why you're having such hard time finding examples I asked you for.

>>And what I asked was:
>>"More work (+ die space) -- yes, indeed, but the last statement is not obvious at all. Why?
>>Which part of OoO stuff imposes a hard limitation on clock rate, hittable by an
>>in-order chip, yet unhittabble by an ooo chip?"
>
>
>>http://realworldtech.com/forums/index.cfm?action=detail&id=102313&threadid=101547&roomid=2
>>
>>So why don't you defend the statement I called into question?
>
>Atleast that claim you put the link to is about potential three way trade off.
>Either increase pipeline lenth OR reduce clockspeed compare to similar inorder
>design, OR do other electrical low level improvements to compensate the extra logic
>delay caused by OoO logic compared to previous design.
>
>If the designers choose the THIRD option, then you could do same for inorder pipeline
>and clock higher. So third option is irrelevant other than showing that there is
>other methods to deal with extra logic delay than those two.

It doesn't look like the overheads are as high as you seemed to think, does it? All the datapoints we considered so far: PPC, Alpha, MIPS -- none of them backs your point even somewhat. Tell you what, if all my examples are somehow "wrong", "flawed", etc., feel free to bring your own. But where are they?

>>>Also just another SINGLE number on the z7. WHERE'S THE PIPELBetter than that, your
>>>example doesn't even show wether the number you just found somewhere, includes cache
>>>L1D accesstime OR mainmemory accesstime or what everINE DIAGRAM? Where's its spend!
>>>for those stages, and process generation & clockspeed & voltage. Also I'm pretty
>>>sure its not made in same process as powerpc 603.
>>
>>Did I imply anything wrt clock rate vs 603 or other designs? No. I only brought
>>this example up as these cores are all in-order, most of them single-issue -- as
>>your argument from the very beginning revolved around OoOE.
>
>Z7 is process generations apart, you looked about total pipeline length in isolation
>without looking what is included in the pipeline length. nada, what you brought
>about Z7 is irrelevant to our discussion without more details.

All I want you to learn and understand from this example is that a) even the simplest PowerPC cores didn't go for a shorter pipeline despite rock-bottom clock rates, b) slightly more complex PowerPC cores have longer pipeline while remaining in order.

I don't insist on clock rate comparison (which is in favor of e300, btw) for obvious reasons.

And the ONLY figure
>you mention is irrelevant as is, and what you would compare it against? 603 is not
>reasonable since they are too many process.
>Z7 is pipeline length is A datapoint. As such you need to show
>A) How many stages are before ex stage.
>B) How many stages for cache access?
>C) Does it have scewed pipeline aka. LOAD pipeline before execution pipeline.
>
>>And as for 603, feel free to consider 0.35 and 0.28 um process it was fabbed on.
>
>It was manufactured 0.5 and got 75mhz there and EV5 got 300mhz.

So you were serious after all? What are the insightful conclusions you arrived at?

>>>Thing is that wiredelays have gotten exponenetially worse relative to transistor
>>>delays each generation from that period so you start to need more and more buffers
>>>to keep clockspeed up for given voltage and cache access times go worse. It should
>>>hurt more for designs which need more area for something like OoO logic to run those signals over.
>>
>>Of course I do agree that physically larger core, w/o knowing anything else, is
>>likely to suffer more from signal-propagation delays. It was my own argument, in case you missed it.
>>
>>The thing is, it's ridiculous to connect this to OoO. Doing so is about as smart
>>as saying how caches take away precious die space and how larger caches hurt access latency.
>
>Actually OoO logic makes it larger, and where that logic resides? Just between
>if &exe. If you want Z7 as example you should put and OoO core of similar generation
>as counter example. I mentioned the cache accesstimes because thats really important
>for the Z7 and NOT important on 603 generation, and the number you gave for z7 doesn't
>say weather it has TWO cache accesstimes there or ONE. Anyway it has it in total pipeline lenth.

The point was meant to be mainly humourous actually. Oh well, if you insist on technology over having a healthy chuckle... Caches in many CPUs tend to occupy way more area then OoOE, with larger caches eating up more (pardon captain Obvious). EV6 had almost *half a die* in its L1s. And I$ latency has direct impact on misprediction penalty, doesn't it? So why did Alpha team go for slower caches and OoOE? They surely could have made an even wider in-order if they wanted, right? Only because of extreme shortsightedness and overall lack of expertise (compared to you), I guess. ;)