On Tuesday, 10 September 2024 at 08:29:49 UTC, Andrea Fontana wrote:
> unlikely_if(...) ...;
> else ...;

Cool. That's the first proposal that I can read without getting eye-cancer.

On Tuesday, 10 September 2024 at 08:54:13 UTC, Dom DiSc wrote:
> On Tuesday, 10 September 2024 at 08:29:49 UTC, Andrea Fontana wrote:
>> unlikely_if(...) ...;
>> else ...;
>
> Cool. That's the first proposal that I can read without getting eye-cancer.

I had similar thoughts.

unlikely(...) ...;
else ...;

On Sat, 31 Aug 2024 at 17:16, Dom DiSc via Digitalmars-d < digitalmars-d@puremagic.com> wrote:

> On Friday, 30 August 2024 at 02:54:28 UTC, Manu wrote:
> > On Fri, 30 Aug 2024 at 04:32, Walter Bright via Digitalmars-d < digitalmars-d@puremagic.com> wrote:
> >
> >> On 8/28/2024 2:45 AM, Manu wrote:
> >> > Here's one that I just wrote a short while ago: https://gist.github.com/TurkeyMan/0e49da245cc0086f852ac18deed21a9c
> >>
> >>
> >> ```
> >> if (data.length < 4) // unlikely
> >>      return 0;
> >> ```
> >>
> >> replace with:
> >>
> >> ```
> >> if (data.length < 4)
> >>      goto Lreturn0;
> >> ```
> >>
> >
> > How is that any different? The branch prediction hasn't changed.
>
> I already asked this question.
> He said a single break or goto is NOT considered the hot branch
> by the compiler.
>

The goto is not a branch at all. The if() is the branch... and it still
predicts the pessimistic case incorrectly.
Replacing the return with a goto hasn't changed the control flow in any
way; goto and return are equivalent; they are not branches.


> But I don't like this, because it's an implementation detail that
> every compiler may implement or not, and it's not documented
> anywhere.
> Maybe if the documentation would clearly state at a prominent
> point that a single break or goto has to be considered the cold
> path by the compiler, but a function call is to be considered the
> hot path (and all related queries about branch priorization link
> there), then I would consider this a solution. But is it likely
> this will happen?
>

On Sat, 7 Sept 2024 at 21:16, Walter Bright via Digitalmars-d < digitalmars-d@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...

Compile the following with -vasm -O:

```
void bar();

int foo(int i)
{
    if (i)
        return 0;
    bar();
    return 1;
}

int baz(int i)
{
    if (i)
        goto Lreturn0;
    bar();
    return 1;

Lreturn0:
    return 0;
}
```
and you get:
```
_D5test93fooFiZi:
0000:   55                       push      RBP
0001:   48 8B EC                 mov       RBP,RSP
0004:   85 FF                    test      EDI,EDI
0006:   74 04                    je        Lc
0008:   31 C0                    xor       EAX,EAX // hot path
000a:   5D                       pop       RBP
000b:   C3                       ret
000c:   E8 00 00 00 00           call      L0   // cold path
0011:   B8 01 00 00 00           mov       EAX,1
0016:   5D                       pop       RBP
0017:   C3                       ret
_D5test93bazFiZi:
0000:   55                       push      RBP
0001:   48 8B EC                 mov       RBP,RSP
0004:   85 FF                    test      EDI,EDI
0006:   75 0C                    jne       L14
0008:   E8 00 00 00 00           call      L0   // hot path
000d:   B8 01 00 00 00           mov       EAX,1
0012:   5D                       pop       RBP
0013:   C3                       ret
0014:   31 C0                    xor       EAX,EAX // cold path
0016:   5D                       pop       RBP
0017:   C3                       ret
```

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.

On 9/9/2024 7:18 PM, Tejas wrote:
> Hi, what are your views on the article linked below that discourages using `[[likely]]` and `[[unlikely]]`?
> 
> https://blog.aaronballman.com/2020/08/dont-use-the-likely-or-unlikely-attributes/

Wow. The article eviscerates that design.

On Tuesday, 10 September 2024 at 11:24:35 UTC, Daniel N wrote:
> On Tuesday, 10 September 2024 at 08:54:13 UTC, Dom DiSc wrote:
>> On Tuesday, 10 September 2024 at 08:29:49 UTC, Andrea Fontana wrote:
>>> unlikely_if(...) ...;
>>> else ...;
>>
>> Cool. That's the first proposal that I can read without getting eye-cancer.
>
> I had similar thoughts.
>
> unlikely(...) ...;
> else ...;

Just tongue-in-cheek along these lines ;-)

iffy(...) ...;
else ...;


At least it is shorter!

On Wednesday, 11 September 2024 at 08:53:30 UTC, ShadoLight wrote:
> Just tongue-in-cheek along these lines ;-)
>
> iffy(...) ...;
> else ...;
>
>
> At least it is shorter!

In german it would be easy: "wenn" is the likely path, "falls" is the unlikely path.

On Wed, 11 Sept 2024 at 06:56, Walter Bright via Digitalmars-d < digitalmars-d@puremagic.com> wrote:

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