Thread: Prime numbers

Originally Posted by abachler

This uses several optimizations, namely it skips all even numbers, which cant be prime (except 2), and uses a fast method for finding the Root of the prime.

The code will tend to be slower than the Sieve of Eratosthenes for large primes (as it checks if a value is divisible by every odd value less than its square root). The benefit is that it uses less memory (the SoE relies on keeping track of all primes found for subsequent testing, and they have to be stored somewhere).

Modifying the value of Root through iteration (as the code does) is not necessarily fast: tracking of the value of Root from one iteration to the next is the optimisation. In comparison with the looping over all odd values, the benefit of that optimisation is minor.

There is the inconvenient fact that the code is also windows specific (relies on compiler extensions).

int64 is an ansi standard datatype. __int64 is the windows specific implimentation of that datatype. The code is only trivially windows dependant, i.e. change the datatype from __int64 to int64 and it is ansi standard.

The code gains a huge performance increase in teh root optimization versus calculating teh root every iteration. Converting the relatively slow sqrt() to a simple divide and compare. As for the value of using SoE versus checking all odd numbers it depends on several factors, but mostly the speed of performign the calculations entirely in registers and the L1 cache versus making frequent calls into L2 and eventually uncached memory. Once the primes you are testing exceed available L2 memory for storage of the divisors, you will essentialyl be runnign at teh speed fo primary memory, which is usually orders of magnitude slower than my code, which will always run at synchronous speeds. Aside from that this code is designed to illustrate a solution not to be entered into the hall of fame for most optimized code EVAR.

Originally Posted by abachler

int64 is an ansi standard datatype. __int64 is the windows specific implimentation of that datatype. The code is only trivially windows dependant, i.e. change the datatype from __int64 to int64 and it is ansi standard.

Not true. int64 is not a standard type in either C or C++.

Originally Posted by abachler

The code gains a huge performance increase in teh root optimization versus calculating teh root every iteration. Converting the relatively slow sqrt() to a simple divide and compare.

You have some measurements to back that up? Having a loop that does divide-and-compares on most iterations will fairly quickly exceed the time for computing a square root: division is also a relatively expensive operation. Of course, computing sqrt() has other tradeoffs (most notably that there is no guarantee that the double type will hold larger integral values) but that's another story - I wouldn't use sqrt() with the SoE either.

Originally Posted by abachler

As for the value of using SoE versus checking all odd numbers it depends on several factors, but mostly the speed of performign the calculations entirely in registers and the L1 cache versus making frequent calls into L2 and eventually uncached memory. Once the primes you are testing exceed available L2 memory for storage of the divisors, you will essentialyl be runnign at teh speed fo primary memory, which is usually orders of magnitude slower than my code, which will always run at synchronous speeds.

I'm not saying you're wrong here, but I'd be interested in seeing measurements to back up your comments. Relying on L1 and L2 cache hits is highly system dependent, highly dependent on how your compiler and system optimises operations. However, increasing the rates of cache hits does not change the fact that your code inherently does more expensive operations (notably division) than alternate approaches like SoE. I'd be interested to know where the cross-over point is.

Your comments on relative performance with SoE are easy to justify for small primes, but harder to justify for larger ones (as, when testing a large value, there are more divisors to be eliminated, and therefore more divisions to be performed).

Originally Posted by grumpy

Not true. int64 is not a standard type in either C or C++.

Originally Posted by http://home.att.net/~jackklein/c/inttypes.html

The Long Long Int Types (C Only)

64 bit processors have been readily available in workstations for several years, and they will be coming to desktop computers soon. These processors can address enough memory to have arrays with more elements than a 32 bit long can specify. Inexpensive disk drives in use today can hold a file which contains more bytes than a 32 bit offset can reach. The requirement for an integer type required to hold more than 32 bits is obvious.

The 1999 update to the ANSI/ISO C language standard has added a new integer type to C, one that is required to be at contain at least 64 bits. Included in this update are the new variable types signed and unsigned long long . The selected name comes from gcc and several other compilers which already provide this type as an extension. On 32 bit Windows compilers from Microsoft, Borland (and maybe others) this same extension has the name __int64.

You have some measurements to back that up? Having a loop that does divide-and-compares on most iterations will fairly quickly exceed the time for computing a square root: division is also a relatively expensive operation. Of course, computing sqrt() has other tradeoffs (most notably that there is no guarantee that the double type will hold larger integral values) but that's another story - I wouldn't use sqrt() with the SoE either.

it divide and compares once per loop versus sqrt() once per loop, therefore its a one to one comparison. sqrt() is slower than divide and compare.

I'm not saying you're wrong here, but I'd be interested in seeing measurements to back up your comments. Relying on L1 and L2 cache hits is highly system dependent, highly dependent on how your compiler and system optimises operations. However, increasing the rates of cache hits does not change the fact that your code inherently does more expensive operations (notably division) than alternate approaches like SoE. I'd be interested to know where the cross-over point is.

Your comments on relative performance with SoE are easy to justify for small primes, but harder to justify for larger ones (as, when testing a large value, there are more divisors to be eliminated, and therefore more divisions to be performed).

By all means, post your SoE implimentation on the contest.

long long (in the 1999 C standard) is not required to be the same as a 64 bit int: in fact the standard goes out of its way to avoid mandating particular representations (eg integer types with a specified number of bits) of the "basic types" (int, long, long long, etc). There is no standard type named int64 or similar.

Originally Posted by abachler

it divide and compares once per loop versus sqrt() once per loop, therefore its a one to one comparison. sqrt() is slower than divide and compare.

It is not necessarily slower than multiple divide and compares though, which your code can exhibit if there are multiple composite numbers between two consecutive primes. Hence my request that you back up your comments.

Originally Posted by abachler

By all means, post your SoE implimentation on the contest.

I'm not the one who has made a claim of offering an optimised solution: you are. I am asking you to back up your assertions.