Optimising Sieve of Atkin by calculating instead of iterating.

[tfpf]

No description provided.

[tfpf]

I am not convinced this has better performance. Are FP operations less expensive than loops?

[tfpf]

I plotted histograms of the running times (in milliseconds) of constructing the sieve of Atkin up to 100,000,000 on the GitHub Actions runners. As seen in the details of the previous commit, this was done 10,000 times for both methods, starting with the older method. There were 1,000 histogram bins distributed equally in the range of values obtained with each method. (Note that this means the bins were different for the methods.)

On macOS, it is unclear which approach is better. Iteration may be faster, but that is probably reading too much into the histogram.

On Ubuntu, calculation is clearly better.

On Windows, iteration may be better, but the difference may not be enough to say this with certainty.

[tfpf]

Same graphs as above, but with the calculation performed first. (See the details of the previous commit.)

[tfpf]

Here are the results on my system.

Now I feel confident going forward with these changes.

[tfpf]

Benchmarking with Criterion.rs reveals that constructing the sieve till 1,000,000 is faster with iteration than calculation. More analysis required!

[tfpf]

Constructing the sieve of Atkin up to 10⁶ is faster on this branch than main. This probably because of 9f72915.

main

sieve_of_atkin          time:   [164.81 µs 164.99 µs 165.19 µs]
                        change: [+0.0173% +0.2115% +0.4076%] (p = 0.04 < 0.05)
                        Change within noise threshold.
Found 3 outliers among 100 measurements (3.00%)
  3 (3.00%) high mild

atkin-iteration2calculation

sieve_of_atkin          time:   [152.19 µs 152.46 µs 152.73 µs]
                        change: [-7.9673% -7.6964% -7.4022%] (p = 0.00 < 0.05)
                        Performance has improved.
Found 9 outliers among 100 measurements (9.00%)
  4 (4.00%) low mild
  2 (2.00%) high mild
  3 (3.00%) high severe

My previous experiments indicate, however, that the performance depends on the size of the input. Should I try an introspective approach? Iteration for small inputs and calculation for large inputs?

[tfpf]

For 10⁵, this branch is slower.

main

sieve_of_atkin          time:   [18.959 µs 18.974 µs 18.990 µs]
                        change: [+0.7638% +0.9530% +1.1370%] (p = 0.00 < 0.05)
                        Change within noise threshold.
Found 4 outliers among 100 measurements (4.00%)
  1 (1.00%) high mild
  3 (3.00%) high severe

atkin-iteration2calculation

sieve_of_atkin          time:   [20.554 µs 20.581 µs 20.608 µs]
                        change: [+7.9204% +8.1374% +8.3305%] (p = 0.00 < 0.05)
                        Performance has regressed.
Found 2 outliers among 100 measurements (2.00%)
  1 (1.00%) high mild
  1 (1.00%) high severe

To summarise, calculation is 2 µs slower than iteration when the input is 10⁵, but 12 µs faster when the input is 10⁶. I guess it's okay to always use calculation.

[tfpf]

For inputs 10⁷, 10⁸ and 10⁹, there was no significant difference between calculation and iteration.

Input	Iteration	Calculation
107	1.7919 ms	1.7881 ms
108	75.724 ms	75.903 ms
109	890.03 ms	891.42 ms

Closing.