[QUOTE=rogue;405382]
In 3.5, I removed the primegen sieve from pfgw because it produced incorrect results. If the current version of pfgw is producing incorrect results, then I need to know about it. I would like to replace the sieve I added with PrimeSieve (from Kim Walisch). Originally it did not have the features that I needed in order to use it with pfgw, but he has incorporated the features I requested, so I can use it with pfgw. I just haven't taken the time to get around to doing that.

You can redirect the output of pfgw by appending "> nul" to the command. This should work on Windows and *nix. On newer machines it won't have much of an impact, but it could on older machines that do not have a dedicated GPU.[/QUOTE]

I have no reason to think that newer versions of PFGW are producing any kind of incorrect results. The GUI version of 3.3.6 is just faster on teeny tests. I think it may have to do with how it is refreshing after each test, even in super quiet mode. I can definitely state that version 3.3.6 is correct in every regard as far as finding primes on both small and large tests. I've run tons of parallel tests on it vs. LLR and other versions of PFGW that were known to be correct.

I am not running the command-line version. I am running the GUI in super quiet mode. It is extremely fast on the teeny tests!

[QUOTE=rogue;405376]I am convinced that this could be much faster. The problem is that a new sieve needs to be written. This would be a sieve that solves for k when given b, n, c, and p for n. The problem with current sieves is that they know k, b, c, and p and solve for n. When you have a large number of k, it takes a much longer time to sieve because you have to solve for each k. Your sieve depth will determine what max n you can guarantee k*b^n+c will be prime. This would only work for low n (~ 20), but if we could knock 80% or more of the k quickly, then testing what remains should take a much shorter period of time.[/QUOTE]
Wouldn't newpgen do what you want? I realise that it is 32-bit and could be improved upon but it would still be fast for a fixed n sieve.
Another option to look at is polysieve.

[QUOTE=henryzz;405395]Wouldn't newpgen do what you want? I realise that it is 32-bit and could be improved upon but it would still be fast for a fixed n sieve.
Another option to look at is polysieve.[/QUOTE]

I haven't used newpgen in years, so that could be worth a look. I am not familiar with polysieve.

[QUOTE=gd_barnes;405383]Mark, I can already state that even on my older machine, PFGW 3.3.6 is going to be faster than your test for the n=2500 test with -f0. It is over half done in 4 hours. So it will likely complete in ~8 hours vs. your ~12 hours for the scripting portion of things.[/QUOTE]

I can't think of any other differences in the pfgw code that could account for such a difference. Does your machine have faster memory or a faster CPU?

[QUOTE=rogue;405408]I can't think of any other differences in the pfgw code that could account for such a difference. Does your machine have faster memory or a faster CPU?[/QUOTE]

No. As previously stated, it's only running at 2.67 Ghz. I'm confident that it is the PFGW version. PFGW 3.3.6 blows away any of the more modern PFGW versions for speed on very small tests. For n=2500-25K, it was much slower than yours. That is what would be expected since I have an older setup and software version. If you want me to provide a link to PFGW 3.3.6 that I use, I can. You can then see if you get a significant speedup for the teeny test portion of things.

I just now completed the test using sieving. Here are the timings:

Scripting n<=2500 with -f0 using PFGW 3.3.6: 7:59
Sieve n=2500-25K to P=200M: 0:33
Test n=2500-25K with -f0 using PFGW 3.3.6 and the stop-on-prime header: 8:23
Primality proof: 0:11
Total: 17:06

This was for the range of P=30G-30.005G. There were 325 k's remaining at n=2500 and 32 k's remaining at n=25K.

My tests without sieving are close to complete. They will come in at about 20 to 22 total hours for everything. I will post their exact timings after they are done later today. What is interesting about this is that your tests for scripting only were at 40-43% complete after 20 hours. Mine are FAR faster, more than double the speed, as they will complete in about that amount of time.

I am now reminded of why I thought that sieving was not worth it. I personally am experiencing only about a 15-20% speedup by sieving. I made the determination that it was not worth the personal hassle to deal with it, especially since the sieve files are huge for large k-ranges.

Another test that I am going to run: Scripting n<=2500 with -f10 (vs. -f0) as the first portion of the above. If that is faster than -f0, I will run a test with -f30.

Edit: Be sure and see the improved script that I previously posted that is for base 3 only. It should only make a very small difference in speed...perhaps 1-3%.

