www.digitalmars.com         C & C++   DMDScript  

digitalmars.dip.ideas - Likelihood of if statement and case

reply Richard (Rikki) Andrew Cattermole <richard cattermole.co.nz> writes:
Given the recent 
[thread](https://forum.dlang.org/post/mailman.2451.1724377685.3719.digitalm
rs-d puremagic.com) by Manu, requesting a way to annotate likelihood for
branches, I think I have found a way forward that is both in recognization of
existing practices both in D and outside.

In this thread, Tejas provided a 
[link](https://blog.aaronballman.com/2020/08/dont-use-the-likely-or-u
likely-attributes/) that shows issues with the C/C++ design.

1. The true path of a branch is assumed to be unlikely.
2. The false path, or the fallthrough path if false path does not 
exist is assumed to be taken.
3. D's if statement, is if-else, not if-elseif-else based, 
therefore it inherently has a priority and scope awareness and 
does not need a priority to be defined by the user.
4. Switch statements have a priority for their cases by simply 
their order. The likely path is the default statement.

The unlikelihood is now defined against D using existing 
practices. No changes there.

What we want to define is a way to do a kind of swap, so to tell 
the compiler that no, the order in the code is the wrong way 
around.

```d
switch(e) {
     /* likely*/
     case E.unlikely1:
         break;
     default:
         break;
}

if (e.unlikely1) /* likely*/ {
} else {
}
```

`` likely`` would be defined in core.attributes. It requires 
minimal changes, but instead it requires us to explicitly define 
this behavior of priorities and likelihood.
Sep 11
next sibling parent Walter Bright <newshound2 digitalmars.com> writes:
On 9/11/2024 2:26 AM, Richard (Rikki) Andrew Cattermole wrote:

 4. Switch statements have a priority for their cases by simply their order.
The 
 likely path is the default statement.


The code is laid out in the order it appears in the source code, including the 
default.
Sep 11
prev sibling next sibling parent reply Sergey <kornburn yandex.ru> writes:
On Wednesday, 11 September 2024 at 09:26:16 UTC, Richard (Rikki) 
Andrew Cattermole wrote:

 Given the recent 
 [thread](https://forum.dlang.org/post/mailman.2451.1724377685.3719.digitalm
rs-d puremagic.com) by Manu, requesting a way to annotate likelihood for
branches, I think I have found a way forward that is both in recognization of
existing practices both in D and outside.


Just recent proposal for zig, that could be used as another 
example of design:

https://github.com/ziglang/zig/issues/21148
Sep 13
parent reply "Richard (Rikki) Andrew Cattermole" <richard cattermole.co.nz> writes:
On 14/09/2024 7:49 AM, Sergey wrote:

 On Wednesday, 11 September 2024 at 09:26:16 UTC, Richard (Rikki) Andrew 
 Cattermole wrote:

 Given the recent 
 [thread](https://forum.dlang.org/post/mailman.2451.1724377685.3719.digitalm
rs-d puremagic.com) by Manu, requesting a way to annotate likelihood for
branches, I think I have found a way forward that is both in recognization of
existing practices both in D and outside.


 
 Just recent proposal for zig, that could be used as another example of 
 design:
 
 https://github.com/ziglang/zig/issues/21148


So an attribute statement.

Nice idea, except we've got an example to show that this isn't such a 
great thing.

``pragma(inline)``, it can be used both as statement and as an attribute 
on a function.

Problem is the compiler may not see it when its a statement, depending 
upon how its been called during multi-step compilation.

It would be nice to convert it to a UDA, to clear this set of issues up.

And this tracks with the C/C++ attribute for likelihood and Tejas's article.

