Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C Programming > Greater than operator Vs Equal to operator : Which one is efficient?

Reply
Thread Tools

Greater than operator Vs Equal to operator : Which one is efficient?

 
 
Vivek Mandava
Guest
Posts: n/a
 
      09-05-2003
Hello All,

Which one is an expensive operation?
'>' or '==" ?

I know this won't matter much. However, if I'm executing this
operation million times, I would prefer the better choice.

My gut feeling is that '>' should be efficient. However, when
translated to assembly code all it generates is "cmpl" instruction
(gcc -S <prog.c>). So, my question here is :: how is "cmpl"
instruction executed by the cpu?

Ex: (1) if (n == 0) vs if (n > 0)
(2) if (len == 12) vs if (len < 13)

Thanks in advance.

Regards,
Vivek

web: http://students.iiit.net/~vivek/
 
Reply With Quote
 
 
 
 
Martin Dickopp
Guest
Posts: n/a
 
      09-05-2003
http://www.velocityreviews.com/forums/(E-Mail Removed) (Vivek Mandava) writes:

> Which one is an expensive operation?
> '>' or '==" ?


The C standard doesn't define the performance of these operations.

> I know this won't matter much. However, if I'm executing this
> operation million times, I would prefer the better choice.
>
> My gut feeling is that '>' should be efficient. However, when
> translated to assembly code all it generates is "cmpl" instruction
> (gcc -S <prog.c>). So, my question here is :: how is "cmpl"
> instruction executed by the cpu?


This is not a C question, but a question about assembler/machine code
on a specific platform. It is off-topic here; please ask in a newsgroup
dedicated to programming the CPU in question.

Martin
 
Reply With Quote
 
 
 
 
Jeff
Guest
Posts: n/a
 
      09-05-2003

"Vivek Mandava" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed) om...
> Hello All,
>
> Which one is an expensive operation?
> '>' or '==" ?
>
> I know this won't matter much. However, if I'm executing this
> operation million times, I would prefer the better choice.
>
> My gut feeling is that '>' should be efficient. However, when
> translated to assembly code all it generates is "cmpl" instruction
> (gcc -S <prog.c>). So, my question here is :: how is "cmpl"
> instruction executed by the cpu?


Why don't ask in your platform specific newsgroup ?


--
Jeff


 
Reply With Quote
 
Nils Petter Vaskinn
Guest
Posts: n/a
 
      09-05-2003
On Fri, 05 Sep 2003 01:25:30 -0700, Vivek Mandava wrote:

> Hello All,
>
> Which one is an expensive operation?


That would depend on both plattform and compiler I think.

int main()
int i,j;

i=INT_MAX;
j=INT_MAX;

print_system_time();

while(1) {
if (i == 0) {
break;
} else {
++i;
}
}

print_system_time();

while(1) {
if (j < 1) {
break;
} else {
++j;
}
}

print_system_time;

return 0;
}

hth
--
NPV
"Linux is to Lego as Windows is to Fisher Price." - Doctor J Frink

 
Reply With Quote
 
Tom Zych
Guest
Posts: n/a
 
      09-05-2003
Vivek Mandava wrote:

> Which one is an expensive operation?
> '>' or '==" ?


That's highly system-dependent and therefore OT here. That said, I'd
be surprised if there were any difference. It should use some kind
of "compare" instruction either way.

Why not put a tight loop of 10^7 of them in a function and run your
profiler on it?

--
Tom Zych
This email address will expire at some point to thwart spammers.
Permanent address: echo '(E-Mail Removed)' | rot13
 
Reply With Quote
 
John Bode
Guest
Posts: n/a
 
      09-05-2003
(E-Mail Removed) (Vivek Mandava) wrote in message news:<(E-Mail Removed). com>...
> Hello All,
>
> Which one is an expensive operation?
> '>' or '==" ?
>


That's entirely a function of the target instruction set, not the C
language.

> I know this won't matter much. However, if I'm executing this
> operation million times, I would prefer the better choice.
>


The only way to know for sure is to write code using each operator and
gather performance statistics on that code, recognizing that your
results are only valid for that particular architecture. FWIW,
they're equally expensive on all the platforms I'm familiar with (they
all generate similar instructions). I'd honestly be surprised if
there was a platform where one was significantly more expensive than
the other.

> My gut feeling is that '>' should be efficient. However, when
> translated to assembly code all it generates is "cmpl" instruction
> (gcc -S <prog.c>). So, my question here is :: how is "cmpl"
> instruction executed by the cpu?
>


