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?

> 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.

> 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 seems, however, that it is a waste on some workloads. 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.

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.

> 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.

> 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?

> 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?

> 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).

-JLarja