Jouni Osmala (josmala@cc.hut.fi) on 9/14/09 wrote:
---------------------------
>---------------------------
>>Jouni Osmala (josmala@cc.hut.fi) on 9/13/09 wrote:
>>---------------------------
>>>>>>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.
>>>
>>>Branch missprediction grows based on L1I cache and beefing up of FRONT-END. I'm
>>>for simpler front-end more raw power in back-end. The Signal propagation problem
>>>for larger core depends on WHERE the larger structures are...
>>
>>Your point keeps evolving to something new with every single post. :) But at least
>>finally something you want, not how OoOE is a killer of clock rate etc.
>
>Original claim from first post I made in this thread.
>"OoO means more work in the earlier stages of pipeline, AND longer critical path from instruction fetch to execute."
>
[moved to end]
>
>>LOL, your English is okay for tech discussions (except for one or two cases when
>>I really didn't understand you), and I wouldn't count myself in rhetoric camp at
>>all, for we had a very fact-based argument (thanks to me) and have clarified a lot,
>>haven't we (beginning from pipeline length, through which process Klamath was fabbed
>>on, to what limited NetBurst uarches :))? Yeah, yeah, must have been done tens of
>>times even here at RWT and by people with much deeper insights, but I don't regret,
>>as the more I live, the more I'm convinced this is the best way to learn.
>>
>>Don't forget about the homework, Jouni Osmala, I'm very curious if you can accomplish
>>the task to back at least one of your opinions. ;)
>
>I think I have backed my original point more than enough
>
>"OoO means more work in the earlier stages of pipeline, AND longer critical path from instruction fetch to execute."
>
>That critical path can be split, aka add more stages keep clock speed. OR keep
>number of stages same go down clockspeed. Notice, it was between fetch&execute,
>the path that normally is in the branch missprediction penalty.
>
>
>Rest of it is dealing with couple of different ways how to handle the longer critical
>path. Length of critical path is in TIME, which then (numberofstagesinpath)*(clockspeed).

and adding your
>A) Increase pipeline length.
>B) Reduce clock speed.
>C) Improve enough some delay to compensate the extrawork
as the options,

is *EXACTLY* why I gave you the homework. Jokes/sarcasm aside, I'm genuinely interested how many examples (if any) can you provide of general-purpose, commercially available in-order CPUs which have 1-cycle fetch-execute distance. Or 2 cycles as in 603, but clock higher (200 MHz on 0.35um and 300 MHz on 0.28 um). What's important, 603 is indeed a true OoO machine (although with minimalistic resources), which renames registers and can move loads ahead of stores (so I presume loads can be reordered as well). If you believe IBM, that is.

By all means, feel free to show such examples to back at least one of your statements with facts (not forgetting that many other things you mentioned to "prove" your point, e.g. Klamath's process, NetBurst's cycle time constraint etc. etc. were downright wrong), as I'm starting to have doubts that something like that existed.