Chasing Primes

The Programming Rite of Passage

Counting prime numbers up to a given limit is a classic rite of passage for new programmers. It’s often assigned early in a course because it naturally introduces key concepts such as variable types, loops, arrays, procedures, and basic algorithm optimization.

A prime number is a whole number greater than 1 that can be divided evenly only by 1 and itself. For example, 7 is prime because its only divisors are 1 and 7, while 15 is not prime because it can be divided evenly by 1, 3, 5, and 15.

Most beginners approach prime detection by checking divisibility and examining remainders. While this method works, and can be improved with smarter logic, it is not the most efficient for large ranges.

An elegant alternative dates back thousands of years to the 3rd century BCE. The mathematician Eratosthenes of Cyrene developed a remarkably efficient technique now known as the Sieve of Eratosthenes. This algorithm is frequently introduced alongside prime-counting assignments because it naturally involves array manipulation and demonstrates how algorithmic thinking can dramatically improve performance.

To see how this timeless mathematical problem scales across physical technology, we compiled and executed a native Prime Counting C Application on computer environments spanning a quarter century—tracking how hardware evolution alters pure computational speed.

A Simple Explanation

Goal: Find all prime numbers up to a chosen limit.

1. Write down all numbers from 2 up to your limit.
2. Start with the first number, 2. Since it hasn't been crossed out, it's prime.
3. Cross out all multiples of 2 (4, 6, 8, 10, ...), because they can be divided by 2.
4. Move to the next uncrossed number, 3. It's prime.
5. Cross out all multiples of 3 (6, 9, 12, 15, ...).
6. Repeat: each time you find an uncrossed number, keep it and cross out its multiples.
7. When you're done, every number that remains uncrossed is prime.

Because this sieve relies heavily on allocating a massive array and iteratively jumping through memory to cross off flags, it serves as an exceptional modern benchmark not just for pure raw processor clock speeds, but for memory latency and CPU cache capacity.

Visualizing the Gap: 100M Limit Performance

To compare all systems fairly, we mapped out the execution times for calculation targets up to 100 Million. Run the 100M benchmark above to see your device plot instantly against legacy and cutting-edge desktop silicon.

The Raw Benchmark Data

The processing times recorded below showcase raw calculation speeds (measured in milliseconds). Lower numbers indicate faster performance.

Key Takeaways & Engineering Insights

1. The Generational Leap (150x Improvement)

Looking closely at the 100 Million calculation block, the year-2000 Dell 5000e running an Intel Pentium III at 550MHz sputtered through the operation in a sluggish 25.49 seconds. Flash forward to the AMD Ryzen 7 9800X3D: it chews through the exact same logic in an invisible 167 milliseconds. That is roughly a 152x speedup, highlighting the massive cumulative effect of frequency improvements, branch prediction refinements, and Instructions Per Clock (IPC) gains over 25 years.

2. The Magic of Large CPU Caching (3D V-Cache)

A classic Sieve of Eratosthenes requires a large chunk of sequential memory array flags. When calculating up to 10 Million, the memory requirement easily fits entirely within the Ryzen 7 9800X3D's massive 96MB of L3 3D V-Cache. Because the CPU doesn't have to continuously fetch data from system RAM, its processing speeds fall to a jaw-dropping 8 to 11 milliseconds.

3. The Severe Tax of Virtualization & Emulation

Look at the Ryzen 9800X3D's behavior inside VirtualBox. Running modern Linux Mint introduces only a minor performance degradation (from 167ms to 208ms at 100M). However, spinning up a 32-bit legacy Windows XP Virtual Machine sends the calculation time skyrocketing to 5,299 milliseconds! Forcing modern Zen 5 architectures to context-switch through legacy 32-bit translations inside an unoptimized hypervisor box destroys execution efficiency.

4. OS Ecosystem Variations

On the Intel Core i5 inside the Early 2015 MacBook Pro, running a native application on Windows 11 surprisingly squeaked past macOS Monterey when tasks scaled up to 1 Billion numbers (13,170ms vs 14,629ms). This highlights how variations in compiler optimizations (GCC/Clang vs MSVC) handle deeply nested looping matrices differently.

Hardware Timeline Map