likely/unlikely — will it ever be supported by FPC?

[flowCRANE]

C++ allows you to use the [[likely]] and [[unlikely]] attributes to tell the compiler which execution path is more or less likely. In this way, the optimizer can produce more efficient code. Will something like this ever be supported by FPC, at least for the if then else statements? Are there any plans related to this topic?

This could be done nicely, in a form that fits Pascal's syntax, for example:

Code: Pascal  [Select][+][-]

1. if likely A >= 0 then
2.   if likely A <= 20 then
3.     Write('A in [0 .. 20], as expected')
4.   else unlikely
5.     Write('A > 20, rarely happens');
6.  

A stupid example, but it illustrates the point. Or the same but in a different form (with parentheses):

Code: Pascal  [Select][+][-]

1. if likely (A >= 0) and (A <= 20) then
2.   Write('A in [0 .. 20], as expected')
3. else unlikely
4.   Write('A > 20, rarely happens');
5.  

likely and unlikely would be a keywords, put right after existing keywords if and else, as optional. In the case of case of statements, they could be used before each case (optional, if the developer want to).

[Thaddy]

 Well, when complete boolean evaluation is OFF {$B-} and given a capable programmer Pascal already will do that implicitly.
But it does not hurt to add attributes as reminder to the programmer that the most likely executed path should be the first part in the comparison.
Adding such as - basically empty - attributes [likely]/[unlikely] is already possible for classes enums and records.
I guess almost everybody already knows that the most often executed part of e.g. if/then/else should be the first part.... Or should know.

What you are suggesting is that based on such keywords can explicitly reverse the order of evaluation and I think that is not necessarily a good idea. But the attributes can readily be used. With some thought attributes can even be used to swap method pointers around...
But in general I don't see the point. Because the programmer obviously already knew the execution order when adding the keyword....
That follows from sheer logic...

If you are unsure, use a profiler...
Or use a macro  :

Code: Pascal  [Select][+][-]

1. {$macro on}{$define likely:=}{$define unlikely:=}{$mode objfpc}
2. var A :integer = 0;
3. begin
4. if likely (A >= 0) and (A <= 20) then
5.   Write('A in [0 .. 20], as expected')
6. else unlikely
7.   Write('A > 20, rarely happens');
8. end.

Or simply use a comment.

[440bx]

Since I am not a developer I cannot answer your question but, I strongly suspect the answer would be "no".

The reason is because, at least in my opinion, it is the programmer's responsibility to organize the code to best fit the problem including taking into account the most likely case.  IOW, IMO, it isn't the compiler's job to rearrange instructions based on statistical concerns which may have unintended/unforeseen consequences.

just my $0.02

[flowCRANE]

Well, when complete boolean evaluation is OFF {$B-} and given a capable programmer Pascal already will do that implicitly.

No, booleval is not used to control branch predictions (and avoid misspredictions). This is something completely different.

But it does not hurt to add attributes as reminder to the programmer that the most likely executed path should be the first part in the comparison.

This is not entirely true because it only applies to complex conditional statements with many else if's. Moreover, in many cases checks are organized differently to increase the readability of the code.

Adding such as - basically empty - attributes [likely]/[unlikely] is already possible for classes enums and records.

Do they have to do with code optimization?

What you are suggesting is that based on such keywords can explicitly reverse the order of evaluation and I think that is not necessarily a good idea.

No, they are intended to inform the compiler about the probability of the conditional statement being true or false, so that the optimizer can produce faster code. This is especially important when we first need to check some variables (e.g. whether the pointer is not nil), and then execute further code in which more similar checks may exist. You cannot change the order of conditions, but the compiler can optimize such code and gain run time, which is available in compilers for C++ and commonly used (e.g. in the Linux kernel, where likely is used over 3,000 times, and unlikely over a 14,000 times — source).

The reason is because, at least in my opinion, it is the programmer's responsibility to organize the code to best fit the problem including taking into account the most likely case.

I wrote above why this is only a partial solution.

IOW, IMO, it isn't the compiler's job to rearrange instructions based on statistical concerns which may have unintended/unforeseen consequences.

The compiler has to do what the developer tells it to do, because it is just a stupid tool. If I know that some conditional statement needs to be pre-executed and that the condition is 99.9% likely to be met, I want to be able to tell the optimizer that this will be the case. As a developer, I am supposed to have control over what code will be emitted, not the compiler over me.

