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/
This archive was generated by hypermail 2b29 : Wed Feb 23 2000 - 21:00:34 EST