`likely`/`unlikely` unlikely to implement unless `unless` is `unlikely` but how likely is that?

[didactic-drunk]

Instead of adding likely/unlikely as keywords, reuse unless to indicate unlikely. This is likely to speed things up (See by the numbers below)

Why? Many types of conditionals are clearly less likely. Some examples:

def foo(str, size)
  # Guard conditions
  raise "empty str" unless str && str.presence
  raise "invalid size" unless size >= MINIMUM

  # c extension return values
  r = Libc.system_call
  raise Errno... unless r >= 0

  # Any other unlikely boolean
  cache_data unless Dir.exists?("cache_dir")

  ...
end

IAQ (Imaginary asked questions)

1. Would this break anything? No
2. Will this slow anything down? unlikely
3. Sorry, I missed that? I'll say it slower: stall stall stall unlikely

By the numbers

My understanding is if/unless are assumed to be true, however code is not necessarily written to take advantage of this making branch mispredictions normal.

There are ~350 if and 64 unless statements in crystal. 9 of the unless statements raise which I assume are guard conditions.
The first 10 unless entries, all except one appear to be unlikely conditions. It appears unless is already used for unlikely conditions. If anything this PR will improve existing code rather than slowing it down.

Providing unlikely via unless developers have the option to provide optimized conditionals for their existing if statements.

Other

First covered in #1712 and #5661.

Bonus points: Make the compiler parse the title without a cache miss.

[straight-shoota]

I think this feature request - along with its predecessors - is too specific. It proposes a specific solution for solving a (complex) problem.

But we need to look at the bigger picture before homing in on one solution. Let's start with the bare problem and a blank sheet ideas.

[yxhuvud]

The bare problem would be that the compiler sometimes assumes a branch happens either often or all the time, when in practice it is really uncommon. Being able to signal that would sometimes be pretty nice.

The two suggested solutions in this issue and the earlier are either a toplevel method or building it into the if/unless statements themselves. There is also a suggestion by way to not solve it. Personally I'd prefer not solving it over a magic solution like weighted implicit if-statements like the suggestion in this proposal. I'd prefer likely_if or unlikely_if over building it into the basic if-statement but I'm not certain if those variants would be worth having.

There are other ways to indicate this to the compiler though. One variant could be to create separate boolean types that are either likely or unlikely to be true. Another variant could be to make the user interface look like a method call, ie (x > 4).unlikely, and somehow (letting it be a macro that rewrites it to something the if statement could act on, could perhaps do it? Not certain if the path is possible even if it reads well).

[HertzDevil]

Crystal already uses llvm.expect.i1 internally for overflow checks on primitives like Int32#+(Int32) (32c5143). It is very much a real use case, even if the language does not expose this feature. If we toy around with that we might be able to gauge how much this would affect code performance.

On Discord I previously suggested allowing annotations in more places, so that one could write not just if @[Likely] x > 0, but also when @[Likely] .>(0). (This is more or less the approach taken by C++20.)

[didactic-drunk]

@jhass Ruby lives from its terseness and that terseness is where the expressiveness comes from IMO. I'd like to see as much as possible of that retained in Crystal.

This

if likely(x > 0)
if (x > 0).likely
if_likely > 0
if @[Likely] x > 0

Or this?

if x > 0
unless x <= 0

Did the new proposals improve expressiveness? They seem to increase verbosity.

[jhass]

But then I'm not sure terseness is all about amount of characters. It's also about conceptual complexity. If I have to think about 10 things one keyword could mean, is it still terse?

[didactic-drunk]

I'd like to point out the CPU must make a branch prediction. The compiler may restructure code to hint at which branch to take. Doing nothing is the same as (disregarding llvm optimizations):

if_likely x > 0
   ...
else_unlikely
  ...
end

Assuming nothing is done what would an optimized method with 3 guard conditions look like?

# A lot of c# code is written in this style to take advantage of assuming the first branch is true.
# Reading it is painful as fuck.
def foo(x, y, z)
  if x > 0
    if y > 0
      if z > 0
        ...
      else
        raise "z invalid"
      end
    else
      raise "y invalid"
    end
  else
    raise "x invalid"
  end
end

Or with unlikely unless

def foo(x, y, z)
  raise "x invalid" unless x > 0
  raise `y invalid" unless y > 0
  raise "z invalid" unless z > 0

  ...
end

From my perspective doing nothing is bad.
2 core members rejected likely as a keyword.
The unless proposal seems the least intrusive both conceptually and for terseness. It also often matches the way people code, So possible speed boost without changing any existing code.

Where is the downside?

[yxhuvud]

Where is the downside?

Lack of clarity. It absolutely forces you to read the documentation to figure out the behavior, and it may force you to write your code not the way that reads best, just to get the wanted behavior wrt likelyhood.

[HertzDevil]

unless !x.pred? is less clear than if likely(x.pred?). Tying branch prediction semantics to a language keyword forces users to write negated predicate methods whose sole purpose is to support the kind of branch prediction suggested in the OP if they want to get rid of the ! call. Also this means only if can be trivially rewritten to take advantage of it; elsif cannot and one must write else unless ...; ...; end; end explicitly, much less case.

[asterite]

Just a note that this can be completely implemented in the language right now:

lib LibIntrinsics
  fun expect_i1 = "llvm.expect.i1"(value : Bool, expected_value : Bool) : Bool
end

def likely(value : Bool)
  LibIntrinsics.expect_i1(value, true)
end

def unlikely(value : Bool)
  LibIntrinsics.expect_i1(value, false)
end

x = 1
if likely(x == 1)
  puts "Yes!"
else
  puts "No!"
end

Or instead of def they can be macros so they are always inlined (it's probably better)

With that in mind, I don't think we need to add to the language or change the language to implement this.

[didactic-drunk]

2 core members rejected likely(). Has this changed? I'm working within the confines of what they said.

case makes an interesting case for an annotation

[asterite]

2 core members rejected likely(). Has this changed? I'm working within the confines of what they said.

This happened in 2015 and 2018. I don't think the people that commented those things are the same people right now.

Also, before doing anything about this, someone should post proves that this actually improves performance. Like, a real peace of code where using likely or not using it dramatically changes the code's performance. Otherwise, there won't be any real pressure or reason to implement this, even if it's there in other languages, and even in LLVM.

[yxhuvud]

Also note that even if we use the implementation @asterite provided above, it doesn't necessarily need to be defined toplevel, it could just as well be something like Boolean.likely(..) if we don't want to pollute the global namespace. Marking something as likely is after all not something that we expect to be very common.

[j8r]

It is not always obvious what is more likely, and the programmer might make false assumptions about the frequency of branches.

Profile-guided optimization is an alternative which takes results from profiling to optimize the executable.
Another advantage is no source code has to be changed.