If I predict branching incorrectly, it will be my fault, I can change it at any time. Currently, I can't do anything except watch the CPU waste time on mispredictions. In the case of performance-critical software (like the game engine I work on), branch misprediction can be expensive. It would be very good for me and the compiler if we could support the optimizer with additional information and get better machine code.

[marcov]

Afaik FPC already assumes likely for the IF and unlikely for the else. Maybe if optimization gets more advanced that will matter more, but for now I don't think this is really something critical

[flowCRANE]

Afaik FPC already assumes likely for the IF and unlikely for the else.

Can the compiler developers confirm this, please?

Edit: wait, you are a FPC developer. Are you not sure about this?

[marcov]

Afaik FPC already assumes likely for the IF and unlikely for the else.

Can the compiler developers confirm this, please?

Edit: wait, you are a FPC developer. Are you not sure about this?

The reasons should be obvious. FPC developer, but not a compiler developer :-)

[Thaddy]

No, booleval is not used to control branch predictions (and avoid misspredictions). This is something completely different.

No. It is Close to the same. See the C++11 specs.
And Marco is right, although I am not a compiler developer either (regarding FPC)

[flowCRANE]

No. It is Close to the same. See the C++11 specs.

C++11? likely and unlikely are available since C++20...

[Laksen]

Will something like this ever be supported by FPC, at least for the if then else statements? Are there any plans related to this topic?

Unlikely

[Thaddy]

No. It is Close to the same. See the C++11 specs.

C++11? likely and unlikely are available since C++20...

It was indeed 20 when it became an official part of the language, but was proposed much earlier and deemed controversial for a time. After reading the docs for 20 I noticed its behavior is more like a hint to the compiler than anything else.
So I still maintain they are not necessary. Point in case for further investigation, though, is if the optimizations available in FreePascal can achieve the intended behavior with the cache lines. I will have a look with an instrumenting profiler and examine the assembler code. What I already do know is that proper code ordering leads to faster code when full boolean evaluation is off. This is also a prerequisite for C±±

[mercurhyo]

my 2 cents here :

can't we stop please willing to add other languages compilers' features? it is probably one of the reasons why newbies leave pascal and turn toward these other languages.

this remark is a global one. It works for the majority of demands of pascal language modifications.

I am BEGGING you to ask for improvements that would make FreePascal UNIQUE instead of being eternal followers of CRAPS

THANK YOU

[flowCRANE]

After reading the docs for 20 I noticed its behavior is more like a hint to the compiler than anything else.

Exactly. It is a hint, the same as inline, so the compiler will decide what it can do to produce better and more efficient code. My proposal is nothing more that adding a hint for the code optimizer. This was not introduced in C++ as a joke — by properly marking conditional jumps, you can gain even more than 10% of CPU time, so it's worth having this option, it's worth having a tool to communicate with the code optimizer.

What I already do know is that proper code ordering leads to faster code when full boolean evaluation is off.

Indeed and I also always use lazy evaluation (which is enabled by default by the way).

can't we stop please willing to add other languages compilers' features?

No. Free Pascal and FPC must be developed and new features must be added to keep pace with the competition and be attractive to others, to be an interesting alternative to other technologies. That's why we have things like generics, recently added and still being developed anonymous functions and function references, etc.

Newbies? Who cares about newbies?

I am BEGGING you to ask for improvements that would make FreePascal UNIQUE instead of being eternal followers of CRAPS

A programming language is supposed to be useful and powerful, not unique. Stagnation in development will lead to being obsolete, not powerful.

[marcov]

After reading the docs for 20 I noticed its behavior is more like a hint to the compiler than anything else.

Exactly. It is a hint, the same as inline, so the compiler will decide what it can do to produce better and more efficient code. My proposal is nothing more that adding a hint for the code optimizer.

And that is vastly premature without actually having that part of the code optimizer. The language bits are the final, not the first steps in such journey.

And _if_ there are extensions to be made(*), how that will be shaped is at the discretion of somebody that will actually implement it.

(*) the if then rule seems sufficient for me, as it was for plain C for decades. So what is the C++ rationale for this, rather than negating the IF?

[flowCRANE]

And that is vastly premature without actually having that part of the code optimizer.

What exactly is vastly premature? I do not understand what you mean.