Wrapper that owns an allocation from primesieve and will correctly free it when it is dropped.
This wrapper acts like a slice of T, similar to Rust’s Vec.
By-value iterator for PrimeArray that “correctly” drops any un-consumed values if the iterator is dropped without consuming all its elements.
This is a bit over the top, since PrimeArray can only be obtained with T being a primitive integer type with trivial drop, so we don’t have
to bother dropping elements. And also, PrimeArray itself only frees its allocation, it does not drop elements. But given that this is
EXACTLY the same as MallocArrayIterator from another of my wrapper crates, I made this future-proof implementatation in case I ever add functionality
to re-use buffers in place. The reasonable way to do that would involve custom allocators, but Rust’s allocator API does not actually jive with
real-world C libraries like gmp, flint, primesieve, etc that have some malloc-wrapper like raw::primesieve_free, so we can only handle this in
unreasonable ways.
This is a more flexible interface into primesive than generate_primes and generate_n_primes: using the iterator interface,
we can decrease memory usage, amortize prime generation, split work across threads, and more.
This crate is a wrapper of Kim Walisch’s primesieve, see the C documentation for more details.
Used with raw functions raw::primesieve_generate_primes and raw::primesieve_generate_n_primes to select the data type.
When using the high level wrappers generate_primes and generate_n_primes, the output type is automatically inferred based on the
inputs. When the inputs are integer literals with no suffix, the compiler might successfully infer the type from the output usage, but you
may need to add a suffix. The iterator interface PrimeIterator always returns u64 primes.
NOTE: there are MUCH faster algorithms to count primes than actually generating all primes, so this function should generally not be used.
Count primes in [start, stop] (both ends inclusive). This function is multithreaded, see set_num_threads (defaults to all threads).
Count quadruplet primes, ie quadruplets where p, p + 2, p + 6, and p + 8 are all prime and ALL in the interval [start, stop] (both inclusive). This function is multithreaded, see set_num_threads (defaults to all threads).
Count quintuplet primes, ie quintuplets where p, p + 2, p + 6, p + 8, and either p - 4 or p + 12 are all prime and ALL in the interval [start, stop] (both inclusive). This function is multithreaded, see set_num_threads (defaults to all threads).
Count sextuplet primes, ie sextuplets where p - 4, p, p + 2, p + 6, p + 8, and p + 12 are all prime and ALL in the interval [start, stop] (both inclusive). This function is multithreaded, see set_num_threads (defaults to all threads).
Count triplet primes, ie triples where p, p+2, and p+6; or p, p+4, and p+6 are all prime and ALL in the interval [start, stop] (both inclusive). This function is multithreaded, see set_num_threads (defaults to all threads).
Count twin primes, ie pairs where p and p+2 are both prime and BOTH in the interval [start, stop] (both inclusive). This function is multithreaded, see set_num_threads (defaults to all threads).
Generate n primes starting at start (including start if it is prime).
The type is inferred from the inputs. If the inputs are untyped integer literals, then the compiler might fail to choose the right type
depending on how the output is constrained, so you may need to add a suffix like 1_000_000u64 to the input.
Generate all primes in the range [start, stop] (both ends are inclusive).
The type is inferred from the inputs. If the inputs are untyped integer literals, then the compiler might fail to choose the right type
depending on how the output is constrained, so you may need to add a suffix like 1_000_000u64 to the input.
get the number of threads primesieve’s multithreaded functions will use, which defaults to the number of hardware threads, but can
be overridden with set_num_threads. Most CPUs have a feature called “hyperthreading” where each CPU core can run 2 hardware threads at once,
but some CPUs (mostly Intel and mobile) have “efficiency cores” which are slower and don’t support hyperthreading. Some CPUs like Apple’s M chips
even have more core tiers than just efficiency and “performance”, and I’m not sure generally how primesieve chooses the number of threads in this case.
In theory we could use one thread per hardware thread but allocate less work to efficiency cores, but in practice the threads we spawn would not actually
get pinned to certain cores without OS level muddling, so just spawning one thread per hardware thread on the highest performance tier of cores would probably
be ideal.
NOTE: we can compute the nth prime MUCH faster than actually generating all primes up to (nth prime after start), so this function should generally not be used.
Find the nth prime >= start. This function is multithreaded, see set_num_threads (defaults to all threads).
set the number of threads primesieve’s multithreaded functions will use, which defaults to the number of hardware threads.
Most CPUs have a feature called “hyperthreading” where each CPU core can run 2 hardware threads at once,
but some CPUs (mostly Intel and mobile) have “efficiency cores” which are slower and don’t support hyperthreading. Some CPUs like Apple’s M chips
even have more core tiers than just efficiency and “performance”, and I’m not sure generally how primesieve chooses the number of threads in this case.
In theory we could use one thread per hardware thread but allocate less work to efficiency cores, but in practice the threads we spawn would not actually
get pinned to certain cores without OS level muddling, so just spawning one thread per hardware thread on the highest performance tier of cores would probably
be ideal.