lkml.org 
[lkml]   [1998]   [Jun]   [1]   [last100]   RSS Feed
Views: [more markup]  [less markup]  [headers]  [forward] 
 
Messages in this thread
/
DateMon, 1 Jun 1998 18:12:40 +0900 (CDT)
FromLin Zhe Min <>
SubjectRe: What is faster: jne or jge?
As this seems not to be a kernel issue, I apologize to everyone who is 
allergic to off-topic messages.

On Sun, 31 May 1998, Simon Kirby wrote:
> On Sun, 31 May 1998, Tigran Aivazian wrote:
> 
> > Hello guys,
> > 
> > Someone asked me a simple but classical question:
> > 
> > What is better:
> > 
> > This: if (some_syscall() < 0) {
> >         ....
> >       }
> > 
> > Or this: if (some_syscall() == -1) {
> >          ....
> >          }
> > 
> > For some system calls (e.g. lseek(2)) one does not have the luxury of
> > choice (because negative results aren't necessarily erroneous) but for
> > most others it is only a matter of taste and both are "right"; so I
> > answered "since in the first case cc(1) will generate jge
> > instruction and in the second jne it depends on what is faster: jge or
> > jne".
> > 
> > But what *is* faster? I don't know. And Intel's website doesn't
> > immediately face one with something useful, such as a table of timings of
> > their instructions or detailed specs of some future generation
> > processors but instead greets one with tons of useless b.s. :)
> 
> Both instructions are equally expensive.  ja, jb, je, jne, jg, jl, jge,
> jle take the same number of cycles.  It's been this way on every version
> of the x86, I believe.
> 
> So, (x < 1), (x <= 1), (x == 1), (x != 1), etc., are all the same.  This
> is only on an Intel chip, however.  I'm not sure about others...


First, I think I really agree with Monnier that you should never think of 
which is _faster_ in this kind of situation. You may use what is the most
obvious.

Compare to any value other than 0 will cause some code like:

cmp ax, -1		(in a MASM form, rather than GNU as'es one)
jle SomeWhere		(or ja, jb, jl, jge...)

They use same instruction circle, like what Simon said. However, when
comparing with 0 it should be something like (I'm not sure if GCC is so
wise to do this):

or ax, ax
jle SomeWhere

But the key point is: (according to Intel's 80386 Programmer's Reference)
"The first clock count is for the true condition (branch taken); the 
second clock count is for the false condition (branch ont taken)." The 
first clock is 7+m in every Jcc instructions other than J(E)CXZ, and the 
second is 3. So you may consider in writing:

if (! some condition) {
  Something you don't suppose to do;
} else {
  Something you really want to do;
}		/* Expression A */
However, according to the output of egcs 1.0.2, the result is not what we 
supposed. The express of

if (Some condition)
	Yes();
else
	No();		/* Expression B */
will be translated as

        cmpl $0,-4(%ebp)
        jne .L4
        call Yes
        jmp .L5
        .align 4
.L4:
        call No
.L5:

So that we know Expression B is more efficient, 'cause egcs has reversed
the instructions due to Jcc's (-128 to +127) limit. However the theory is 
not proven in i486 chips or newer. It seems the alignation is more 
important to newer chips.


.e'osai ko sarji la lojban.	==> Please support the logical language.
co'o mi'e lindjy,min.		==> Goodbye, I'm Lin Zhe Min.
Fingerprint20 = CE32 D237 02C0 FE31 FEA9  B858 DE8F AE2D D810 F2D9

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu

\
 
 \ /
  Last update: 2005-03-22 12:42    [from the cache]
©2003-2008