Jukka Larja (roskakori2006@gmail.com) on 9/24/09 wrote:
---------------------------
>My apologies for anyone who reads this to find technical content. There really isn't
>any. It's just meta-discussion where I try to cipher what AM actually means and
>explain to him what I mean. If I was a nice person, I would just let it be. Unfortunately,
>I spent years explaining things to students and maybe because of that it is hard for me to stop in time.
>
>AM (myname4rwt@jee.male) on 9/24/09 wrote:
>---------------------------
>
>> 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)?
>
>I don't understand the point of all this. I already told you my views were theoretical.
>I even stated that they are valid only if everything else is equal and that it never
>is. Why are you answering with practical examples?

It's pretty hard for me to believe that your claims like "of course in-order system will clock higher, everything else being equal" or "Out-of-order adds complexity, so how could it clock faster?" root in theory.

In case they really do, I'm very curious what theory you're referring to.

>I'm not a fan of in-order execution or simple cores. In general, more complex the
>core, more fun it is to read about it and discuss about it. As far as performance
>in practise goes, who cares how it is achieved? From that point of view computers
>are tools and I couldn't care less whether there's an in-order, out-of-order, VLIW,
>EPIC or whatever inside. I don't get my kicks from knowing that the very laptop
>I'm writing this on has OoO executing processor inside.
>
>So, really, stop implying that I have some fanboyish agenda in this discussion.
>If any, I'm a fanboy of theory over practise.

No implications; I don't take you for anything else other than what your writing suggests (and hardly anyone will). Theoretical fanboyism in my books is not any better than any other fanboyism, that's all.

>> 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?
>
>Well, I think you have made your opinion clear, but I still don't understand why.
>If you admit that there is a penalty that may in certain circumstances affect cycle-time
>or pipeline-lenght, why shouldn't it be said? Because you think it never (or hardly
>ever) happens in practise?

You seem to have gotten it completely the other way around (presuming you write what you think). Please read the beginning of this sub-thread if you joined in for content rather than useless babbling -- it started with claims re. OoOE *in general* (check posts signed "Jouni Osmala") which were dissected one by one. I lost count of how many times he adjusted his argument to slightly different or tried to "prove" it with downright wrong data.

>Well I'm not interested in that (well, I am, just not discussing it here).

Why a fanboy of theory would not make a good theoretical contribution then?

>>>> 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.
>
>Well, sorry if I understood wrong, but you are saying that OoO doesn't negatively
>affect clock speed or performance per watt and increases absolute performance.

Of course OoOE is not bound to constrain clock or result in inferior power efficiency as exemplified by *real* designs (as opposed to mysterious theory you refer to, which might say something different). But if that's the case indeed, I would strongly like to see some references.

>>>> 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?
>
>I don't know the right number if that's what you mean. My comment was mostly a
>funny way (see, a smiley) to point out the difficulty of discussing practise.

OK, so does it mean you have little interest in tech side of the discussion?

>>>>> 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.
>
>The problem really is that if I can't figure out when you are jesting and when
>you are not, I spend my time on answering to irrelevant, exaggerated claims instead
>of the ones that you actually mean. Just look at the beginning of this message.
>I actually thought there was a simple theory vs. practise misunderstanding there.
>But obviously it isn't just misunderstanding and clearly not simple.

Actually, so far noone has seen a *single* reference to theory from you to support the "in-order system will clock higher" and other claims. A factless discussion is a territory of *bigots*, theoretical fanboys would post some references.

>>>>> 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.
>
>Ok.
>
>1) You admit that on some workloads an out-of-order execution is a waste.
>2) You say out-of-order doesn't affect clock speed.
>3) 2) can only be true if OoO doesn't increase power consumption

Very interesting, why do you think so? Is that because some "theory" states that?

>4) So if 2) and 3) are true how can 1) be? Where is the waste?

Forgetting the broken logic in (3), the "waste" is no benefit in those special cases when static machine can execute given schedule as fast as one with dynamic scheduler would do.

Btw, it was stated by me at least once in this very thread: http://realworldtech.com/forums/index.cfm?action=detail&id=102312&threadid=101547&roomid=2

Maybe you should get hold of better books than ones you read, or at least spend some time rereading the thread instead of making others repeat the same to you?

>So, my thought was that you were just sloppy and I shouldn't take everything you
>say literally. That I should add things like "in practise", "for general purpose
>computing" and so to your statements. But that doesn't seem to work either, and
>I still don't really understand why. Is it just that you find theoretical discussion
>insulting or are you actually saying that even on the low-level the theory is wrong.

Please show me "the theory" that states what you say. I'm very much interested in seeing the references.

>> 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 that just means there's no good candidate to compare against. Not that I think
>there would be even if there was an IBM designed in-order 603ish processor. The ish is the problem.

Feel free to compare e200 vs e300, as proposed earlier. e200 is in-order, e300 is OoO, both available on the same process.

>> 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.
>
>You are very eager to sent me hunting something that I have said I don't expect
>to find. Are you sure you have any idea what I'm trying say?

You're quite right, I expected to see some constructive input from you.

>> GP computing, I thought I didn't have to point
>> out the obvious to you.
>
>Well, you didn't (I hope that was clear from my answer). I just asked to make sure.
>
>I have another dump question for you: is General purpose computing strictly defined term and what exactly does it mean?
>
>Sorry to ask, but since my whole answer so far seems to be just meta discussion
>circling around misunderstandings and explanations of what who thought he meant
>etc., I sort of want to make sure we have at least somewhat similar idea of what GP computing is.

I myself never felt a need for strict definition of adjectives like "embedded" or "general-purpose" (this is the first time I see such question asked) and I doubt someone like you can be satisfied even with an expert's answer. But hey, what has your theory got to say on this subject? :)

>> Can you show me an in-order chip from that time
>> frame with shorter time b/w IF and EX as claimed?
>
>To be honest, I don't even know exact 603s time frame, neither can I name any in-order
>processors from it. I don't find this problematic and unless you understand why,
>we are just going to have another exchange of meta-messages (or come to our senses and stop).

Okay, let's look at your theory then.

>> If I'm not mistaken, this is the last straw left
>> that you two are still catching at.
>
>Me and Jouni? Although we went to same university, I don't think I have ever seen
>him or interacted with him outside this forum, so I really can't speak for him.
>I have just seen the same messages as you have and it seemed to me you were reading
>him wrong. My mistake to think that I could be more clear.
>
>As for the straws, I don't feel like I need to catch any, which just underlines
>the fact that we are talking about different things here. Or maybe in a different
>way, since my different things theory doesn't seem to be working either.

Theory again? :) So where is a single reference or citation?

>>>> 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.
>
>Well, I was agreeing with you, or thought I was. Firmer ground doesn't really help if your still neck deep in it.

Even more so when all one sees from a "theoretical fanboy" is many words, zero references.

>-JLarja