Question 2 about optimization
which one is better a>=6; or a>7
I think the a>=6 does two operations while a>7 does only one, so the second one is better. Am I wrong here?
I think the a>=6 does two operations while a>7 does only one, so the second one is better. Am I wrong here?
| which one is better a>=6; or a>7 |
Well, it depends whether a is an int (in which case they give the same answer and the compiler is entitled to rewrite one as the other) or a floating point number (in which case they would give different answers anyway).
I wouldn't worry about such extreme low-level optimisation. One thing I can say: it is highly likely that such operations will pale into insignificance compared with any serious numerical code.
Last edited on
Thanks @lastchance, btw, I am not worry, I am curious)
I am not caring about the values here, I want to know if I am wrong or right, I think the compiler in:
a>7 does only one comparison, where in a>=6 it does two comparison, In other way i think
"a>=6" == "a>6 || a==6"
I am not caring about the values here, I want to know if I am wrong or right, I think the compiler in:
a>7 does only one comparison, where in a>=6 it does two comparison, In other way i think
"a>=6" == "a>6 || a==6"
@ninja01,
The compiler is perfectly entitled to simply rewrite a>=6 asa>7(whoops, a>5) (if a is an integer). You cannot predict that.
It is also possible (particularly for user-defined types) that only one comparison operation (say <) is defined. Then, for example,
might be tested as
and
might be tested as
You simply can't prejudge what a particular compiler might do.
I have a slight preference for using < over > where possible, but it's only a personal preference (probably linked to a natural sense of order and the left-right order on the horizontal axis of a graph) - there's no programming reason for doing so.
The compiler is perfectly entitled to simply rewrite a>=6 as
It is also possible (particularly for user-defined types) that only one comparison operation (say <) is defined. Then, for example,
a==b |
!(a<b || b<a) |
and
a>=6 |
!(a<6) |
You simply can't prejudge what a particular compiler might do.
I have a slight preference for using < over > where possible, but it's only a personal preference (probably linked to a natural sense of order and the left-right order on the horizontal axis of a graph) - there's no programming reason for doing so.
Last edited on
First of all, note that a>=6 and a>7 does not mean the same thing.
a>=6 is equivalent to a>5.
a>7 is equivalent to a>=8.
(assuming a is an integer)
On x86-64 it seems like all these comparison operations gets compiled to the same cmp instruction and then another instruction is used to extract the result.
https://godbolt.org/z/ozYqajrMK <-- This is what I'm basing this on.
Note that GCC seems to prefer using the setg instruction (g = greater than) while Clang seems to prefer the setge instruction (ge = greater or equal to). Since they use different instructions it's probably because they have the same performance, otherwise they would both have preferred the same instruction.
My recommendation:
1. Use whatever is correct.
2. Use whatever is less error-prone.
3. Use whatever is more readable.
a>=6 is equivalent to a>5.
a>7 is equivalent to a>=8.
(assuming a is an integer)
On x86-64 it seems like all these comparison operations gets compiled to the same cmp instruction and then another instruction is used to extract the result.
https://godbolt.org/z/ozYqajrMK <-- This is what I'm basing this on.
Note that GCC seems to prefer using the setg instruction (g = greater than) while Clang seems to prefer the setge instruction (ge = greater or equal to). Since they use different instructions it's probably because they have the same performance, otherwise they would both have preferred the same instruction.
My recommendation:
1. Use whatever is correct.
2. Use whatever is less error-prone.
3. Use whatever is more readable.
Last edited on
depends on what the CPU and compiler can do.
http://unixwiz.net/techtips/x86-jumps.html tells you that the condition is directly supported on PC type chips. You could research which instruction is faster, or take it from there that there is no major difference.
but on some reduced instruction cpu or small & simple embedded, it may have to do at least 2-3 or possibly several more steps to jump on >= vs just >
the compiler may be able to translate it into a jump that the CPU understands, though, instead of generating the extra steps, esp like the example where constants are involved.
http://unixwiz.net/techtips/x86-jumps.html tells you that the condition is directly supported on PC type chips. You could research which instruction is faster, or take it from there that there is no major difference.
but on some reduced instruction cpu or small & simple embedded, it may have to do at least 2-3 or possibly several more steps to jump on >= vs just >
the compiler may be able to translate it into a jump that the CPU understands, though, instead of generating the extra steps, esp like the example where constants are involved.
Last edited on
integer comparisons at assembler level tend to be based on a test instruction which sets a set of flags and then a branch based upon 1 or more of how these flags are set. So a > and >= would both generate a test and a branch instruction - although the branch instruction would be different. eg
obviously only the requirfed j instruction(s) would actually be used. The point is that doing a > or >= or < or <= or == would usually take the same number of instructions.
|
|
obviously only the requirfed j instruction(s) would actually be used. The point is that doing a > or >= or < or <= or == would usually take the same number of instructions.
Last edited on
Topic archived. No new replies allowed.