SPEED IMPROVEMENT

This program is almost identical to the previous one except
that it runs noticeably faster.  In the old program, I
generated a list of 40,000 primes in just under a minute.
This version of the program does it in just under 10
seconds.  

The execution time decreased by breaking out of the for loop
on line 23 that checks that all the mods of known primes are
0.  Instead of comparing the number being checked with every
known prime, it now breaks out of the loop if any mod value
is 0.  The added test greatly reduces the number of mod
operations, comparisons, and inside this loop.  

For example, imagine the program has already found 10,000
primes, and it is looking for 10,001.  In the original
program, the for loop would do 10,000 comparisons even if
the number was a multiple of 3.  With this if-statement, the
program would check that the number was a multiple of three
and then kick out, saving at least 10,000 operations.  The
10,000th prime is 104,729.  The next prime isn't until
104,743: 14 cycles later.  That is approximately 140,000 mod
operations saved alone between these two primes.  


PROFILER OUTPUT

The following comes from the output of gprof:

	Each sample counts as 0.01 seconds.
		%   cumulative   self              self     total           
	 time   seconds   seconds    calls   s/call   s/call  name    
	100.00      1.71     1.71        1     1.71     1.71  ptest

This information tells me that my program is spending
all of its time in the function 'ptest'.  This makes sense
as it is the only function other than main that I have.

'cumulative seconds' represents the sum of all the functions
called up to and including 'ptest'.  Since 'ptest' is the
only function called, it is equal to 'self seconds': the
amount of time that 'ptest' itself took.  If there were other
functions invoked, 'self seconds' would be less than
'cumulative seconds'.

'calls' indicates that the function was only called once.

'self/call' and 'total s/call' also show the amount of time
spent in the function, this time on a per call basis.

The rest of the profiler output can be found in the file
'profile'.


SCALING

Since the algorithm hasn't changed, it is still expected to
scale quadratically due to its nested loops.  Change just
happens more gradually because no more checks are done on
numbers already ruled out as primes.