[QUOTE=gd_barnes;405417]What is interesting about this is that your tests for scripting only were at 40-43% complete after 20 hours. Mine are FAR faster, more than double the speed, as they will complete in about that amount of time..[/QUOTE]

I know that this is due to new sieving code in pfgw added in 3.5. The current sieving code is slower, but more accurate. Once I replace that with primesieve, the speed should be close to the speed of 3.3.6. I don't know when that will happen.

The vast majority of time used by the script is in PRP testing when n is small. The next biggest chunk is MOB testing. I have an idea that (if it works) should cut the time in half, if not better. This is my plan:

[FONT="Courier New"][SIZE="2"]
1) Run fixed-n sieve (newpgen) for n=1 to 20 (maybe higher)
2) Write a custom program to:
a) Take files from step 1 along with the base, mink, maxk, and c and produce pl_MOB.txt and pl_prime.txt.
b) For remaining k, sieve (srsieve) and test (pfgw) ranges in chunks of n. New primes are added to pl_prime.txt
c) When n=25000 is reached, output pl_remain.txt
[/SIZE][/FONT]

I've already started a program that can do steps 2b and 2c, but it isn't ready for prime time yet. 2a will take more time. I need to digest the MOB logic before I can do that.

I realized that I did write an opecl fixed-n sieve about three years ago. If it is at least as fast as newpgen, I will incorporate it into the program.

[QUOTE=rogue;405421]I realized that I did write an opecl fixed-n sieve about three years ago. If it is at least as fast as newpgen, I will incorporate it into the program.[/QUOTE]

It was for fixed k not fixed c, but it shouldn't be hard to modify it.

OK, I've finished all of my timings. For future reference all in one place, here are the specifics:

Machine: Vintage 2011. Intel I7 64-bit with 4 GB RAM at 2.67 Ghz
O.S.: Windows 7
Software: PFGW version 3.3.6
Range: k=30G-30.005G
k's remaining at n=2500: 325
k's remaining at n=25K: 32

Tests:
Script to n=2500 with -f0; sieve n=2500-25K to P=200M; test n=2500-25K;
Script: 7:59
Sieve: 0:33
Test: 8:23
Primality proof: 0:11
Total: 17:06

Script to n=25K with -f10: 20:11

Script to n=25K with -f30: 21:33

Script to n=25K with -f50: 23:04

So...I was wrong about -f30 being the fastest. Without any sieving -f10 is fastest. I'm glad I did this. I think I will stop the 4 cores of my current reservation and change them from -f30 to -f10.

Another interesting thing. It appears that there is a VERY significant speedup when scripting to n=2500 with -f10 or -f30 (vs. -f0). Once again, this is very different than what you found Mark. Those tests should be done within a couple of hours. I'll post the timings when they are done.

[QUOTE=gd_barnes;405431]Another interesting thing. It appears that there is a VERY significant speedup when scripting to n=2500 with -f10 or -f30 (vs. -f0). Once again, this is very different than what you found Mark. Those tests should be done within a couple of hours. I'll post the timings when they are done.[/QUOTE]

That might be enough to push me to get primesieve into pfgw.

Timings for scripting only k=30G-30.005G to n=2500 with various factoring switches using PFGW 3.3.6:

-f0: 7:59
-f10: 4:49
-f30: 4:51

(!!)

So at least on my setup -f10 is fastest across the board, whether it be scripting to n=2500 or n=25K with no sieving.

Extrapolating had I scripted to n=2500 with -f10 followed by sieving and testing as before, here would have been the timings:
scripting: 4:49
sieving: 0:33
testing: 8:23
proof: 0:11

Total 13:56. This would crush everything else and...it was done with a 4-year-old computer (not overclocked) and nearly 5-year-old PFGW. :-)

[QUOTE=gd_barnes;405438]Timings for scripting only k=30G-30.005G to n=2500 with various factoring switches using PFGW 3.3.6:

-f0: 7:59
-f10: 4:49
-f30: 4:51

(!!)

So at least on my setup -f10 is fastest across the board, whether it be scripting to n=2500 or n=25K with no sieving.

Extrapolating had I scripted to n=2500 with -f10 followed by sieving and testing as before, here would have been the timings:
scripting: 4:49
sieving: 0:33
testing: 8:23
proof: 0:11

Total 13:56. This would crush everything else and...it was done with a 4-year-old computer (not overclocked) and nearly 5-year-old PFGW. :-)[/QUOTE]

Did you using {number_primes,$a,1} for testing phase? That seems out of line from what I was expecting, unless you didn't sieve deeply enough. My times were much lower than that.