Jukka Larja (roskakori2006@gmail.com) on 9/23/09 wrote:
---------------------------
>AM (myname4rwt@jee.male) on 9/23/09 wrote:
>---------------------------
>
>> 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. :)
>
>Well, of course in-order system will clock higher, everything else being equal
>(which I state once again just to make sure, never is). Out-of-order adds complexity, so how could it clock faster?

You know, this "OoO adds complexity so in-order chips will clock higher" argument bears striking resemblance to what could be heard from various in-order bigots (rather than the likes of Hennessey and Patterson who Osmala referred to).

But EV6 came, and I can imagine how quickly the argument changed to "okay, but it's RISC", then Netburst came along and with no more milk in OoO-will-lose-on-clockrate cow left, various Jouni Osmalas and Jukka Larjas were left with the need to complain about something else. Like number of pipeline stages or IF-EX distance, but even those last-resort arguments don't seem to be valid in general on a closer look.

Do you actually realize that if an OoO machine's cycle time is limited by, say, int bypass loop, an in-order machine with the same integer unit won't clock higher no matter what? Or that complexity and low clock rate do not necessarily go together (hint: NetBurst)? Or that lack of dynamic scheduling does not necessarily mean simplicity or high clock (hint:Itanium)?

>In practise 1) you don't care about clock speed, but performance, 2) there are
>many other things that may have much larger effects on clocking.
>
>> 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.
>
>If I recall correctly someone (not sure if it was Jouni) already noted that some
>of the extra work can be done in parallel. Of course, there won't be some fixed
>number of stages required, since you can always just drop the clock speed (relatively speaking) and fit more to a stage.

I suggest you should read the discussion, lest the same things should be repeated over and over again. The point is, while particular implementations can pay an obvious cycle-time or pipeline-length penalty, it should be used to judge *particular design only*, not OoOE in general.

Is it really that hard to grasp?

>> You're kidding, right?
>
>Sure. And your kidding with your black-and-white praise of out-of-order, right?

What *exactly* of what I said do you consider a "black-and-white praise of out-of-order"? Please, don't be shy to point it out for me and those who follow the thread.

>> 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...
>
>Did you actually manage to come to an understanding on number of pipeline stages in those designs? :)

What about him and you?

>>> Has someone said OoOE is "utter waste of power
>>> and die space"?
>>
>> It was a paraphrase of your post. :)
>
>Well, I think this explains pretty much. Seems that there's at least some sort of language barrier between us.
>
>Irony and exaggeration may be fine in fiction, but when writing to multi-lingual
>audience, it's bound to lead to misunderstandings.

Never thought it would take a great deal of fluency to figure it out.

>>> 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.
>
>If it doesn't affect clock speed, then it obviously cannot affect power consumption, then how can it be a waste?
>
>I think the problem here may be that I'm reading you too literally and don't know
>when you are meaning "practically something" instead of just "something".

I'm starting to wonder what you're trying to say.

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

and now you say:
>... then how can it be a waste?

try to bring your point a little more clearly.

>> 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.
>
>Won what? There's no in-order 603. Sure, it looks good, but would it have been
>worse without OoO pieces (and with more in-order pieces)?

That there's no in-order chip in original PowerPC line, is *exactly* my point. Even 602 was a stripped-down 603 core, not an in-order design.

But hey, don't listen to what I say, better look at the chip's specs and do comparison with other available chips from that time frame on your own.

>By the way, if 603 (and A9) are "the *lowest end* of computing", what should I call lower power chips below them?

GP computing, I thought I didn't have to point out the obvious to you. Can you show me an in-order chip from that time frame with shorter time b/w IF and EX as claimed? If I'm not mistaken, this is the last straw left that you two are still catching at.

>> OoOE shouldn't be judged by Willamette and
>> its heritage.
>
>In general there are so many levels of being out-of-order that it would be pretty
>stupid to judge it by any individual case. Same goes for in-order and pretty much any high-level design idea.

Judging by worst (or just bad) examples will hardly help arrive at meaningful conclusions. Judging by the best, we will arguably tread on firmer ground. Funny how even this approach doesn't seem to help neither you, nor Osmala.

>> 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. :)
>
>Yeah, especially if you take into account possibility of changing workload :) .
>Still, simply the growing number of cores and problems with communication could
>result in making the cores generally speaking beefier, even for workloads like today, more beneficial trade off.
>
>-JLarja