Is there any difference in the performance of the following two lines:
1. if (a == b) c++;
or
c += (a == b);
Is any of these faster?
Performance question
Moderators: hgm, Rebel, chrisw
-
- Posts: 20943
- Joined: Mon Feb 27, 2006 7:30 pm
- Location: Birmingham, AL
Re: Performance question
Probably not enough to worry about. using CMOV, the compiler could produce the same code for either of those.metax wrote:Is there any difference in the performance of the following two lines:
1. if (a == b) c++;
or
c += (a == b);
Is any of these faster?
-
- Posts: 344
- Joined: Wed Sep 23, 2009 5:56 pm
- Location: Germany
Re: Performance question
Sorry, what is CMOV?
-
- Posts: 6401
- Joined: Thu Mar 09, 2006 8:30 pm
- Location: Chicago, Illinois, USA
Re: Performance question
The second one is incorrect and it is not guaranteed to give you what you expect. (a==b) could give you any number as long as is not zero! Even if it does, it hurts readability.metax wrote:Is there any difference in the performance of the following two lines:
1. if (a == b) c++;
or
c += (a == b);
Is any of these faster?
Stay away from it!
Miguel
-
- Posts: 750
- Joined: Mon Mar 27, 2006 7:45 pm
- Location: Finland
Re: Performance question
Agree about the poor readability, but (a == b) is guaranteed to return either 0 or 1, at least in C.michiguel wrote:The second one is incorrect and it is not guaranteed to give you what you expect. (a==b) could give you any number as long as is not zero! Even if it does, it hurts readability.
-
- Posts: 20943
- Joined: Mon Feb 27, 2006 7:30 pm
- Location: Birmingham, AL
Re: Performance question
Last time I looked, ansi standards said 0 or 1 for that. The test for true will take any non-zero value for true, but a == b is supposed to return 0 or one only, so far as I know. Other languages are different (Fortran used to use -1 for true on many machines, as one example).michiguel wrote:The second one is incorrect and it is not guaranteed to give you what you expect. (a==b) could give you any number as long as is not zero! Even if it does, it hurts readability.metax wrote:Is there any difference in the performance of the following two lines:
1. if (a == b) c++;
or
c += (a == b);
Is any of these faster?
Stay away from it!
Miguel
-
- Posts: 20943
- Joined: Mon Feb 27, 2006 7:30 pm
- Location: Birmingham, AL
Re: Performance question
It is an instruction on processors since the intel pentium pro that can be used to eliminate a branch.metax wrote:Sorry, what is CMOV?
cmp eax, 0
cmoveq eax, mem
is a simple example.
The cmp instruction sets the usual flags (zero, sign). the cmoveq tests the flags to see if the result of the comparison of eax to zero was "equal" or not. If eax was equal to zero, the cmoveq instruction moves the contents of "mem" into eax, otherwise it does nothing. It avoids the usual:
cmp eax, 0
jne skip
mov eax, mem
skip:
type of conditional jump that requires prediction, which when it is wrong causes a pipeline drain and re-start.
-
- Posts: 778
- Joined: Sat Jul 01, 2006 7:11 am
Re: Performance question
The standard does actually guarantee that the result of a logical expression is either 0 or 1. I was looking into a similar question:michiguel wrote:The second one is incorrect and it is not guaranteed to give you what you expect. (a==b) could give you any number as long as is not zero! Even if it does, it hurts readability.metax wrote:Is there any difference in the performance of the following two lines:
1. if (a == b) c++;
or
c += (a == b);
Is any of these faster?
Stay away from it!
Miguel
The expression "if ((a==b) || (c==d))" requires two branches to allow short-circuiting if the first part is true. If the parts are independent, for performance reasons you could code it as "if ((a==b) | (c==d))", which just looks wrong to me.
-
- Posts: 5106
- Joined: Tue Apr 29, 2008 4:27 pm
Re: Performance question
Are you sure about that? I'm pretty sure it is implementation defined unless that has changed.bob wrote:Last time I looked, ansi standards said 0 or 1 for that. The test for true will take any non-zero value for true, but a == b is supposed to return 0 or one only, so far as I know. Other languages are different (Fortran used to use -1 for true on many machines, as one example).michiguel wrote:The second one is incorrect and it is not guaranteed to give you what you expect. (a==b) could give you any number as long as is not zero! Even if it does, it hurts readability.metax wrote:Is there any difference in the performance of the following two lines:
1. if (a == b) c++;
or
c += (a == b);
Is any of these faster?
Stay away from it!
Miguel
-
- Posts: 5106
- Joined: Tue Apr 29, 2008 4:27 pm
Re: Performance question
I specifically remember searching for this a few years ago because I wanted to be able to safely make that assumption, but I had to reject it. Now I'm trying to figure out if I'm remembering this correctly.bob wrote:Last time I looked, ansi standards said 0 or 1 for that. The test for true will take any non-zero value for true, but a == b is supposed to return 0 or one only, so far as I know. Other languages are different (Fortran used to use -1 for true on many machines, as one example).michiguel wrote:The second one is incorrect and it is not guaranteed to give you what you expect. (a==b) could give you any number as long as is not zero! Even if it does, it hurts readability.metax wrote:Is there any difference in the performance of the following two lines:
1. if (a == b) c++;
or
c += (a == b);
Is any of these faster?
Stay away from it!
Miguel
I looked on wikipedia under boolean data types and they have a section for several common languages.
In the section on the C language it says this:
and later is says this about C:To this day, Boolean values are commonly represented by integers in C programs. The comparison operators (' > ', '==', etc.) are defined to return a signed integer (int) result, either zero (for false) or nonzero (for true).
So I think you are mistaken or the wikipedia entry needs to be corrected.However, since the C language standards allow the result of a comparison to be any non-zero value, the statement if(t==1){...} is not equivalent to if(t){...} or to if(t!=0){...}.