Burst Hint Likely/Unlikely interesting results

Unity Engine
, ,
1

Doing some profiling using the Hint Likely/Unlikely intrinsic and I’m not sure what is going on here. So firstly the result.

The code

public int GetClosestSegmentNew(float3 position)
{
    // Find the first point in the closest line segment to the path
    float closestDist = DistToSegment(position, this.Path[0].Position, this.Path[1].Position);
    int closestSegment = 0;

    for (int i = 1; i < this.Length - 1; i++)
    {
        float dist = DistToSegment(position, this.Path[i].Position, this.Path[i + 1].Position);

        if (Hint.Unlikely(dist <= closestDist))
        {
            closestDist = dist;
            closestSegment = i;
        }
    }

    return closestSegment;
}

Using Unlikely hint - the correct choice

24.22 without hint
20.97 with hint
A pretty significant improvement

Using Likely hint - the wrong hint

Ok now the results are weird. How is it also faster!? It’s not as fast (and I repeat this test a lot of times to confirm and it’s consistently a little slower than Unlikely) but it’s still significantly faster than not having a hint. How?

and just to confirm it’s not something odd, removing the hint.

Both tests run the same speed as expected.

So the bad and naive TLDR would be, just add hints to every condition and things will run faster!
What I’m trying to understand is what is going on here and how both likely and unlikely on a condition could be faster.

-edit-

totally forgot there is a burst forum now I’ve cross posted to it here:

2 Likes
Burst Hint Likely/Unlikely interesting results
2

Well, I suppose this is the reason they both exists :slight_smile:
The better explanation we’ll get when will look at assembly code compiled in those 3 situations. You know that both hints tell the compiler that: “Hey, I can help you optimize this stuff, this is how I expect it will work In most cases” and then the compiler can process better-optimised code for our expected result and can vectorize it much better. When you haven’t any hints it will process branching with the (sort of) equal optimization priority which not optimize it to one or another branch (by branch I mean not only real branching code but the existence or not of code block inside the loop :slight_smile: ) in most cases and thus not vectorizes code properly.
Eventually only compiled assembly code will tell us “why” :slight_smile: Or @sheredom can explain it better than me (in case if I’m not wrong :smile:)

3

I’ll post the assembly up tomorrow just headed off to bed.

But if both hints work then to me that feels like there is room for improvement for burst if it just assumed one way or other.