Jouni Osmala (josmala@cc.hut.fi) on 9/11/09 wrote:
---------------------------
>>>I look what each pipeline stage DOES, and EV6:s SINGLE exec stage does what EV5
>>>first exec stage does, and EV5 second exec stage functionality takes two more cycles
>>>than whats shown in the simplified pipeline of EV6. And by comparing the from fetch->
>>>end of THOSE instructions is even worse for EV6...
>>>
>>>In EV6 pipeline doesn't include L1 data cache latency, while EV5 pipeline includes
>>>L1 data cache latency as part of measurement of pipeline length. So its apples to
>>>oranges comparison, see number of execution stages in either pipeline BOTH have
>>>1 cycle and multicycle instructions, both pipelined, however EV6 diagram just don't
>>>show the multicycle instruction pipeline while EV5 does. But most relevant way of
>>>counting pipeline length is from Fetch to integer ALU result, which was done on
>>>EV6 pipeline, EV5 pipeline had L1 memory stage included AFTER the exec stage that was equal to EV6 exec stage.
>>>
>>>IF EV6 pipeline would of counted the same way as EV5 pipeline it would be 9 stage
>>>pipeline, due to fact that what EV5 did in 2nd execution stage, took EV6 a cycle
>>>more than in EV5 and it was omitted from EV6 pipeline diagram.
>>>
>>>What MY original claim was that OoO logic takes extra stage(s) between fetch and
>>>execute and THAT gives extra branch misprediction penalty, and that is THE extra
>>>cost for OoO execution besides the power and area costs.
>>
>>Actually you never mentioned mispredict penalty until now (probably because I asked
>>if you mix it up with pipeline length).
>
>Its the primary negative effect that comes with pipeline length, its direct RESULT of the increased pipeline length.
>Also term critical loop while being more general term, but when talking with main
>pipeline length equals misprediction penalty. Other critical loops are not important in this discussion.

I think one crucial point you're still missing (or just don't want to admit) is that pipeline and mispr. penalty can grow not *just* because of OoOE, it comes along as a natural by-product of pretty much ANY attempt to beef up a core with larger and thus slower structures, more ex. units with larger and thus slower bypass networks driving more loads, etc. etc. -- completely regardless of whether machine is static or not. Plus, larger core has direct impact on the time to propagate signals across.

Anyway. Here is one more datapoint for you to consider:

Consider R4400: in-order, 8-stage monolithic pipeline with 3-cycle branch delay, 250 MHz on 0.35 um.
And compare it with MIPS R10K: OoO, 5 stages int. pipeline, 200 MHz in 0.35um, 2-3 cycle misprediction penalty (+ possible delays).

Do the math, really.

>>>If you go read what each pipeline stage DOES then you understand that yes, there
>>>is logical reason why EV6 has another pipeline stage,
>>>
>>>I cut most of discussion to make my point simpler for you to understand by just keeping it on single simplest example
>>
>>Actually some of the things you said in the previous post would be much more interesting
>>to discuss (e.g. that in-order machines are a better option from performance point
>of view). I'm *very* curious why. :)
>
>Less power per executable instruction -> more cores per given power budget -> faster if running hand optimized code.

Very broken logic. The "less power per insn" is very much arguable. Do you want examples? Consider in-order machine like Itanium vs same-company-made Core2. Both are designed for performance, so you have no reason to complain, because we can also take some ULV parts for comparison.

The "hand-optimized" part only works when you not only have lots of ILP to take advantage of (presuming you mean very wide in-orders, not single- or dual-issue ones), but insn latencies don't vary much during execution (so that static schedule has little to gain from insn reordering), which is a *double* special case, limited pretty much to array/stream processing tasks, and by far not all of them.

>>As for EV6 pipeline length, DEC's papers are quite specific re. 7 stages of the
>>int. pipe, so unless you're on your way to show how they were misleading anyone
>>reading their papers for years, I don't see a point arguing that they probably didn't,
>>as there's remarkably nothing to gain (but potentially something to lose) from that.
>
>There are multiple reasonable way to count pipeline stages, and between EV5 and
>EV6 the metrics changed. Neither lie, but both measure different thing.
>EV5 pipeline is measured from Icache->Execute-Dcache-access->registerfile.
>EV6 pipeline is measured from Icache->Execute->registerfile
>And the Dcache access is shown as going to separate pipeline.

I don't know what pipeline diagrams you used, EV5 pipeline which you can find in original DEC papers shows memory pipe separately. So maybe you should start using good references? Take a look at DTJ paper, it has a detailed pipeline diagram and a very detailed description of the pipeline (vol. 7 no. 1 issue).

>>Mispr. penalty grew from 5 cycle in EV5 to 7 cycles in EV6, 1 extra cycle is likely
>>due to 64k I$, the other extra cycle might well result from something unrelated to OoOE as well.
>
>Its exacly because OoO it has dependencies that either limit the clockfrequency
>(to less than half of alpha) or takes 3 stages. Its partially because OoO takes
>more area->Longer distance to transfer things AND more complex logic-> longer logic path.
>
>>And, btw, why don't you take into account that EV5 also increased mispr. penalty
>>by a cycle from EV4 while staying in-order (and I would suggest you check a few
>
>EV5 has slightly more complex instruction selection than EV4 & buffering stage
>to separate execution from instruction fetch which is something thats always seen
>in OoO pipelines but rarely in inorder pipelines.
>But that buffering&selection is still my point, there is extra work there that
>costs latency. What made EV5 longer than EV4 was the extra work it needed to do
>in those stages, checking and buffering instructions, just like OoO is extra work
>in selecting & buffering instructions. It clearly was worth it but it had costs...
>Of course they COULD of done it without adding extra stage, but then it would of
>cost clockspeed which would of been counter productive...

Your point seems to make good progress towards becoming totally meaningless. Nothing goes without costs. The more EUs you have (regardless of in-order or OoO core), the larger and slower are your bypass networks; the larger the caches, the slower they are, etc. etc. So is there any sense left in your point anymore, really?

>>sources rather than just trust me)? Do you admit a possibility that one more extra
>>cycle of mispr. penalty in EV6 is also a result of physically larger, more capable
>>core, in which some circuits/units have higher latency as a direct consequence of
>>getting bigger, and the distances signals have to travel are longer? After all,
>
>OoO Logic costs AREA between instruction fetch and instruction execution -> that
>area increases distances -> OoO logic cost time between instruction execution&instruction fetch stages.

Judging from facts, the losses are very small. Certainly small enough to justify OoOE when performance and power efficiency are important.

>>I hope you wouldn't characterize EV6's slower L1 caches as the "price" designers
>>had to pay for going OoOE. :) Or would you?
>
>I wouldn't, but one thing about that large cache is that it still has single cycle
>access to its array, so the effect of that is LESS than a single clock cycle, since
>it takes some time access even the 8kb array. D-cache latency has lot of logic before
>and after the array access thats why it is longer than 1 cycle.

Another angle to look at it is that there was no easier way to design caches for EV6 than to inherit them from EV5. At the same cycle time, it would still be 2-cycle cache. The point is, apparently larger but 1-cycle-slower caches were judged to be a better option. See? You can't have your cake AND eat it; a better design is one that makes right tradeoffs in the course of design for given objective. Hopefully now things are more clear for you and you can rethink some of the things discussed here armed with good references.