which is faster ?

which of the following is faster and why ?

if ( x == 1 ) {

}

or

if ( x != 0 ) {

}

re: which is faster ?

if (x!=0) if your cpu is x86, otherwise i don't know.

if you choose optimise, i don't know either

re: which is faster ?

junky_fel...@yahoo.co.in wrote:[color=blue]
> which of the following is faster and why ?
>
> if ( x == 1 ) {
>
> }
>
> or
>
> if ( x != 0 ) {
>
> }[/color]

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

re: which is faster ?

On 16 May 2005 04:57:30 -0700, junky_fellow@yahoo.co.in wrote:
[color=blue]
>which of the following is faster and why ?
>
>if ( x == 1 ) {
>
>}
>
>or
>
>if ( x != 0 ) {
>
>}[/color]

First answer the question of which gives you the right answer.

--
Al Balmer
Balmer Consulting
removebalmerconsultingthis@att.net

re: which is faster ?

junky_fellow@yahoo.co.in wrote:[color=blue]
> which of the following is faster and why ?
>
> if ( x == 1 ) {
>
> }
>
> or
>
> if ( x != 0 ) {
>
> }
>[/color]

In practice it would probably be

if (x) { ... }


-- August

re: which is faster ?

August Karlstrom <fusionfive@comhem.se> writes:[color=blue]
> junky_fellow@yahoo.co.in wrote:[color=green]
>> which of the following is faster and why ?
>> if ( x == 1 ) {
>> }
>> or
>> if ( x != 0 ) {
>> }[/color]
>
> In practice it would probably be
>
> if (x) { ... }[/color]

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).

--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

re: which is faster ?

Keith Thompson <kst-u@mib.org> writes:
[color=blue]
> 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).[/color]

But that's a very common situation in C, because all of the
relational, equality, and logical operators yield either 0 or 1.
--
Go not to Usenet for counsel, for they will say both no and yes.

re: which is faster ?

junky_fellow@yahoo.co.in wrote:[color=blue]
> which of the following is faster and why ?
>
> if ( x == 1 ) {
>
> }
>
> or
>
> if ( x != 0 ) {
>
> }
>[/color]
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

re: which is faster ?

Keith Thompson wrote:[color=blue]
>[/color]
.... snip ...[color=blue]
>
> 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.[/color]

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:
news:news.announce.newusers
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

re: which is faster ?

In article <1116244650.578587.308870@g14g2000cwa.googlegroups .com>,
junky_fellow@yahoo.co.in wrote:
[color=blue]
> which of the following is faster and why ?
>
> if ( x == 1 ) {
>
> }
>
> or
>
> if ( x != 0 ) {
>
> }
>[/color]

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.

re: which is faster ?

In article <christian.bau-A0ED60.22315717052005@slb-newsm1.svr.pol.co.uk>,
Christian Bau <christian.bau@cbau.freeserve.co.uk> wrote:[color=blue]
>The rule of thumb for speed is:[/color]
[color=blue]
>1. If it doesn't work then speed doesn't matter.[/color]

Well, that explains MS Windows then ;-)
--
Warning: potentially contains traces of nuts.

re: which is faster ?

Christian Bau wrote:[color=blue]
> In article <1116244650.578587.308870@g14g2000cwa.googlegroups .com>,
> junky_fellow@yahoo.co.in wrote:
>
>[color=green]
>>which of the following is faster and why ?
>>
>>if ( x == 1 ) {
>>
>>}
>>
>>or
>>
>>if ( x != 0 ) {
>>
>>}
>>[/color]
>
>
> A pointless question, since they don't do the same thing.[/color]

Note that the OP doesn't state that they do the same thing.

-- August

re: which is faster ?

In article <7Unie.712$H24.111@newssvr17.news.prodigy.com>,
Thomas Matthews <Thomas_MatthewsSpamBotsSuck@sbcglobal.net> wrote:[color=blue]
>junky_fellow@yahoo.co.in wrote:[color=green]
>> if ( x == 1 ) {
>> if ( x != 0 ) {[/color][/color]
[color=blue]
>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.[/color]

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.)
--
Feep if you love VT-52's.

re: which is faster ?

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...

re: which is faster ?

On Wed, 18 May 2005 00:31:38 +0200, Guillaume
<> wrote:
[color=blue]
> 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?)[/color]

Indeed it does, when I used Z80 they didn't go nearly that fast! 1MHz
was usual...
[color=blue]
> And even in those cases, I would
> write routines in assembly language if speed was really a concern.[/color]

Yup. Done that...
[color=blue]
> 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.[/color]

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...
[color=blue]
> So, as other have said, you're most likely to be wasting your time
> with such questions...[/color]

Indeed. But retro-programming is fun <g>...

Chris C

re: which is faster ?

On Wed, 18 May 2005 00:31:38 +0200, Guillaume <"grsNOSPAM at
NOTTHATmail dot com"> wrote:

<snip>[color=blue]
> 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.
>[/color]
_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

re: which is faster ?

On Mon, 23 May 2005 02:31:37 GMT,
Dave Thompson <david.thompson1@worldnet.att.net> wrote:

[color=blue]
> On Wed, 18 May 2005 00:31:38 +0200, Guillaume <"grsNOSPAM at
> NOTTHATmail dot com"> wrote:
>
><snip>[color=green]
>> 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.
>>[/color]
> _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.
>[/color]

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

re: which is faster ?

In article <dnf291h4op2c0ievpoj57o36nuqn2eqtig@4ax.com>,
Dave Thompson <david.thompson1@worldnet.att.net> wrote:
[color=blue]
> On Wed, 18 May 2005 00:31:38 +0200, Guillaume <"grsNOSPAM at
> NOTTHATmail dot com"> wrote:
>
> <snip>[color=green]
> > 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.
> >[/color]
> _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.[/color]

Ok, make that two instructions on a PowerPC for signed integers (one
shift right arithmetic, one add zero + carry).
[color=blue]
> 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[/color]

re: which is faster ?

"tigervamp" <rgamble99@gmail.com> wrote in message
news:1116258059.498213.224430@g47g2000cwa.googlegr oups.com...[color=blue]
> junky_fel...@yahoo.co.in wrote:[color=green]
> > which of the following is faster and why ?
> >
> > if ( x == 1 ) {
> >
> > }
> >
> > or
> >
> > if ( x != 0 ) {
> >
> > }[/color]
>
> 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
>[/color]

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 :-).