Testing new Ranges for Sierpinski/Riesel

[rogue]

I am releasing srbsieve (64-bit only right now), the program I have referred to in the Riesel Base 3 thread. So far this has only been tested with Riesel base 3. From my testing it can complete a range of 1G in 50 days or less on a single core of a modern laptop. This program requires pfgw64 and srsieve to be installed in the same directory as srbsieve. Although this is compiled only for Windows, the program can be compiled for other platforms. I just haven't tested on them yet. A sample configuration file is in the attachment. Most of the configurations are self-explanatory.

npgfile= is used to specify output files from newgpen's fixed n sieve. The first value is the n for which the range was sieved. The second is the name of the file that was output from newpgen. You can specify as many of these as you want, although there is a practical limit due to newpgnew limits with sieving. newpgen will sieve until p exceeds sqrt(maxk*b^n+c) and it will terminate on its own. That is great for this search because it means that all values remaining after sieving are prime which means that none of the values that passed sieving will require a primality test. You will not want to go to a very high n as sieving takes longer as n increases and the effectiveness of removing k is diminished. n=22 is about as far as one should go for Riesel base 3. Higher bases will result in going to a lower n.

phase= is used to sieve in steps. The first value is the upper n for the phase followed by the number of concurrent k to sieve and finally by the maxp of the sieving. This program will run srsieve with those settings then take the output and run it through pfgw (after adding the number_primes switch). You will want to sieve and test in multiple phases because k will be quickly removed and there is no point to sieving those k to higher n values. The settings in the file I provided are intended to keep the output from srsieve manageable in size. I have noticed that if the output from srsieve gets too large that the I/O slows down. After each phase srbsieve will output pl_remain.txt and when the last phase is completed, it will shutdown. Note that the sieve limits appear to be pretty good for Riesel base 3 although I certain that someone could tweak them better to get even better results than what I have provided.

Before running srbsieve you will need to run newpgen to generate the files needed for the npgfile= configuration. This program will not run if that is not done. I recommend running newpgen until mink*b^n > 1e20.

As srbsieve is running, it outputs stuff like the following:


Status (00:00:00): Started with 5000001 terms
Status (00:00:00): Removed 2500000 terms due to k being odd
Status (00:00:01): Removed 729499 terms due to MOB
Status (00:00:04): Removed 209104 terms from newpgen for n = 1: 1561398 remaining
Status (00:00:06): Removed 179665 terms from newpgen for n = 2: 1381733 remaining
Status (00:00:08): Removed 155802 terms from newpgen for n = 3: 1225931 remaining
. . . more lines . . .
Status (00:00:27): Removed 14325 terms from newpgen for n = 23: 246592 remaining
Status (00:00:27): Removed 13967 terms from newpgen for n = 24: 232625 remaining

Status (00:18:46): Completed 0.2149 pct of phase 1.
Status (00:35:58): Completed 0.4299 pct of phase 1.
Status (00:53:09): Completed 0.6448 pct of phase 1.
Status (01:10:08): Completed 0.8598 pct of phase 1.
Status (01:21:23): Completed phase 1: 39548 remaining
Status (01:45:47): Completed 0.7586 pct of phase 2.
Status (01:53:26): Completed phase 2: 5287 remaining
Status (02:04:59): Completed phase 3: 1018 remaining
Status (02:15:40): Completed phase 4: 271 remaining
Status (02:53:32): Completed phase 5: 91 remaining
Status (06:18:52): Completed phase 6: 32 remaining


This should be fairly self-explanatory. Note that this range of 5M took a little over 6 hours. That is less than half the time of using the new base script.

srbsieve will output pl_MOB.txt, pl_prime.txt, and pl_remain.txt according to what the new base script today although pl_prime.txt will not be sorted by ascending k. Fortunately if all k have the decimal length, it is easily sorted into ascending k. The only thing this program doesn't do is check for GFNs which only affects Sierpinski searches, but that should be fairly easy to add. No code changes should be required to use this for any other Riesel bases.

If you want the source or need a 32-bit version, please let me know and I'll post it.

[rogue]

I have a couple of other things of note. First, this program does run a primality test on the PRPs output by pfgw. Second,I noticed that a bunch of numbers in the range I tested were "Lucas and Fermat PRP", which means that pfgw could not prove primality on them. Those numbers were all under 40 bits or so in length. Now that newpgen is used to find all primes less than 60 bits in length, I haven't run into any small numbers that pfgw cannot prove primality on.

[lalera]

i did the test-range that is provided with srbsieve.
newpgen runtime is around 35 min.
srbsieve runtime is 04:52:54
on a sbe 3930k
works fine!

[rogue]

The percentage shown goes from 0.0 to 1.0. In the next release I'll multiple it by 100.

I have another note on this program. It does not produce pl_trivial.txt like the new-base script.

[lalera]

i tried several other bases but
srbsieve seems to work only with R3

[rogue]

Originally Posted by lalera

i tried several other bases but
srbsieve seems to work only with R3

What happens with other bases?

[lalera]

the program is starting and it gives out one or two lines on the screen and
then there is no progress to see - the taskmanager says that it is running

[rogue]

Originally Posted by lalera

the program is starting and it gives out one or two lines on the screen and
then there is no progress to see - the taskmanager says that it is running

Send me the srbsieve.ini file you are using.

[lalera]

Originally Posted by rogue

Send me the srbsieve.ini file you are using.

here is one

[rogue]

Originally Posted by lalera

here is one

I can't believe that you used newpgen up to n=24. That would take a very long time to sieve, probably days. I stated above that n=24 was probably adequate for base 3, but lower n should used for other bases. You want to choose a max n where b^n > 1e10. That is quickly exceeded at n=6. You have to fully sieve up to sqrt(maxk*b^n+c) because newpgen will stop automatically. If you stop newpgen in the middle of sieving, then you will have composite values in your newpgen output file.

That being said, I found the problem and you are correct that it was a hard-coded "3" in the code. I'll fix that shortly.

[lalera]

Originally Posted by rogue

I can't believe that you used newpgen up to n=24. That would take a very long time to sieve, probably days. I stated above that n=24 was probably adequate for base 3, but lower n should used for other bases. You want to choose a max n where b^n > 1e10. That is quickly exceeded at n=6. You have to fully sieve up to sqrt(maxk*b^n+c) because newpgen will stop automatically. If you stop newpgen in the middle of sieving, then you will have composite values in your newpgen output file.

That being said, I found the problem and you are correct that it was a hard-coded "3" in the code. I'll fix that shortly.

thank you!
(i did newpgen let run to p=80e9 ~ 8min per n)
i will change the n to 5000 for R498