Re: disabling branch probability guessing (patch)

[Aldy Hernandez <aldyh at redhat dot com>]

On Tue, Jan 16, 2001 at 12:21:37AM -0800, Mark Mitchell wrote:
> >>>>> "Jeffrey" == Jeffrey A Law <law@redhat.com> writes:
> 
>     >> but Jim had some arguments (on our internal list) for being
>     >> able to disable this pass.
> 
> Would one of you mind posting a summary of the thinking on the
> external list?  We should get Jim's thoughts into the public
> consciousness, and allow everyone else to comment.

Ok, I'll try do do the best I can.  Jim, feel free to fill in my gaps... :)

Our customer wants to have the code run in a more deterministic way,
I assume this is for a real-time system in which we need to know the
worst case scenario.  They always want to know how fast the code is
going to run, and having gcc second guess them by guessing branch
predictions is not desireable.

And here is Jim's relevant quote...

===
In hard real time systems, it doesn't matter how fast the code runs in the
best case.  What matters is how fast the code runs in the worst case.  If
we get data every 10 milliseconds, and can process it in 2 milliseconds
best case then the processor just sits idle for 8 milliseconds.  But if we
take 11 milliseconds to process it, then we miss the next data item and
bad things happen.  So we need to know exactly how many cycles an
instruction sequence will take worst case.  Caches don't help if the data
might not be in the cache in the worst case.  Branch predictions bits
confuse timing if you get different prediction bits set with different
compilers or different compiler options.  Since only the worst case matters,
setting the predict bit to always false doesn't hurt.

[aldy-- in our particular case, the customer wants to have all non-specified
branch probabilities set to false]

Another thing to consider here is timing problems.  It is easier to get
timing right if a code sequence always takes the same amount of time,
i.e. it is deterministic.  Caches can be a bad thing here.  If the code
sometimes runs fast because of a cache hit and sometimes runs slow because
of a cache miss, then it may be hard to make the system work all of the time.
But if you disable the cache (or don't have one in the first place), then
the code always takes the same amount of time to run, and timing problems are
easier to fix.
===

Profile directed feedback also puts in branch probabilities, but we don't
care about those because the user has to specify them directly.

Let me know if this makes things clearer.
Aldy