Jouni Osmala (josmala@cc.hut.fi) on 9/20/09 wrote:
---------------------------
>>>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, so you couln't just assume
>>>it could clock higher with that design without changing design. 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)
>>>
>>>
>>>You where asking about strawman 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.
>>
>>An Alpha clocking higher than a low-PowerPC (sorry, couldn't resist...) processor?
>>Surely this must be caused by it being in-order :)...
>
>The discussion was about how much time was spend before execution stage, and his insistence that 603 was his
>"proof" that OoO logic wouldn't add time between IF&execution stage, by showing
>it has 4 cycle pipeline, and failing to understand that it just absorbed the extra
>delay from OoO logic compared classic risc pipeline design by increasing cycle time.

Maybe you're right, maybe not... but I simply can't see where 603xEV5 is a reasonable example of anything. It's a meaningless comparison if there ever was one, for many reasons:

1- 603 was a low-power low-cost low-area processor. EV5 was anything but, for it's time.

2- Even if they had the same goals, the teams were completely different. ISAs also were different. There's nothing to stop us from imagining that a "DEC Alpha 603" would be completely different (and clock higher) than IBM PowerPC 603. Hell, even StrongARM had higher clockspeed...

These two factors mean clearly that any kind of OoOExIn-Order will be simply too indirect to work. The oly way we could make a comparison (and not a good comparison) of the two methods would be if two processors were designed by the same team, with the same design tools and resources.

Now, I guess it's really obvious that if you bolt OoOE in a in-order design you will get lower clockspeed, more pipeline stages or something similar. But that is completely irrelevant to reality. Now, one can probably imagine that a equivalent in-order design would get the same benefits in a more realistic situation, but...

1- More pipeline stages aren't necessarily a problem, misprediction penalty on performance isn't that big and the cost in power is probably low.

2- Per clock, the OoOE processor will be faster in most if not all codes. The two processors just aren't comparable in performance goals.

3- Clockspeed is more complicated than that. Maybe the critical path are the ALUs?

4- Design is more complicated than that. Nobody will just bolt the ROB on the in-order design, they will be completely different and at this point saying anything about clockspeed depends on tons of things, and our comparison ceases to be meaningful.

>And it having VERY little OoO moving room meant that OoO performance gain should
>be pretty neglible compared to EV5 scoreboarding & instruction buffering. The clockspeed
>as is not the thing nor anyway comparable, the 2x time in the pipeline before execution stage is.

Do you really think that EV5 gained ALL it's clockspeed advantage over 603 because it was in-order, more pipelined and very general uarch things like these? I simply can't see this. AFAIK all other RISCs were in-order similar to EV4 in it's launch and they couldn't even touch the Alpha's clockspeed.

>
>>In fact your discussion is pretty sterile: there is no way you will find "equivalente"
>>processors to compare.
>
>Pretty much aggreeing on that. EV5->EV6 transition was the closest thing to it.
>But I'd rather have this discussion in the lower level details. But that would take
>even more time, which I don't have. And AM would need to read Henessey & Patterson
>book on the subject to actually start understanding things at that level.
>
>> These would be very bad design: OoOE isn't something you
>>add on your processor at eleventh hour, it's something that you develop your processor
>>with from the beginning. With all the usual factors (design team ability, goals,
>>tools, time, resources, various tradeoffs), OoO effects on pipeline timing are probably lost in noise.
>
>I have realized THAT a long time ago. Thats one of primary reasons I have tried
>to steer the discussion to lower level pipeline design. But AM sees to be stuck
>with number of stages in 603 pipeline, instead of starting to answer about the lower level stuff.
>
>>>>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.
>>
>>Even if it was that simple (and it isn't, in-order processors have their set of
>>clockspeed problems too), I don't really think it would be faster on real apps,
>>or they would simply keep their old design... also, EV6 wasn't just EV5+OoO, and
>>EV5 wasn't a simple in-order processor. You can't just take OoOE out of EV6 and
>>expect something to happen: it was built with OoOE in mind.
>
>I know that EV5 had stages that could be cut if making somewhat simpler inorder
>design. And that everything is designed from ground up to either OoOE or inorder
>pipeline, but endresults are what matters, and what I've seen in lower level details,
>the OoOE results longer critical path between instruction fetch and first execution stage.

That's a very bad comparison: the two processors were designed by different teams at different times. If you're trying to prove a theoretical point, I can agree with you, that it's obvious... but this model you're using is simply too simple to work in real life.

>I know that there are SOME techniques that I don't like that are used to make programmers
>optimization job easier with inorder designs, and those techniques cost some power
>AND the if-ex delay, which are the reasons I consider them ugly. Like register renamers
>on itanium & skewed memory pipeline in some other designs...

Well, engineers have to work with whatever programs they need to run, or we would already have tons of in-order GPU-like processors...