primesieve, a prime generator that sizes itself to your cache

Cache detection is the design decision

primesieve is a command line program and C/C++ library for quickly generating prime numbers, and the README leads with the reason it is fast rather than with a benchmark number. It is very cache efficient, it detects the CPU's L1 and L2 cache sizes and allocates its main data structures accordingly, and it is multi-threaded by default, using all available CPU cores whenever possible, which is to say whenever sequential ordering is not required. The last clause is the one to hold on to, because it decides which parts of the tool can be parallel. The algorithm underneath is a segmented sieve of Eratosthenes with wheel factorization, with a run time complexity of O(n log log n) operations and O(sqrt n) memory, and the range it covers is primes and prime k-tuplets up to 2^64. The audience is a number theory developer, a cryptography researcher, or a systems programmer who needs primes over a large interval quickly and would rather link a library than write a sieve.

The bucket sieve for the big ranges

Above a certain size the classic sieve stops working well, and the README names the technique primesieve uses to fix that. It uses the bucket sieve algorithm, which improves the cache efficiency when generating primes greater than 2^32, and the more algorithm details live in a separate document, doc/ALGORITHMS.md. The memory story is stated precisely enough to be useful. primesieve uses 8 bytes per sieving prime, so in practice the memory usage is about pi(sqrt(n)) times 8 bytes per thread, where pi counts the primes up to the square root of the limit. That is the number to compute before you run it on a shared machine, because the figure scales with the square root of the range and with the thread count, and a run with every core on a 64 core machine is a different order of memory from a single threaded run over a small interval. The topic list on the repository also names the instruction sets in play, arm-neon, arm-sve, avx2 and avx512, which tells you the low level code is written per architecture rather than relying on a single generic path.

Seven package managers, one command

Installation goes through the operating system's package manager, and the README lists one command per platform. The development packages have a different name, since building against libprimesieve may need libprimesieve-dev or libprimesieve-devel depending on the distribution.

winget install primesieve
brew install primesieve
sudo pacman -S primesieve
sudo apt install primesieve
sudo dnf install primesieve
pkg install primesieve
sudo zypper install primesieve

Those cover Windows, macOS, Arch Linux, Debian and Ubuntu, Fedora, FreeBSD and openSUSE. The library side of the project is the C API and the C++ API, each with its own documentation file in the doc directory, and the repository carries a primesieve.pc.in file, which is the pkg-config template, so linking against an installed copy is a matter of a standard pkg-config entry rather than hand written paths. The build is CMake, with a CMakeLists.txt at the root and a cmake/ directory, and the source is in src/ with public headers in include/.

The command line is broad, and printing has a caveat

The usage examples in the README show the shape of the tool. A bare limit counts the primes below it using all cores, --print prints them, a redirect writes them to a text file, --print=2 prints the twin primes, and a combination of --dist and --count=3 counts the prime triplets inside an interval.

# Count the primes ≤ 1e10 using all CPU cores
primesieve 1e10

# Print the primes ≤ 1000000
primesieve 1000000 --print

# Store the primes ≤ 1000000 in a text file
primesieve 1000000 --print > primes.txt

# Print the twin primes ≤ 1000000
primesieve 1000000 --print=2

# Count the prime triplets inside [1e10, 1e10+2^32]
primesieve 1e10 --dist=2^32 --count=3

The caveat is stated in the same section, and it is the most useful sentence in the README. Printing primes and storing them in a text file are not the primary use cases, because both run single threaded as printing requires sequential ordering, and both use the same standard output path rather than file specific I/O optimizations. For maximum throughput the documentation points at libprimesieve and generating the primes in memory instead. In other words, if you pipe a billion primes to a file, you have left the fast path.

Options for counts, intervals, nth primes and sieve size

The option list in the README is the reference for what the tool can do. Counting is the default and covers primes and k-tuplets up to six, with the count value selecting twin primes, triplets and beyond. --dist sets the interval to sieve, so the run covers a window rather than everything below a limit, and --nth-prime finds a prime by index, either the nth prime overall or the nth prime above a start value, which is a genuinely useful mode for a library user. --size sets the sieve size in KiB with a ceiling of 8192, and the default is computed from the hardware, matching the CPU's L1 cache size per core or being slightly smaller than the L2 cache size. --threads sets the thread count up to the number of cores, --quiet reduces output, --time prints the elapsed seconds, --cpu-info prints the cache sizes it detected, and --test runs the correctness tests, which the option list says take less than a minute. A tool that exposes its own detected cache sizes is doing you a favour, since it lets you confirm the assumption the default rests on.

Stress testing the machine, not the numbers

primesieve includes support for stress testing both the CPU and the memory, and the documented purpose is checking system stability under maximum load and verifying whether the cooling solution is adequate. Two modes are offered, CPU for the highest CPU load using little memory and RAM for high memory usage at about 1.2 GiB per thread. The example run in the README uses a five minute timeout, reports the expected memory usage for the thread count, and then prints a line per thread with the prime counting function it computed and the result, ending with all tests passed successfully. The interesting part is the failure semantics, since the stress test keeps running until either a miscalculation occurs, which the README attributes to a hardware issue, or the timeout expires, and it can be cancelled at any time with Ctrl+C. A tool that can detect a marginal CPU or memory fault while it is running is useful to a systems administrator, and primesieve bundles that with the number theory work because the sieve is the load generator.

Version cadence, licence and the shape of the tree

The releases move often, with v12.14 on 2026-05-08, v12.15 on 2026-07-17 and v12.16 on 2026-09-28, and the repository is not archived with the last push on 2026-10-16, so the project is being maintained and released regularly. The licence is BSD-2-Clause, with the text in COPYING, which is a permissive grant that lets you embed the library in a commercial product without the copyleft obligations of the GPL, and it suits a project whose main use is being linked into someone else's tool. The repository layout is small and conventional, with src/ and include/ for the code, doc/ for the C API and C++ API documentation and the algorithm notes, test/ for the test suite, scripts/ for helper scripts, examples/ with both C and C++ example programs under a CMakeLists.txt of their own, and an AGENTS.md at the root for automated agents working in the tree. A ChangeLog file sits alongside, and the continuous integration has separate workflows for the build and for benchmarks, which is consistent with a project whose first claim is about performance.

Editorial conclusion

primesieve fits a number theory developer who needs a prime count or a prime list for a large interval and wants the work spread across every core, and it fits a systems engineer checking whether a machine is stable under maximum load, since the stress test mode is part of the same tool. It does not fit a program that wants primes one at a time as a stream, because the library interface is built around bulk generation, and it does not fit a team that needs the command line program to be a service. Verify three things before you depend on it: which interface you want, since the documentation states that printing and writing to a text file are not the primary use cases and both run single threaded, what the sieve size default does on your CPU, since it follows the L1 cache size per core or slightly less than the L2 size, and which version you link against, since the library ships a C API and a C++ API with their own documentation files and the version numbers move often.

Frequently asked questions

Official sources

1. Issues
2. kimwalisch/primesieve on GitHub
3. License: BSD-2-Clause
4. README
5. Releases