You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
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 viaIx
typeclass, we'd rather stick either to low-level arrays fromprimitive
or to full-fledged vectors fromvector
. The arrays in question are quite long and we "grow" them ingrowCache
, soVector
is the right choice.Unfortunately, vanilla
Vector
does not support dense bit arrays (64 bits perWord64
). See also haskell/primitive#42. There isbitvec
package, which aims to provideVector
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 usingUArray Int Bool
.The text was updated successfully, but these errors were encountered: