Description
Our implementation of Eratosthenes sieve is notoriously difficult to read. It has been heavily optimized long time ago and I have no clue if these patterns still make sense for modern GHCs and modern PCs. It is also quite possible that bugs are lurking in dark corners. I tried to disentangle it a couple of times, but always retreated in horror. Basically, it is too easy to introduce an off-by-one error, which will manifest itself only for a small portion of cases, possibly very large ones.
Maybe there is a better path: reimplement prime sieves altogether using the sieve of Atkin. It has better performance characteristics and the relevant paper is super clear.
Note on containers. Current implementation represents sieves by UArray Int Bool
. This is clearly the wrong level of abstraction: since we do not employ fancy indexing via Ix
typeclass, we'd rather stick either to low-level arrays from primitive
or to full-fledged vectors from vector
. The arrays in question are quite long and we "grow" them in growCache
, so Vector
is the right choice.
Unfortunately, vanilla Vector
does not support dense bit arrays (64 bits per Word64
). See also haskell/primitive#42. There is bitvec
package, which aims to provide Vector
interface to dense bitmaps, but it is abandoned: known issues are open for two years and the test suite does not build anymore. So for the time being there is no other choice but continue using UArray Int Bool
.