By: anon (anon.delete@this.anon.com), August 11, 2014 8:44 pm
Room: Moderated Discussions
Wow, what a huge load of rubbish. I shouldn't even dignify it with a reply.
Megol (golem960.delete@this.gmail.com) on August 11, 2014 8:10 am wrote:
> anon (anon.delete@this.anon.com) on August 9, 2014 5:03 am wrote:
> > Dynamic instruction count to solve a given problem is literally the final word in semantic expressiveness
> > of instructions. If the ARM decoder can take fewer cycles to decode a compiled program than x86,
> > then it objectively has the better throughput for that case. (obviously there are many more variables
> > for "goodness", but simply talking about decode width in this paragraph).
>
> Of course.
Yes, of course.
[snip strawman] We're talking about *decode*.
> > > Second: 2 wide
> > > is sort of a sweet spot - going wider is expending resources with diminishing returns.
> >
> > Of course, and again, a non-statement. 2-wide *is* a sweet
> > spot at that level... for x86. Because decoding is hard.
>
> No. Because it is the sweet spot. Go read some papers on scaling of processor structures.
No, there is no fundamental "sweet spot".
> > > The AMD Bobcat and relatives are also officially 2 wide decode. But it can do the same
> > > work as 4 RISC instructions, two integer operations and two memory operations.
> >
> > Look, obviously just taking datapoints and making assumptions/extrapolations
> > from there is never going to give
> > conclusive evidence one way or the other. That said, if
> > you think x86 decoding is _not_ a notable disadvantage
> > for the ISA, then you're just completely out to lunch, and against what any credible person I've ever seen
> > (not me, an anonymous internet poster is not credible, but former Intel engineers for example, are).
>
> Of course it is a disadvantage, can you point out where I said(wrote) the opposite?
I can point out vast amounts of handwaving and attempts to deny it or explain it away.
> But for a realistic design the disadvantage isn't notable
There's one right there ^^^
[strawman]
> >
> > How do you know?
>
> Because they haven't.
Two can play at that game. Yes they have.
Idiot.
> > > you mean here. They have temporarily compensated the decode bandwidth with the µop cache
> > > that have other advantages too inclusive lower power consumption for hot loops.
> >
> > For x86 decoders.
>
> No.
Yes, obviously uop cache helps lower power consumption of x86 decoders.
> > > The idea that going 8 wide isn't a problem is funny given the attempts
> > > in the past and the well known scaling problems in the area.
> >
> > For x86 decoders.
>
> *sigh*
> Go read some studies in the area - strangely they tend to use RISC pipelines...
Point to one.
> > Rubbish. The only dependencies in instruction decoding are for x86, because variable length instructions
> > means encoding of instruction depends on encoding of previous instructions. Fixed width has no such
> > issues. Dual width has obviously dependant pairs, but that's obviously easier to scale up.
>
> It is? Go earn some money then by describing how to do it.
It is already known just fine. See POWER8.
> > Many of these things are good regardless of ISA, but also other ISAs did not have to implement them. POWER6
> > had no store forwarding, POWER7 (I believe) did not have memory disambiguation, none of uop caches.
>
> Look I don't know how to respond to this. Do you really think what you wrote above is true?
You didn't know how to respond to anything else, but that did not stop you.
> > Oh, so it does have overheads now?
>
> Who claimed otherwise? Most ISAs have overheads - even the Alpha had some (minor) warts.
You, practically did.
>
> > > but those are in percentages nowadays
> >
> > Evidence?
>
> Go to news://comp.arch. Search for discussions in about x86 decode complexity or overheads.
> Get opinions and figures from people that have implemented both x86 and RISC.
>
> > > which can be
> > > more than compensated for by the development costs and larger chips the mass market can afford.
> >
> > Evidence? Certainly for smartphone space, the market says you're wrong.
>
> No the market says that they want to design their own SoCs and have very low prices
> for their processor designs. Intel have traditionally not worked like that.
Because they can't. Not for lack of trying. See: Atom, Quark.
Convenient how you respond with everything including outrage and insults, except for data.
Megol (golem960.delete@this.gmail.com) on August 11, 2014 8:10 am wrote:
> anon (anon.delete@this.anon.com) on August 9, 2014 5:03 am wrote:
> > Dynamic instruction count to solve a given problem is literally the final word in semantic expressiveness
> > of instructions. If the ARM decoder can take fewer cycles to decode a compiled program than x86,
> > then it objectively has the better throughput for that case. (obviously there are many more variables
> > for "goodness", but simply talking about decode width in this paragraph).
>
> Of course.
Yes, of course.
[snip strawman] We're talking about *decode*.
> > > Second: 2 wide
> > > is sort of a sweet spot - going wider is expending resources with diminishing returns.
> >
> > Of course, and again, a non-statement. 2-wide *is* a sweet
> > spot at that level... for x86. Because decoding is hard.
>
> No. Because it is the sweet spot. Go read some papers on scaling of processor structures.
No, there is no fundamental "sweet spot".
> > > The AMD Bobcat and relatives are also officially 2 wide decode. But it can do the same
> > > work as 4 RISC instructions, two integer operations and two memory operations.
> >
> > Look, obviously just taking datapoints and making assumptions/extrapolations
> > from there is never going to give
> > conclusive evidence one way or the other. That said, if
> > you think x86 decoding is _not_ a notable disadvantage
> > for the ISA, then you're just completely out to lunch, and against what any credible person I've ever seen
> > (not me, an anonymous internet poster is not credible, but former Intel engineers for example, are).
>
> Of course it is a disadvantage, can you point out where I said(wrote) the opposite?
I can point out vast amounts of handwaving and attempts to deny it or explain it away.
> But for a realistic design the disadvantage isn't notable
There's one right there ^^^
[strawman]
> >
> > How do you know?
>
> Because they haven't.
Two can play at that game. Yes they have.
Idiot.
> > > you mean here. They have temporarily compensated the decode bandwidth with the µop cache
> > > that have other advantages too inclusive lower power consumption for hot loops.
> >
> > For x86 decoders.
>
> No.
Yes, obviously uop cache helps lower power consumption of x86 decoders.
> > > The idea that going 8 wide isn't a problem is funny given the attempts
> > > in the past and the well known scaling problems in the area.
> >
> > For x86 decoders.
>
> *sigh*
> Go read some studies in the area - strangely they tend to use RISC pipelines...
Point to one.
> > Rubbish. The only dependencies in instruction decoding are for x86, because variable length instructions
> > means encoding of instruction depends on encoding of previous instructions. Fixed width has no such
> > issues. Dual width has obviously dependant pairs, but that's obviously easier to scale up.
>
> It is? Go earn some money then by describing how to do it.
It is already known just fine. See POWER8.
> > Many of these things are good regardless of ISA, but also other ISAs did not have to implement them. POWER6
> > had no store forwarding, POWER7 (I believe) did not have memory disambiguation, none of uop caches.
>
> Look I don't know how to respond to this. Do you really think what you wrote above is true?
You didn't know how to respond to anything else, but that did not stop you.
> > Oh, so it does have overheads now?
>
> Who claimed otherwise? Most ISAs have overheads - even the Alpha had some (minor) warts.
You, practically did.
>
> > > but those are in percentages nowadays
> >
> > Evidence?
>
> Go to news://comp.arch. Search for discussions in about x86 decode complexity or overheads.
> Get opinions and figures from people that have implemented both x86 and RISC.
>
> > > which can be
> > > more than compensated for by the development costs and larger chips the mass market can afford.
> >
> > Evidence? Certainly for smartphone space, the market says you're wrong.
>
> No the market says that they want to design their own SoCs and have very low prices
> for their processor designs. Intel have traditionally not worked like that.
Because they can't. Not for lack of trying. See: Atom, Quark.
Convenient how you respond with everything including outrage and insults, except for data.