So, I'm currently going through some of the problems from project euler, specifically number 33.
The problem itself isn't really complicated but I noticed some strange benchmark results I would love to hear some opinions about.
Disclaimer: The following code solves the problem and if you don't want any spoilers you shouldn't keep reading
playground (copy and pasted some dependencies together until all required code was there).
Now the strange part:
in the if condition starting on line 61 the first two cases (out of the four) can never happen. So I assumed commenting them out should improve performance right.
So I changed the if condition as follows:
if n_1 == d_2 && n_2 == num && d_1 == den
|| n_2 == d_1 && n_1 == num && d_2 == den
{[...]}
And the performance decreased:
Original:
[src/bin/../helper.rs:69] now.elapsed().as_secs_f64() / loops as f64 = 0.00000226712
[src/bin/../helper.rs:69] now.elapsed().as_secs_f64() / loops as f64 = 0.0000020891310000000003
[src/bin/../helper.rs:69] now.elapsed().as_secs_f64() / loops as f64 = 0.0000020770779
[src/bin/../helper.rs:69] now.elapsed().as_secs_f64() / loops as f64 = 0.0000020719742
[src/bin/problem_0033.rs:33] solve() = 100
"Improved":
[src/bin/../helper.rs:69] now.elapsed().as_secs_f64() / loops as f64 = 0.0000025229199999999997
[src/bin/../helper.rs:69] now.elapsed().as_secs_f64() / loops as f64 = 0.0000024225290000000003
[src/bin/../helper.rs:69] now.elapsed().as_secs_f64() / loops as f64 = 0.0000024351696999999998
[src/bin/../helper.rs:69] now.elapsed().as_secs_f64() / loops as f64 = 0.0000024414159199999998
[src/bin/problem_0033.rs:33] solve() = 100
Thats a whooping 20%-25% slower than before. And that because of two conditions that could never happen (and should not help the compiler avoid any bound checks I assume).
I am relatively confident that the compiler does not optimize the function away completely while measuring as the measured time per loop stays roughly the same for different numbers of iterations (100,1000,10000,100000).