Standard way to supply hints to branches

[Manu]

On Sat, 7 Sept 2024 at 21:16, Walter Bright via Digitalmars-d <
digitalmars-d at puremagic.com> wrote:

> On 9/6/2024 3:21 AM, Quirin Schroll wrote:
> > Early returns for unlikely-but-valid input like null pointers
> > makes sense to me.
>
> I often write code so that the happy path is the first if. Andrei objected
> to
> this style :-/
>
> > Other than that, there’s `if (...) throw ...;`, but basically
> > all optimizers recognize this as an unlikely path.
>
> Sure, but that's only one case. Manu's functions are all nothrow.
>
> > This is your style, and IMO it’s a bad style.
>
> Since CPU branch prediction for forward branches assumes they are not
> taken, it
> seems your style is statistically less likely. (As I assume the CPU
> designers
> did collect statistics on this.)
>

The statistical majority that you allude to is overwhelmingly dominated by
the branch UP and the end of every loop cycle.
Statistically speaking, almost all branches encountered during program flow
are up-branches at the end of loop cycles, which infers the rule that an up
branch should be predicted true, and therefore given a
sign-bit-branch-preiction strategy, down-branch must therefore predict
false. No other statistical realities past the loop continuation branch are
relevant.

I'd also suggest that, other than maybe the statistical probability of a
loop continuation being a good choice to predict in the true case, the
strategy of sign-bit based prediction is more a useful tool for a compiler
than an inherent architectural optimising feature. It gives the compiler
agency that it might not otherwise have, and in the cases where the
compiler can't infer meaningful predictions, we should be able to supply
them...
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20240910/211b3989/attachment.htm>