lkml.org 
[lkml]   [2000]   [Feb]   [23]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: Kernel bugs found using inspect tool
nathan.zook@amd.com wrote:
> The speed trade-off is directly related to the predictability of the
> branch(es). A branch which goes rlrlrlrlrlrlrlr will, under most schemes in
> use, be mispredicted either 50 or 100% of the time. rrllrrllrrllrrllrrll is
> another really bad sequence.

I think the PII can match both of those correctly.

> A REALLY good optimizer might take the lazy-branch version of the code,
> recognize that the later tests are side effect-free, and chose the version
> is thinks is better. Problem is, such a compiler would likely be helpless
> attempting to recognize an alternating branch point such as above.

A really good optimiser might expand the control flow graph to
accomodate poor branch prediction.... but not in this example.

> I'm right when I say "The rules have changed. Consider bit-logicals. Time
> your critical inner loops". It all depends on the exact details of the code
> & the processor. When c, d, e, and f are simple variables and the first two
> branches are hard to predict, bit-ors should be faster on all the latest
> superscalar systems.

Actually bit-ors were faster for some simpler operations on old
processors too.

Consider:

mov var1,%reg
or var2,%reg
jne label

vs.

mov var1,%reg
jne label
mov var2,%reg
jne label

or even

mov var1,%reg
or %reg,%reg
jne label
mov var2,%reg
or %reg,%reg
jne label

enjoy,
-- jamie

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 13:56    [W:0.409 / U:0.024 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site