Draft impl of JP06 pseudo-uniform sieve #65
Conversation
Avoid a clone
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## master #65 +/- ##
==========================================
- Coverage 99.37% 95.25% -4.13%
==========================================
Files 9 10 +1
Lines 1280 1390 +110
==========================================
+ Hits 1272 1324 +52
- Misses 8 66 +58 ☔ View full report in Codecov by Sentry. |
src/uniform_sieve.rs
Outdated
| // λ(m) = 0x0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000099F002D0502D70DF7B64150D19B477A781987C56EBCDB7637842794D22D0D022010DC9BA1DB141FC9D07A9587E7A130D9DF6F9B67812800D00 | ||
| // TODO(dp): Would love for this to be `const`. Or not here at all. Does it have any value, in some form? | ||
| #[allow(unused)] | ||
| fn calculate_m_and_lambda_m<T>() -> (T, T) |
There was a problem hiding this comment.
How long does that take, compared to prime searching? If it's not too long, we can just generate it in the sieve on every call. If it is, could be put in https://doc.rust-lang.org/std/sync/struct.LazyLock.html, but that requires std, so will have to be gated behind a feature.
There was a problem hiding this comment.
I had a thought about moving it to a build.rs and spit out a file on disk with the values. That way it wouldn't bloat the binary. But that sucks in a lot of ways.
Another thought I had was to remove the code completely and add a git commit hash as a comment in the code, providing future readers a way to check how the constants were generated if they really care.
Plenty to do here still, but I wanted to check the temperature on adding something like this. I have some preliminary benchmarks but need more, as well as some sort of measurement of the quality of the candidate distribution.
Benchmarks:
The above benchmark results are quite surprising to me. I expected the uniform sieve to be significantly slower than our
PRIMEINCsieve. One odd thing is that I discovered by accident that when finding the upper bounds foralgorithm2, usingT::random_modis significantly slower thanT::random_bits(code here vs here). I can't quite explain why this is and have not (yet) benchmarkedcrypto-bigint.