Jukka Larja (roskakori2006@gmail.com) on 9/23/09 wrote:
---------------------------
>AM (myname4rwt@jee.male) on 9/22/09 wrote:
>---------------------------
>
>> I could go on, but hopefully the point is clear;
>> referring to theory to make up for fishy claims
>> is a sad excuse.
>
>Well, if your only point is that theory and practice disagree, you should probably
>just say so and move on. Its painful to see pages after pages of discussion where
>participants don't even seem to discuss about same thing.
>
>I mean, you don't really disagree with that OoO adds time between instruction fetch
>and execution, right? Sure, time added may be insignificant and "lost in noise"
>after everything else is accounted for, especially since there is such a wide range
>of being OoO. But just by looking at that detail, not thinking about performance of whole pipeline, you agree?

Actually, the only thing I called into question is that in-order system will allegedly clock higher with equal clocking. That was the starting point of the discussion after he posted. The claim was never retracted, by the way. :)

IF-EX distance can be discussed as well, but to begin with, I don't believe that authoritative text like H&P he referred to could state point-blank that OoO results in 2 more stages as he asserted. A NetBurt pipeline could have done that, but I think merits of OoOE should better be considered in a more general manner than looking at pipeline of what is probably least-efficient OoOE design ever made.

>> Sorry, but I don't think proof is the right word.
>> I would be really curious to see at least *anything*
>> which would look good for his points -- and this is
>> his job to bring it up.
>
>In a sense, wouldn't every in-order chip designed after invention of OoO make his
>point look good? Of course, there are other, more important reasons to choose in-order, so we can't actually know.

You're kidding, right? The only example he came up with to defend the point is EV5, and, oh, looks like even in his only example the time b/w IF and EX turns out to be...

3 stages @ 600 MHz in 0.35 um process vs
1 stage @ 200 MHz in 0.35 um process,

or about the same. :) Actually, considering that 603 could have been optimized for performance (or just operated with higher Vdd), it appears OoO would win this comparison by a good margin. :D

>> Besides, much of what you say is not what I ever
>> asserted.
>
>Quite possible. I didn't read the whole thread again and english isn't my native
>tongue. I'm pretty sure I couldn't even fully communicate what I think you have asserted :) .
>
>>> By the way, I have to ask: if out-of-order is
>>> so great and power efficient, why are GPUs
>>> in-order?
>>
>> That's a good question, but it begs a reply: if
>> OoOE is such a complete and utter waste of power
>> and die space, why even the lowest end of
>> PowerPC (603, 602) were OoO -- in times when die
>> space was *much more valuable* than now? Why ARM
>> is going OoO with A9?
>
>Has someone said OoOE is "utter waste of power and die space"?

It was a paraphrase of your post. :)

It seems, however,
>that it is a waste on some workloads.

Which I gladly admitted long before. Various sorts of array processing don't benefit much from dynamic scheduler.

Just like, say, dual-issue and branch-prediction
>is. It is hard to say, especially just by looking at designs, where some technology
>becomes useful. For example OoO core is harder to implement and validate than an
>in-order one. That has little to do with engineering per se, and more to do with economy.
>
>As for why specially 603, 602 and A9 are OoO designs, well probably, because their
>intented workload benefits greatly from OoO, they aren't too power/die-size/complexity/whatever
>limited and because they have enough money and expertise to pull it off.

These examples are to show that even for the *lowest end* of computing, where cost and power are important, certain teams dismissed in-order and won. How A9 silicon ends up remains to be seen though.

>In the end, OoOE's only problem is that given a certain clock frequency, it will
>eat more power than an in-order design (everything else being equal, which, of course,
>it never is). But it will also usually give more performance, which means you can
>actually lower the clock speed and voltage and save some power that way.
>
>So, is it a net win? I could probably spend another hour pondering about that.
>It depends at least on workload, performance target and process. Then there are
>a whole lot of economical reasons, which are probably more important, so I'm not
>sure it even worth discussing the technical aspects in too much detail.

I agree it depends on the workload (among other things), and probably even more on the expertise of designers when we consider real chips. Like nuclear power shouldn't be judged by Chernobyl accident, OoOE shouldn't be judged by Willamette and its heritage.

>> See? :) But don't answer, I would much rather
>> see Jouni answer this if he'll be back with
>> interesting examples.
>
>Well, I don't really see, I did answer and I don't understand why you are so fixated
>on what Jouni will do. Theory != practice. If that's all you care about, every detail
>is going to be too small to discuss. It will just be swamped by the whole.

Well, I think the question I replied with deserves to be asked (and answered) just as much, that's all.

>> Turning back to GPUs, if you want to know why,
>> there was a guy on this board (Hans) who can
>> give a very informative answer, and I would be
>> interested to see him post myself.
>
>I have been wondering for a while, how efficient designs GPU really are from engineering
>standpoint. In reality, much of design is determined by cost. It is easier to use
>as much of previous generation's design, just add more parallelism and avoid overly
>complex ideas. But if money was taken out of the equation, would GPUs still look much different?

Those guys had to compete for the past ~10 years, so that alone is imo a pretty good indicator they weren't sitting idle.

>> But if you want to hear something from me,
>> then I think the workloads they are mainly
>> bought for are such when benefits from dynamic
>> scheduling of code have been too small to
>> justify OoO design.
>
>Hmm. Are you saying that OoO would still be a benefit from performance / watt (and
>perhaps performance / area) point of view but just not from performance / design
>cost point of view? Or am I just reading what you wrote wrong?

You're reading probably a bit more than I put there, I said "have been" mainly because noone knows for sure what future will bring. :) It's a hard call; we could speculate that if shader models will get more and more relaxed, removing various constraints (like shader program length), and GPGPU really takes off, then performance benefits could well justify OoOE designs one day.

>> And back to CPUs, codes don't all behave the
>> way HPC stuff does in that compiler could
>> build a schedule for a given in-order machine
>> that would perform as fast as on a dynamic
>> scheduler.
>
>I would say that for where 603 and A9 are targeted, codes don't _mostly_ behave
>nicely. Although perhaps for most performance critical code the percentage is higher
>(wouldn't count on even that though).

603 was a GP chip indeed, the whole point of aim was to eat away a share of pc market.

>-JLarja