Review of generated assembly

[nakedible]

The current library compiled to assembly can be viewed conveniently here on godbolt: https://godbolt.org/z/hjfvj9a1v

Documentation and other noise has been stripped for easy comparison between source and assembly.

@cassioneri I would be delighted if you could take a quick peek through the generated assembly for the entire library to see if anything terribly obvious strikes out as being inefficient. But I understand if you are too busy. I am planning on releasing 0.1.0 of the library now that I think the public api asserting and datatypes are the way they should be.

[cassioneri]

I'm glad to help. I took a quick look and, for the moment, I have just one suggestion. There's an alternative for is_leap_year (which I did not mentioned in my talk) that saves one instruction (and, perhaps, a little bit of time):

pub const fn is_leap_year(y: i32) -> bool {
    if (y % 25) != 0 { 
        y & 3 == 0
    } else {
        y & 15 == 0
    }
}

Notice that we check divisibility by 25 instead of 100. This works for the following reasons.

1. First assume that y % 4 != 0. It follows that y % 16 != 0. Hence, the conditions y & 3 == 0 and y & 15 == 0 are both false and thus, the code above returns false as it should (regardless of y % 25.)

2. Now assume that y % 4 == 0. In this case, y % 25 == 0 if, and only if, y % 100 == 0. Hence, the result of the code above is exactly the same as the original's.

Now, since y % 100 == 0 is equivalent to y % 4 == 0 && y % 25 == 0, one can expect (philosophically, at least) that checking y % 25 == 0 is cheaper than checking y % 100 == 0. This is indeed the case as you can see here: https://godbolt.org/z/z8PTP7jc9

Notice the missing ror eax, 2 in the second assembly. To understand why this instruction is needed in the first case but not in the second, take a look at my article in Overload 154: https://accu.org/journals/overload/27/154/overload154.pdf#page=13

Final remark which, although not related to your code, I hope you enjoy 🙂: The now obsolete .NET6 implementation, took profit of the math above. However, their code followed the traditional logic that first checks divisibility by 4 and contains branches. So although they saved one instruction the performance got worse. The reason is hinted in my talk: branching on y % 100 == 0 splits execution into two paths with 1% and 99% probability whereas branching on y % 25 == 0, splits it into two paths with 4% and 96% probability. The latter is more difficult for the branch predictor.

I will need more iterations at your code to see if I can spot any other improvement but overall, I think it is very efficient. Good stuff!

[nakedible]

Testing shows this change has a 1%-1.5% performance benefit that's barely breaking noise threshold. On the test setup, that's less than 15 picoseconds. But an improvement is an improvement, so I'm taking it.

For just curiosity, switching to % 4 and % 16 produces a branch based version of the code (for some reason). This version is 30% faster in a tight loop (with random input values, on average) - but since we are talking about 300 picoseconds on a 1 nanosecond function, it's much more important that the functions using this are fast. I benchmarked % 25 vs % 100 on that version with the branches, and % 100 was around 1.5% faster, most likely due to the improved branch prediction as you mentioned.

Thank you for the contribution, this has been very interesting again!