August 24

On Saturday, 24 August 2024 at 03:37:32 UTC, Walter Bright wrote:

>

It's not pedantically correct. More precisely, any code following the if is presumed to be the hot path. A branch instruction doesn't count, i.e. it's the branch-not-taken that is considered the hot path.

I think everyone in this thread can agree that we need a compiler-agnostic solution for changing the presumed hot-path, and one that doesn’t require rewriting existing code more than just adding on one word. For example, if((x == y).expect(false)){} makes it a pain to rewrite existing ifs, where @unlikely if(x == y) {} is easy.

August 24

On Saturday, 24 August 2024 at 08:06:21 UTC, IchorDev wrote:

>

On Saturday, 24 August 2024 at 03:37:32 UTC, Walter Bright wrote:

>

It's not pedantically correct. More precisely, any code following the if is presumed to be the hot path. A branch instruction doesn't count, i.e. it's the branch-not-taken that is considered the hot path.

I think everyone in this thread can agree that we need a compiler-agnostic solution for changing the presumed hot-path, and one that doesn’t require rewriting existing code more than just adding on one word. For example, if((x == y).expect(false)){} makes it a pain to rewrite existing ifs, where @unlikely if(x == y) {} is easy.

You also have the pragma option. I think that would be more adequate as not every vendor has to support it. In other words "dmd can just ignore it". Bonus: pragma can be attached to statements, that's not the case of attributes.

August 24

On Saturday, 24 August 2024 at 09:11:34 UTC, user1234 wrote:

>

On Saturday, 24 August 2024 at 08:06:21 UTC, IchorDev wrote:

>

I think everyone in this thread can agree that we need a compiler-agnostic solution for changing the presumed hot-path, and one that doesn’t require rewriting existing code more than just adding on one word. For example, if((x == y).expect(false)){} makes it a pain to rewrite existing ifs, where @unlikely if(x == y) {} is easy.

You also have the pragma option. I think that would be more adequate as not every vendor has to support it. In other words "dmd can just ignore it". Bonus: pragma can be attached to statements, that's not the case of attributes.

Like pragma(likely, false)? It’s a bit long, maybe pragma(unlikely)? It’s something I’d want to use fairly often, after all. Or we could just add some new grammar for adding special modifiers to if statements. Something like…

if: unlikely(x){
  //…
}
if(!x){
  //…
}else: likely{
  //…
}
August 25
On Sat, 24 Aug 2024 at 12:06, Nicholas Wilson via Digitalmars-d < digitalmars-d@puremagic.com> wrote:

> On Friday, 23 August 2024 at 01:47:37 UTC, Manu wrote:
> > I'm working on microcontrollers, and many don't have a branch predictor. They do "static" prediction, that is, they just predict branch-not-taken and it's on you to write your code as such, and that's not always possible. (like the loop condition in a for loop)
>
> Stupid questions: does PGO work on the microcontrollers, and have you tried PGO?
>

Maybe... I'd have to source the profile from an alt architecture though...
I wonder if the profile is at a higher level (like in the LLVM realm), or
if it ends up profiling target-local constructs.
I'm not likely to use it anyway. I've always found tooling like that to add
unsatisfactory complexity to the build and deploy environment, especially
when the build environment is already a bit fiddley with ROM packaging and
stuff.


August 25
On Sat, 24 Aug 2024 at 21:46, IchorDev via Digitalmars-d < digitalmars-d@puremagic.com> wrote:

> On Saturday, 24 August 2024 at 09:11:34 UTC, user1234 wrote:
> > On Saturday, 24 August 2024 at 08:06:21 UTC, IchorDev wrote:
> >> I think everyone in this thread can agree that we need a
> >> compiler-agnostic solution for changing the presumed hot-path,
> >> and one that doesn’t require rewriting existing code more than
> >> just adding on one word. For example, `if((x ==
> >> y).expect(false)){}` makes it a pain to rewrite existing
> >> `if`s, where `@unlikely if(x == y) {}` is easy.
> >
> > You also have the `pragma` option. I think that would be more adequate as not every vendor has to support it. In other words "dmd can just ignore it". Bonus: pragma can be attached to statements, that's not the case of attributes.
>
> Like `pragma(likely, false)`? It’s a bit long, maybe
> `pragma(unlikely)`? It’s something I’d want to use fairly often,
> after all. Or we could just add some new grammar for adding
> special modifiers to if statements. Something like…
> ```d
> if: unlikely(x){
>    //…
> }
> if(!x){
>    //…
> }else: likely{
>    //…
> }
> ```
>

