Messages in this thread | | | Date | Wed, 23 Feb 2000 20:42:18 +0100 | From | Jamie Lokier <> | Subject | Re: 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/
| |