On 9/10/2024 1:48 PM, Manu wrote:
> On Sat, 7 Sept 2024 at 21:16, Walter Bright via Digitalmars-d
> 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 think that is what I wrote.
> 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...
I did write that forward branches were considered not likely, and backward
branches likely. We are in agreement on that.
Okay, I lost the signal somewhere... what I'm essentially saying though, is that it doesn't matter what the rule is or how it came about; the point is, it's a tool the architecture offers which is most useful at the language level. Laying out code to match this particular rule is not something that's appropriate, because some other arch with whatever other primitive strategy might come along.
Obfuscating the contorting code is not the goal or a reasonable solution; we just want a mechanism in the language to take advantage of this general category of support in whatever architecture.