C++ is way ahead on this... they added attributes to the language years
back, and they defined [[likely]] and [[unlikely]] post-fix on control
statements. It's really convenient, it reads well, and it's easy to
retrofit without disturbing the code.
That's the de-facto now, and we should follow it.


August 26
On 8/24/2024 9:47 AM, Manu wrote:
> C++ is way ahead on this... they added attributes to the language years back, and they defined [[likely]] and [[unlikely]] post-fix on control statements. It's really convenient, it reads well, and it's easy to retrofit without disturbing the code.
> That's the de-facto now, and we should follow it.

It's unattractive.

I provided two alternate means to accomplish the same thing elsewhere in this thread.

https://www.digitalmars.com/d/archives/digitalmars/D/Standard_way_to_supply_hints_to_branches_375697.html#N375717
August 26

On Monday, 26 August 2024 at 07:12:47 UTC, Walter Bright wrote:

>

I recently learned a syntactical trick on how to do this.

do
{
   if (x) break;
   if (y) break;
   if (z) break;
   hotPath();
} while (0);

Why does this work? The else path is still the cold path, isn't it?

August 27
On Mon, 26 Aug 2024 at 17:16, Walter Bright via Digitalmars-d < digitalmars-d@puremagic.com> wrote:

> On 8/24/2024 9:47 AM, Manu wrote:
> > C++ is way ahead on this... they added attributes to the language years
> back,
> > and they defined [[likely]] and [[unlikely]] post-fix on control
> statements.
> > It's really convenient, it reads well, and it's easy to retrofit without
> > disturbing the code.
> > That's the de-facto now, and we should follow it.
>
> It's unattractive.
>
> I provided two alternate means to accomplish the same thing elsewhere in
> this
> thread.
>
>
> https://www.digitalmars.com/d/archives/digitalmars/D/Standard_way_to_supply_hints_to_branches_375697.html#N375717
>

"Unattractive"? ... seriously?
Your suggestions were to quite seriously molest the code, reordering,
adding extra scopes, inverting logic, nonsense statements like `do {}
while(0)`, using labels and goto's which doesn't marry well with general
control flow and RAII type things... sorry; but "unattractive"? That might
be the most bizarre thing I've ever heard you say! ;)


August 27
On Tue, 27 Aug 2024 at 15:27, Manu <turkeyman@gmail.com> wrote:

> On Mon, 26 Aug 2024 at 17:16, Walter Bright via Digitalmars-d < digitalmars-d@puremagic.com> wrote:
>
>> On 8/24/2024 9:47 AM, Manu wrote:
>> > C++ is way ahead on this... they added attributes to the language years
>> back,
>> > and they defined [[likely]] and [[unlikely]] post-fix on control
>> statements.
>> > It's really convenient, it reads well, and it's easy to retrofit
>> without
>> > disturbing the code.
>> > That's the de-facto now, and we should follow it.
>>
>> It's unattractive.
>>
>> I provided two alternate means to accomplish the same thing elsewhere in
>> this
>> thread.
>>
>>
>> https://www.digitalmars.com/d/archives/digitalmars/D/Standard_way_to_supply_hints_to_branches_375697.html#N375717
>>
>
> "Unattractive"? ... seriously?
> Your suggestions were to quite seriously molest the code, reordering,
> adding extra scopes, inverting logic, nonsense statements like `do {}
> while(0)`, using labels and goto's which doesn't marry well with general
> control flow and RAII type things... sorry; but "unattractive"? That might
> be the most bizarre thing I've ever heard you say! ;)
>

Just so it's clear what's going on here; certain microcontrollers don't
have branch predictors at all; so hinting is essential on these exotic
platforms. Your suggestions could appear in almost every single
at-least-warm function, and it's not clear how they marry with eachother.
We discussed 2 principle cases; likely early return because of short-path
or cached value, and unlikely early return due to argument validation
failure. Plenty of functions contain both cases, and plenty of functions
contain numerous such items.
Try and imagine how your suggestion scales when there are 4-5 conditions
that need to be tested on function entry, and they don't all receive the
same hint. I value readable and maintainable code...


August 27
On 8/26/2024 2:08 AM, Dom DiSc wrote:
> Why does this work? The else path is still the cold path, isn't it?

It works because the "break" is not considered the hot path.