Forum > Suggestions

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

(1/6) > >>

furious programming:
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  [+][-]window.onload = function(){var x1 = document.getElementById("main_content_section"); if (x1) { var x = document.getElementsByClassName("geshi");for (var i = 0; i < x.length; i++) { x[i].style.maxHeight='none'; x[i].style.height = Math.min(x[i].clientHeight+15,306)+'px'; x[i].style.resize = "vertical";}};} ---if likely A >= 0 then  if likely A <= 20 then    Write('A in [0 .. 20], as expected')  else unlikely    Write('A > 20, rarely happens'); 
A stupid example, but it illustrates the point. Or the same but in a different form (with parentheses):


--- Code: Pascal  [+][-]window.onload = function(){var x1 = document.getElementById("main_content_section"); if (x1) { var x = document.getElementsByClassName("geshi");for (var i = 0; i < x.length; i++) { x[i].style.maxHeight='none'; x[i].style.height = Math.min(x[i].clientHeight+15,306)+'px'; x[i].style.resize = "vertical";}};} ---if likely (A >= 0) and (A <= 20) then  Write('A in [0 .. 20], as expected')else unlikely  Write('A > 20, rarely happens'); 
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  :D O:-) :
--- Code: Pascal  [+][-]window.onload = function(){var x1 = document.getElementById("main_content_section"); if (x1) { var x = document.getElementsByClassName("geshi");for (var i = 0; i < x.length; i++) { x[i].style.maxHeight='none'; x[i].style.height = Math.min(x[i].clientHeight+15,306)+'px'; x[i].style.resize = "vertical";}};} ---{$macro on}{$define likely:=}{$define unlikely:=}{$mode objfpc}var A :integer = 0;beginif likely (A >= 0) and (A <= 20) then  Write('A in [0 .. 20], as expected')else unlikely  Write('A > 20, rarely happens');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

furious programming:

--- Quote from: Thaddy on December 08, 2023, 03:57:02 pm ---Well, when complete boolean evaluation is OFF {$B-} and given a capable programmer Pascal already will do that implicitly.

--- End quote ---

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


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

--- End quote ---

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.


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

--- End quote ---

Do they have to do with code optimization?


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

--- End quote ---

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



--- Quote from: 440bx on December 08, 2023, 03:57:50 pm ---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.

--- End quote ---

I wrote above why this is only a partial solution.


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

--- End quote ---

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

Navigation

[0] Message Index

[#] Next page

Go to full version