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

[Martin_fr]

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?

I don't know the C++ rationale, but I could imagine some cases.

E.g.

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

1. {$PUSH}{$OPT LIKELY_ELSE}
2. If not InitDone then begin
3.   DoInit();
4. end;
5. {$POP}

to lots of people may read easier than

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

1. If InitDone then begin
2. end
3. else begin
4.   DoInit();
5. end;

or

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

1. If InitDone then begin
2.   // do work
3. end
4. else begin
5.   DoInit();
6.   // COPY OF do work
7. end;

(potentially having to make "do work" a new (inlined) procedure to avoid code duplication)

Or whatever else way to write it, so that "DoInit" is in the "else" block?

Anyway, if I had my 3 free wishes, and they were 3 free wishes about the fpc optimizer, they would "likely" not include this one.

Of course that opens the door to so much more

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

1. {$PUSH}{$OPT LIKELY_FALSE}
2. MyBool := not InitDone;
3. {$POP}
4. // some code
5. If MyBool then // remembers, this is likely false
6.   DoInit();

No, not serious....

[440bx]

Newbies? Who cares about newbies?

Compiler developers should care about newbies and the compiler users should too.

Here is one of the many reasons why: Compilers, C in particular, have a well deserved reputation of outputting cryptic error messages.  Those error messages can make a newbie give up on using the language, particularly if the language is not popular, e.g, Pascal. 

Even seasoned users and compiler developers occasionally look at an error message, the context in which it occurred and wonder what the F is the compiler talking about !?

Generally speaking, FPC often emits reasonably decent error messages but, there is definitely room for improvement there, "illegal operation" or "semicolon expected" (when it is obvious a semicolon would make no difference whatsoever) are not particularly helpful and, can be rather frustrating to a newbie - which doesn't help promoting FPC nor Pascal.

Lastly, lousy error messages - such as "illegal operation" - do not help programmer productivity.

I'm not sure if the following is true but, I read someplace that the main motivation behind creating LLVM was to create a C compiler that emitted, at least, somewhat useful error messages.

[flowCRANE]

In the current project (game engine) I have dozens, if not hundreds of functions that need to check whether the pointer is different from nil (or other checks of the parameter values) and in the vast majority of these functions, such conditions are met 99.9% of the time. However, such a condition must exist, because there are situations in which the pointer may be nil (which is legal). If there is no condition, it will crash. So it would be good if it was possible to indicate to the optimizer that such a condition will almost always be met/unfulfilled (like in C++).

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

1. {$PUSH}{$OPT LIKELY_FALSE}
2. MyBool := not InitDone;
3. {$POP}
4. // some code
5. If MyBool then // remembers, this is likely false
6.   DoInit();

Interesting approach with these directives. This could be used for what I suggested:

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

1. {$PUSH}{$OPT LIKELY}
2. if MyPointer <> nil then
3. {$POP}
4.   // condition met, do something.
5.  

You could wrap these directives in macros and obtain any syntax of such hints, without changing the language syntax itself:

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

1. {$MACRO ON}
2.  
3. {$DEFINE likely    := {$PUSH} {$OPT LIKELY}}
4. {$DEFINE likelyend := {$POP}}
5.  
6. var
7.   MyPointer: Pointer = nil;
8. begin
9.   if likely MyPointer <> nil likelyend then
10.     // condition met, do something.
11.  

or whatever else. I like it, it is a non-invasive solution.

[runewalsh]

“Likely” and “unlikely” can be very powerful. For example, code

Code: [Select]

if X = 0 then
    FixupZero;
DoWork;

will probably be compiled by default into

Code: [Select]

compare x with 0
if not equals: goto continuation
call FixupZero
continuation: call DoWork
...

which is a good idea if the condition is likely to happen. But if the condition is unlikely, the code can be reorganized into

Code: [Select]

compare x with 0
if equals: goto rare_branch
continuation: call DoWork
...
rare_branch:
call FixupZero
goto continuation

eliminating a jump from the hot path (and this is what GCC likes to do); if the branch is never taken, it might not even require a BTB slot. An example where “unlikely” can be heuristically assumed by default.

[flowCRANE]

Thanks for the reply, @runewalsh. Very good point.

[PascalDragon]

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?

There are currently no plans for this.

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.

marcov means that it makes no sense to think about a syntax to control is when there is nothing to control. The compiler currently has no way influence the optimization for that in any way,  because it's simply not implemented. So it makes no sense to polute the language with some mechanism that's not going to be implemented for the foreseeable future with users then asking why it isn't working.

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.

Which is why we compiler developers don't add every feature and the kitchen sink. We are very conservative with adding new feature no matter how much users beg/nag for them especially if they are simply copy-cats from some other compiler (an exception would be Delphi, but that has a reason obviously).

[VisualLab]

Newbies? Who cares about newbies?

Compiler developers should care about newbies and the compiler users should too.

Here is one of the many reasons why: Compilers, C in particular, have a well deserved reputation of outputting cryptic error messages.  Those error messages can make a newbie give up on using the language, particularly if the language is not popular, e.g, Pascal. 

Even seasoned users and compiler developers occasionally look at an error message, the context in which it occurred and wonder what the F is the compiler talking about !?

Generally speaking, FPC often emits reasonably decent error messages but, there is definitely room for improvement there, "illegal operation" or "semicolon expected" (when it is obvious a semicolon would make no difference whatsoever) are not particularly helpful and, can be rather frustrating to a newbie - which doesn't help promoting FPC nor Pascal.