Good prior work content!
Sep 13
parent reply Quirin Schroll <qs.il.paperinik gmail.com> writes:
On Friday, 13 September 2024 at 19:54:49 UTC, Richard (Rikki) 
Andrew Cattermole wrote:

 On 14/09/2024 7:49 AM, Sergey wrote:

 On Wednesday, 11 September 2024 at 09:26:16 UTC, Richard 
 (Rikki) Andrew Cattermole wrote:

 Given the recent 
 [thread](https://forum.dlang.org/post/mailman.2451.1724377685.3719.digitalm
rs-d puremagic.com) by Manu, requesting a way to annotate likelihood for
branches, I think I have found a way forward that is both in recognization of
existing practices both in D and outside.


 
 Just recent proposal for zig, that could be used as another 
 example of design:
 
 https://github.com/ziglang/zig/issues/21148


 So an attribute statement.

 Nice idea, except we've got an example to show that this isn't 
 such a great thing.

 ``pragma(inline)``, it can be used both as statement and as an 
 attribute on a function.

 Problem is the compiler may not see it when its a statement, 
 depending upon how its been called during multi-step 
 compilation.

 It would be nice to convert it to a UDA, to clear this set of 
 issues up.

 And this tracks with the C/C++ attribute for likelihood and 
 Tejas's article.

 Good prior work content!


I can only repeat myself: An attribute is the wrong choice. Use a 
pragma. That’s what it’s for. Statement-level attributes require 
a grammar change. If you allow ` whatever` here specifically, one 
would assume any UDAs work there, too. But why would they? What 
would they mean? It’s really inconsistent.
Sep 18
parent "Richard (Rikki) Andrew Cattermole" <richard cattermole.co.nz> writes:
On 19/09/2024 2:46 AM, Quirin Schroll wrote:

 I can only repeat myself: An attribute is the wrong choice. Use a 
 pragma. That’s what it’s for. Statement-level attributes require a 
 grammar change. If you allow | whatever| here specifically, one would 
 assume any UDAs work there, too. But why would they? What would they 
 mean? It’s really inconsistent.


They mean the same thing as they do anywhere else.

The fact that you don't have the ability to introspect them is irrelevant.

You can do the same thing for any symbol, or function parameter and you 
are free to never introspect them.

The only thing inconsistent is that there is no way to introspect it, 
but perhaps tooling could i.e. a documentation generator.
Sep 18
prev sibling parent reply IchorDev <zxinsworld gmail.com> writes:
On Wednesday, 11 September 2024 at 09:26:16 UTC, Richard (Rikki) 
Andrew Cattermole wrote:

 ```d
 switch(e) {
     /* likely*/
     case E.unlikely1:
         break;
     default:
         break;
 }

 if (e.unlikely1) /* likely*/ {
 } else {
 }
 ```

 `` likely`` would be defined in core.attributes. It requires 
 minimal changes, but instead it requires us to explicitly 
 define this behavior of priorities and likelihood.


How would one emulate this?
```d
void x(int a, uint b){
   if(a < 0)  unlikely return;
   if(b == uint.max)  unlikely return;
   //do stuff
}
```
Not being able to mark an if-return as unlikely is one of the 
major problems with the current design, because the if-return 
pattern avoids issues with really deep nesting that would occur 
otherwise.
Sep 22
parent "Richard (Rikki) Andrew Cattermole" <richard cattermole.co.nz> writes:
On 22/09/2024 9:49 PM, IchorDev wrote:

 On Wednesday, 11 September 2024 at 09:26:16 UTC, Richard (Rikki) Andrew 
 Cattermole wrote:

 ```d
 switch(e) {
     /* likely*/
     case E.unlikely1:
         break;
     default:
         break;
 }

 if (e.unlikely1) /* likely*/ {
 } else {
 }
 ```

 `` likely`` would be defined in core.attributes. It requires minimal 
 changes, but instead it requires us to explicitly define this behavior 
 of priorities and likelihood.


 
 How would one emulate this?
 ```d
 void x(int a, uint b){
    if(a < 0)  unlikely return;
    if(b == uint.max)  unlikely return;
    //do stuff
 }
 ```
 Not being able to mark an if-return as unlikely is one of the major 
 problems with the current design, because the if-return pattern avoids 
 issues with really deep nesting that would occur otherwise.


Why would you need to annotate it?

It is the default for the true path.

The `` likely`` annotation is _swapping_ the likelihoods of the two paths.

Note: compilers are free to add other attributes once UDA's are turned on.
Sep 22