Assuming you're on x86:
http://www.penguin.cz/~literakl/intel/intel.html

> Ex: (1) if (n == 0) vs if (n > 0)
> (2) if (len == 12) vs if (len < 13)
>
> Thanks in advance.
>
> Regards,
> Vivek
>
> web: http://students.iiit.net/~vivek/

 
Reply With Quote
 
E. Robert Tisdale
Guest
Posts: n/a
 
      09-05-2003
Vivek Mandava wrote:

> Which one is the more expensive operation?
>
> '>' or '==' ?
>
> I know this won't matter much.
> However, if I'm executing this operation million times,
> I would prefer the better choice.
>
> My gut feeling is that '>' should be efficient.
> However, when translated to assembly code
> all it generates is "cmpl" instruction (gcc -S <prog.c>).
> So, my question here is,
> "How is the 'cmpl' instruction executed by the cpu?"
>
> Ex: (1) if (n == 0) vs if (n > 0)
> (2) if (len == 12) vs if (len < 13)


The cmpl instruction is a subtraction which does *not* save a result.
It just sets some status register flags.
The branch instructions (je, jne, jlt, jle, jgt, jge, etc.)
test these status bits and branch accordingly.
None of them are inherently faster than the others.
Your CPU almost certainly includes branch prediction hardware
which it can use to prefetch instructions for the most likely branch.
Your compiler almost certainly includes optimizations
to assist branch prediction.

It is almost always a bad idea to attempt to outsmart
your optimizing compiler.
You will probably only succeed in frustrating these optimizations.
Write your code in the most straight forward and readable way
that you can and let your optimizing compiler figure out
how to generate instructions that yield the highest performance
and efficiency. If performance is not satisfactory,
use a profiler to locate the code that produces the bottleneck
and concentrate on optimizing that code first.

 
Reply With Quote
 
Christian Bau
Guest
Posts: n/a
 
      09-06-2003
In article <(E-Mail Removed) >,
(E-Mail Removed) (Vivek Mandava) wrote:

> Hello All,
>
> Which one is an expensive operation?
> '>' or '==" ?
>
> I know this won't matter much. However, if I'm executing this
> operation million times, I would prefer the better choice.


There are three things you can do:

1. Don't worry. Unless you get a measurable benefit from it, try to
write code that is readable and easy to maintain instead of trying to
make it fast. This will mean that you finish writing your software
earlier.

2. Check the assembler code. Check the manufacturers web sites for
manuals; absolutely everything you need is available; most will send you
a CD with the manuals for free.

3. Measure. Write two versions of the code and measure their speed.

Before you start doing anything: Make sure your code is correct. Once it
is correct, use a profiler which will tell you which parts of your
program spend the most time.
 
Reply With Quote
 
pete
Guest
Posts: n/a
 
      09-06-2003
John Bode wrote:

> I'd honestly be surprised if
> there was a platform where one was significantly more expensive than
> the other.


I've seen old 16 bit systems, (CHAR_BIT==8, sizeof(int)==2)
where equality of long int
was determined by an bitwise XOR of the high words (2 bytes==word),
followed by a zero flag condition check, and then if zero,
followed by an XOR of the low words and a zero flag check.
So, it was possible to bail out before entirely evaluating
either operand.
A long was compared for equality against zero, by ORing
the high word, with the low word and then checking the zero flag.

Equality vs inequality,
seems to me to be a simpler concept than greater than,
so when the equality or inequality operator,
does what I want, then that's what I use.

--
pete
 
Reply With Quote
 
Glen Herrmannsfeldt
Guest
Posts: n/a
 
      09-08-2003

"pete" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...

(snip regarding the performance of == and >)

> Equality vs inequality,
> seems to me to be a simpler concept than greater than,
> so when the equality or inequality operator,
> does what I want, then that's what I use.


But consider that, with twos complement arithmetic, <0 can be evaluated by
checking only one bit, where ==0 must test them all.

-- glen


 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Include header files in quotes or less-than greater-than signs? Dwight Army of Champions C++ 4 03-17-2010 06:39 PM
Greater than operator problem andybeh Javascript 3 02-07-2007 02:29 PM
regex problem: 'greater than' 'less than' and 'equals' not matching! falcon Java 10 02-24-2006 01:23 PM
Find Greater or Equal Massimiliano Alberti C Programming 3 02-20-2004 09:41 PM
IS string date greater than or equal to a SQL server datetime record? Hebar Tiltwobler ASP General 9 10-24-2003 07:31 PM



Advertisments