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...