J
junky_fellow
which of the following is faster and why ?
if ( x == 1 ) {
}
or
if ( x != 0 ) {
}
if ( x == 1 ) {
}
or
if ( x != 0 ) {
}
B
baumann@pan
if (x!=0) if your cpu is x86, otherwise i don't know.
if you choose optimise, i don't know either
if you choose optimise, i don't know either
T
tigervamp
[email protected] said:
It depends on your platform, the Standard has nothing to say about
this. Why don't you test it yourself on your machine?
You should also note that the above tests are not equivalent. If x is
2 then the first test will be false while the second will be true. You
should be more worried about writing clear code that makes sense in
your situation and let the compiler worry about how to best perform the
test for you since it undoubtedly knows more than you do about how best
to optimize such an expression.
Rob Gamble
A
Alan Balmer
First answer the question of which gives you the right answer.
A
August Karlstrom
In practice it would probably be
if (x) { ... }
-- August
K
Keith Thompson
August Karlstrom said:
Not likely. "if (x)" is precisely equivalent to "if (x != 0 )".
There's no reason to expect that either will be faster than the other.
For any reasonable compiler, both will result in exactly the same
generated code.
On the other hand, comparing the speed of "x != 0" vs. "x == 1" is
unlikely to be useful, since they aren't semantically equivalent
(unless you can prove that the value of x is either 0 or 1).
B
Ben Pfaff
Keith Thompson said:
But that's a very common situation in C, because all of the
relational, equality, and logical operators yield either 0 or 1.
T
Thomas Matthews
The two comparisons are different.
In the first, you are comparing to an exact value,
the other you are checking for not zero.
Many processors have an instruction that allows
branching if a value is not zero, and also if
the value is zero. So, in some processors, the
second comparison can be reduced to a single
jump instruction.
In some processors, the first comparison requires
issuing a compare instruction to set the condition
codes, then a branch on that condition. Thus,
two instructions are required. If the values are
already in registers, some processors can execute
the first comparison with one instruction.
As to which is faster, neither. They break the
sequential flow of instructions. This break may
take up more time than the execution of the
instructions. For more efficient programs, try
implementing Boolean Arithmetic instead of using
compares. The objective is to reduce the breaks
in the sequential execution of instructions.
--
Thomas Matthews
C++ newsgroup welcome message:
http://www.slack.net/~shiva/welcome.txt
C++ Faq: http://www.parashift.com/c++-faq-lite
C Faq: http://www.eskimo.com/~scs/c-faq/top.html
alt.comp.lang.learn.c-c++ faq:
http://www.comeaucomputing.com/learn/faq/
Other sites:
http://www.josuttis.com -- C++ STL Library book
http://www.sgi.com/tech/stl -- Standard Template Library
C
CBFalconer
Keith said:
That depends on the optimization. There is no reason to prefer:
load x
cpi 0
jz ...
versus
test x
jz ...
where, for a suitable machine, the sequences will be generated by
slavishly following the C source. Being anachronistic, I prefer
having the control via the optimization level. Besides, a compiler
that is sufficiently slavish is probably much smaller and faster.
--
Some informative links:
http://www.geocities.com/nnqweb/
http://www.catb.org/~esr/faqs/smart-questions.html
http://www.caliburn.nl/topposting.html
http://www.netmeister.org/news/learn2quote.html
C
Christian Bau
A pointless question, since they don't do the same thing.
The rule of thumb for speed is:
1. If it doesn't work then speed doesn't matter.
2. If nobody pays money to make it faster then speed doesn't matter.
3. If it works, and if people complain that it is too slow, then it is
time to learn to use a profiler. If you haven't profiled it, then trying
to make it faster is a waste of time.
4. If you have to ask whether x==1 or x!=0 is faster, then you can be
sure that the answer will not solve any speed problems you might have.
W
Walter Roberson
Well, that explains MS Windows then ;-)
A
August Karlstrom
Christian said:
Note that the OP doesn't state that they do the same thing.
-- August
W
Walter Roberson
It gets worse than that -- it can depend on what's in the { }
afterwards. If the statements afterwards consist of relatively
simple calculations that set the same variable, then especially
on RISC machines with multiple internal execution units, the
compiler might choose to use a "move conditional" instruction,
computing -both- results and then moving the proper result in
depending on the result of the comparison.
(Some chips have elaborate interlocks about exceptions that might be
generated in the meantime, holding on to exceptions and only releasing
them when the appropriate instruction would be "fully graduated", and
discarding them if it turns out that that section wasn't executed
after-all.)
G
Guillaume
Nothing to add to what has been already said, except this:
I have been writing a lot of software, some very computation intensive,
and some with tight real-time requirements.
I have never ever had to bother with the speed of integer tests, except
maybe on some microcontrollers and way back on Z80 processors (4 MHz,
this does blow your mind doesn't it?) And even in those cases, I would
write routines in assembly language if speed was really a concern.
That said, even the dumbest C compiler will compile this kind of test
in the optimal way. You'd need to get a very, very old compiler to
actually find a difference in the object code.
The same goes for integer multiply/divide by a power of 2. Except when
it is clearer to the reader, you don't need to use shifting operators.
Over 12 years ago, Think C on the Mac already knew how to optimize
n / 2 as a right shift operation.
So, as other have said, you're most likely to be wasting your time
with such questions...
I have been writing a lot of software, some very computation intensive,
and some with tight real-time requirements.
I have never ever had to bother with the speed of integer tests, except
maybe on some microcontrollers and way back on Z80 processors (4 MHz,
this does blow your mind doesn't it?) And even in those cases, I would
write routines in assembly language if speed was really a concern.
That said, even the dumbest C compiler will compile this kind of test
in the optimal way. You'd need to get a very, very old compiler to
actually find a difference in the object code.
The same goes for integer multiply/divide by a power of 2. Except when
it is clearer to the reader, you don't need to use shifting operators.
Over 12 years ago, Think C on the Mac already knew how to optimize
n / 2 as a right shift operation.
So, as other have said, you're most likely to be wasting your time
with such questions...
C
Chris Croughton
Indeed it does, when I used Z80 they didn't go nearly that fast! 1MHz
was usual...
Yup. Done that...
Even the Aztec C compiler on the 8080 did that (actually, at one point
it had a separate optimiser which you ran on the generated assembler!).
Since the 8080 didn't have multiply and divide instructions, this saved
an enormous amount of code and time getting rid of the calls to compiler
support functions...
Indeed. But retro-programming is fun <g>...
Chris C
D
Dave Thompson
_For unsigned integers_. For signed, the round-in required in C99 and
universally or nearly so implemented though not required in C89,
differs from and thus can't be optimized to right shift on two's
complement which also is nearly universal but not actually required.
For signed but actually positive values, usually something like i/2U
will conveniently give a correct and optimizable result.
- David.Thompson1 at worldnet.att.net
V
Villy Kruse
Thus, compilers which optimizes divide by 2 to shift the value right will
first test if the value is negative. If it is, the value is then negated
before shift and then the result is negated to get the negative result.
Villy
C
Christian Bau
Dave Thompson said:
Ok, make that two instructions on a PowerPC for signed integers (one
shift right arithmetic, one add zero + carry).
B
BGreene
tigervamp said:
I have fixed many a line of code where someone or some program tried to
convert a program from a language which assumed the low order bit to be
"true". It is not always easy to find on an embedded system
.