By: Maynard Handley (name99.delete@this.name99.org), July 7, 2015 12:00 pm
Room: Moderated Discussions
Patrick Chase (patrickjchase.delete@this.gmai.com) on July 7, 2015 10:49 am wrote:
> Linus Torvalds (torvalds.delete@this.linux-foundation.org) on July 7, 2015 9:23 am wrote:
> > Patrick Chase (patrickjchase.delete@this.gmai.com) on July 6, 2015 10:31 pm wrote:
> > > And yet you yourself have (very effectively, with real data) made the argument that
> > > cmov seldom pays on x86.
> >
> > Absolutely. I think cmov a often a bad idea, because it leaves those data dependencies.
> > And because it's often a bad idea, it's probably under-utilized in some cases (and also
> > probably over-utilized in other cases).
>
> Back when I was mentoring people who did a lot of DSP-ish coding I saw a common pattern: There would inevitably
> come a time when cmov/select was the right solution for a performance issue, so I would show them the
> appropriate idioms to convince the compiler to emit it (or intrinsic, or asm directive). Most of them
> would then go batsh*t crazy and use selects in all sorts of inappropriate places. Modern branch predictors
> are pretty good, and over-utilization ends up being the bigger problem in my experience.
Maybe the problem is when I say cmov/csel I am thinking of the (IMHO) obvious use cases. max/min, abs, sgn, and the sorts of very similar functions I constantly dealt with when writing codecs (eg parse one bit then, if (bit){motionVector=-motionVector})
All of these strike me as PRECISELY the point of cmov/csel.
Perhaps it's my experience in this field where one CONSTANTLY has these sorts of one instruction branch-overs --- for clamping values, for non-linear edge smoothing, etc --- that makes me appreciate their value; and perhaps most people just don't encounter this sort of code in the code they write?
Now if people are idiots and want to use cmov in situation where, as you say
... the HW would also have to issue and execute all of the instructions on the not-predicted side of the branch.... [ie you should not be USING these types of instructions if we are talking MULTIPLE setup instructions, and MULTIPLE instructions in the branch's basic block]
What can I say? People are morons who will abuse any tool. We don't argue for the abolition of the FPU because some people are so stupid that they will use FP for what should clearly be integer data.
> Linus Torvalds (torvalds.delete@this.linux-foundation.org) on July 7, 2015 9:23 am wrote:
> > Patrick Chase (patrickjchase.delete@this.gmai.com) on July 6, 2015 10:31 pm wrote:
> > > And yet you yourself have (very effectively, with real data) made the argument that
> > > cmov seldom pays on x86.
> >
> > Absolutely. I think cmov a often a bad idea, because it leaves those data dependencies.
> > And because it's often a bad idea, it's probably under-utilized in some cases (and also
> > probably over-utilized in other cases).
>
> Back when I was mentoring people who did a lot of DSP-ish coding I saw a common pattern: There would inevitably
> come a time when cmov/select was the right solution for a performance issue, so I would show them the
> appropriate idioms to convince the compiler to emit it (or intrinsic, or asm directive). Most of them
> would then go batsh*t crazy and use selects in all sorts of inappropriate places. Modern branch predictors
> are pretty good, and over-utilization ends up being the bigger problem in my experience.
Maybe the problem is when I say cmov/csel I am thinking of the (IMHO) obvious use cases. max/min, abs, sgn, and the sorts of very similar functions I constantly dealt with when writing codecs (eg parse one bit then, if (bit){motionVector=-motionVector})
All of these strike me as PRECISELY the point of cmov/csel.
Perhaps it's my experience in this field where one CONSTANTLY has these sorts of one instruction branch-overs --- for clamping values, for non-linear edge smoothing, etc --- that makes me appreciate their value; and perhaps most people just don't encounter this sort of code in the code they write?
Now if people are idiots and want to use cmov in situation where, as you say
... the HW would also have to issue and execute all of the instructions on the not-predicted side of the branch.... [ie you should not be USING these types of instructions if we are talking MULTIPLE setup instructions, and MULTIPLE instructions in the branch's basic block]
What can I say? People are morons who will abuse any tool. We don't argue for the abolition of the FPU because some people are so stupid that they will use FP for what should clearly be integer data.