tables of p(n) and/or pi(n) / tables of primes

[Hugo Pfoertner]

cino hilliard wrote:
> 
> Hi Hugo,Hans and seqfans
> 
> >From: "Pfoertner, Hugo" <Hugo.Pfoertner at muc.mtu.de>
> >To: seqfan at ext.jussieu.fr
> >Subject: RE: tables of p(n) and/or pi(n) / tables of primes
> >Date: Wed, 21 Sep 2005 16:27:32 +0200
> >
[...]
> > >On Sep 19, 2005, at 6:53 AM, cino hilliard wrote:
> > >
> > >>I have computed and stored all primes < 100 billion in a 45 gig file.
> I finally computed and saved enough primes to get A099824(10)
> 
> This is updated to primes < 260 billion in file
> 12/19/2005  06:40 AM    82,406,594,024 prime2-260bill.bin
> 
> These numbers are 8 bytes binary and are  read and summed  by a power basic
> program dll. C
> cannot read beyond 2^31-1 bytes. The dll is declared in a bcx program and
> translated to LccWin32
> using the 100 digit precision qfloat to get the proper output.
> 
> Here are some timings including A099824(10). The sumprimes dll reads blocks
> of 1000 from the file
> prime2-260bill.bin  giving faster access.
> 
> num 1000000
> 7472966967499.0000000000000000000000000000
> Time  0.8125s
> Hugo fortran time  0.57s
> num 10000000
> 870530414842019.00000000000000000000000000
> Time  1.703125s
> Hugo fortran time  4.28s
> num 100000000
> 99262851056183695.000000000000000000000000
> Time  16.6875s
> Hugo fortran time 45.67s
> num 1000000000
> 11138479445180240497.000000000000000000000
> Time  170.4063s
> Hugo fortran time ? 4500s ?

Why should CPU time change from being proportional to the number of
items processed? If I had used the necessary amount of memory I would
expect ~= 450s.

> num 10000000000
> 1234379338586942892505.0000000000000000000
> Time  2042.953s  (While multi-tasking. Should be 1800 straight through)
> Hugo fortran time ?  45000s ?

There is no reason why the behavior of reading a big table should change
from being linear in the number of entries to be read. The mentioned
timings where by-products of reading a 333 MByte straightforward 1 byte
/ 30 numbers table storing the primality for numbers up to 10^10. The
purpose of having this table was to keep it in solid-state memory for
fast primality checking of randomly arriving numbers. Tables not fitting
into solid-state memory are of no interest in this context. Running
sequentially through consecutive primes might benefit from other
compression techniques.

Since disk space on my employer's computers is an expensive resource (in
contrast to CPU time), I will not participate in any effort to extend
anything needing big amounts of stored data on disk.

Hugo Pfoertner