Lastly, lousy error messages - such as "illegal operation" - do not help programmer productivity.

I'm not sure if the following is true but, I read someplace that the main motivation behind creating LLVM was to create a C compiler that emitted, at least, somewhat useful error messages.

I totally agree. After some time (after gaining experience), the novice will become a full-fledged programmer who can contribute to the popularity and development of the language (e.g. by creating various libraries, examples, etc.). People who develop Python or JavaScript can ignore novices, because there are hundreds of thousands (if not millions) of users of these languages.

Is the request [[likely]]/[[unlikely]] made by furious programming useful? Hard to say. If something like this were ever to appear, the proposal given by Martin_fr seems to make the most sense, i.e. in the form of a compiler directive.

[marcov]

I don't know the C++ rationale, but I could imagine some cases.

E.g.

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

1. {$PUSH}{$OPT LIKELY_ELSE}
2. If not InitDone then begin
3.   DoInit();
4. end;
5. {$POP}

to lots of people may read easier than

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

1. If InitDone then begin
2. end
3. else begin
4.   DoInit();
5. end;

This bit is about last cycle optimization of extremely tight loops, and not about general purpose code. As such it will be rare, and mostly function over appearance.  Actually that thought was why I initially considered out of language solutions.

Anyway, if I had my 3 free wishes, and they were 3 free wishes about the fpc optimizer, they would "likely" not include this one.

Or the next 50 wishes for that matter.

[BeniBela]

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

On the contrary

The other languages add features from Pascal.

Then Pascal  is not unique anymore, because the other languages have all the Pascal features.

Then the newbies leave




To stop them from leaving, we need more features

[Warfley]

I find this likely and unlikely an interesting idea, because optimizing branches usually results in very unreadable code. For example, as was discussed here, if this is implicit by the ordering, this means that if you have the following code:

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

1. if A then
2.   ...
3. else if B then
4.   ...
5. else if C then
6.   ...

And it turns out that the last branch is the most likely one, this would needed to be rewritten to:

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

1. if not A and not B and C then
2.   ...
3. else if A then
4.   ...
5. else if B then
6.   ...
7.  

Which just made the code much more complicated to understand. In fact, reordering of an if-then-else chain can quadratically increase the complexity of each branching condition.

But on the other hand, more verbose is not necessarily better readable either, and adding something like "likely" to a branch, makes it at least slightly less readable.

So the question that I am asking myself is not what way of optimizing this is better, reordering or a keyword, because there with the exponential complexity increase a keyword would win hands down, but rather if this is needed in the first place.

C++ is designed to be as optimizable as possible, all features are designed to be "near-zero-cost" abstractions, as they call it, so having such keywords to enable the optimizer to better consider more likely paths makes sense in that context.
BUT: Pascal is not built in the same way. Pascals feature set is not built around optimizability. When you want to write really optimized Pascal code, you already must exclude a lot of language features which are quite essential to what is considered "good" Pascal code, such as Classes instead of Objects, managed types like Arrays and Strings, Try-Finally blocks, etc.

So I think when considering new features to be implemented, the goal should not be to allow for micro optimizations, because this is not the core value that Pascal brings to the table. This effort if anything should be focused on adding features that ease development and make it easier to write simple code that performs complex tasks.

And always to keep in mind, the most used languages are languages like Python, JavaScript, Java, C#, etc. and while their optimizations are pretty amazing for what they are, simply the fact that they are dynamic bytecode languages makes them comparatively extremely slow.
So it's not optimizations and program performance that drive language usage, most people don't care about that when choosing a language to use (as long as it is "fast enough"). It's simply a question on how much effort does it take to solve my problem in a satisfying manner

[flowCRANE]

There are currently no plans for this.

Ok, thank you for the answer.

The compiler currently has no way influence the optimization for that in any way,  because it's simply not implemented. So it makes no sense to polute the language with some mechanism that's not going to be implemented for the foreseeable future with users then asking why it isn't working.

If I knew what was implemented and whether it was possible to influence the optimizer, I wouldn't need to ask. But thanks anyway.

[MarkMLl]

There are currently no plans for this.

Ok, thank you for the answer.

The bottom line is that if it's not documented- and I don't mean a note in the wiki or some observations that the code generator usually/currently works favours "if" rather than "else"- then the facility quite simply does not exist.

My own feeling is that this is something which, if ever implemented at all, should be done as a pragma which tells the compiler that the developer is assuming that such-and-such a path is the likely one and at its discretion would the code generator please take that into account. In that role it would join the $OPTIMIZATION pragma, and possibly a pragma replacing the current almost-useless include keyword.

I don't think it would be appropriate to have it as a keyword, since by and large keywords are used to indicate things that the compiler is obliged to do: a forward declaration, a calling convention specification and so on.

MarkMLl

[flowCRANE]

My example with keywords was only an illustration of the problem, but I used keywords for a reason — they ensure high readability, are highlighted in a different style (like other keywords, so they would be clearly visible), are short and without special characters (so they are easy and quick to type) and do not require closures. This would be especially important in the case of many nested if else statements. For this reason, in my opinion, they are a better solution for language users, better than pragmas.

But how they would be implemented is not very important to me — it doesn't matter what form they take, as long as it is possible to instruct the optimizer about which execution path is more important. The compiler doesn't know path statistics, but I know exactly what they look like in many places, so I could help it try to generate better code.