anon2 (anon.delete@this.anon.com) on April 28, 2017 5:42 am wrote:
> anon (spam.delete.delete@this.this.spam.com) on April 28, 2017 2:06 am wrote:
> > anon2 (anon.delete@this.anon.com) on April 27, 2017 5:00 pm wrote:
> > > anon2 (anon.delete@this.anon.com) on April 27, 2017 4:57 pm wrote:
> > > > anon (spam.delete.delete@this.this.spam.com) on April 27, 2017 4:10 pm wrote:
> > > > > anon2 (anon.delete@this.anon.com) on April 27, 2017 3:39 pm wrote:
> > > > > > anon (spam.delete.delete@this.this.spam.com) on April 27, 2017 2:39 pm wrote:
> > > > > > > Linus Torvalds (torvalds.delete@this.linux-foundation.org) on April 27, 2017 1:07 pm wrote:
> > > > > > > > anon (spam.delete.delete@this.this.spam.com) on April 27, 2017 12:28 pm wrote:
> > > > > > > > >
> > > > > > > > > Are you taking the piss?
> > > > > > > > >
> > > > > > > > > Or do you actually live in a world where
> > > > > > > > > cheaper = cheap
> > > > > > > > > and
> > > > > > > > > only option = cheap
> > > > > > > > > no matter the price?
> > > > > > > >
> > > > > > > > I'm living in a world where "cheap" is not some absolute number.
> > > > > > > >
> > > > > > >
> > > > > > > And I'm not just if this is a translation issue, but for me cheap and
> > > > > > > "cost effective" or whatever you want to call it are not the same.
> > > > > > > Something can cost millions and be cost effective, but I'll never call that cheap.
> > > > > >
> > > > > > For all general purpose CPU cores from sub watt smartphones to highest end servers, it is the
> > > > > > *cheapest* approach found. Going retarded and moving the argument to semantics now when that
> > > > > > clearly was not original intent is not helpful. Because you weren't just observing that it
> > > > > > is "expensive", you were using that as a justification as to why other approaches might be
> > > > > > viable. This is where your attempt to shift the goalposts just now falls on its face.
> > > > > >
> > > > > > It IS the cheapest of everything (and there have been quite a few) tried so far. So if
> > > > > > you try to use some absolute number for "expensive" then it still does not support you.
> > > > >
> > > > > Well if it were cheap then searching for alternatives wouldn't be worth the effort, that's my point.
> > > > > It's the cheapest of all things tried so far and that's why we use it. That doesn't
> > > > > mean we can't make it cheaper or that some cheaper alternative can't be found.
> > > > >
> > > > > I really do hate the claim that OoO is cheap. Other things being
> > > > > more expensive doesn't make the pains of implementing OoO go away.
> > > >
> > > > It's no worse than the claim that OOO is expensive. Actually it's
> > > > better, because alternatives are all proven to be more expensive.
> > > >
> > > > Despite your attempt to save face by claiming you were talking about absolute expense, expense is
> > > > always understood to be relative in such conversations when you are talking about alternatives.
> > > >
> > > > If you want to say instruction scheduling is an expensive component of the core therefore effort should
> > > > be put in to improving it, that's fine. But it does not automatically follow that because OOO is the
> > > > predominant techniques today, that non-OOO improvements should be tried above improvements to OOO.
> > >
> > > This might have been badly phrased. What I mean is this:
> > >
> > > Illogical: "OOO is expensive so alternatives to it have merit"
> > >
> > > Logical: "Instruction scheduling is expensive so it should be improved. OOO has so far proven
> > > to be the best set of techniques for that, so maybe we should look for improvements there."
> > >
> >
> > I wanted to reply to your first post already, but then I saw this.
> >
> > This is what I was trying to say.
> > OoO works well but it's expensive. So if you want to improve OoO reduce the cost first.
> > Or find something else that gets you the same performance for less. I don't care.
> >
> > To me it seems this whole "OoO is cheap" talk just ends with "well other things
> > were more expensive so it's alread cheap enough, nothing to improve here".
> >
> > I still believe that alternatives to it can have merit,
> > because it is imperfect. Not in a "wow this expensive,
> > surely everything else must be cheaper" way, instead more along the lines of "wow this is the best we could
> > come up with and it's still expensive. Would be great if there was a cheaper alternative.".
>
> I see your point, and it's not to say there is no reason to look elsewhere than oooe for improvement.
> But if you look at the bigger picture, the techniques for high performance are all expensive,
> but oooe has been the most successful so far, so it seems not unreasonable to expect the next
> improvement to come from improving oooe technology than an in order one. Doesn't it?

Yes. Didn't I say that? Did you assume because I called OoO expensive I was in favour of replacing it with in order? I'll support whatever is cheapest for a given performance and then still look for a way to make it cheaper or a cheaper alternative.
I guess it sounded differently because this all started with the Mill, which is in order. That would be the category of "cheaper alternative". Higher risk, potentially higher reward, definitely longer timeframe. Short term we'll see OoO improvements only. There's never a whole lot of high risk projects going on at the same time, VISC got stuck somewhere in limbo and the Mill keeps getting delayed so that'll be a few years too.