[QUOTE=gd_barnes;405417]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[COLOR=red] to P=200M[/COLOR]: 0:33
Test n=2500-25K with -f0 using PFGW 3.3.6 and the [COLOR=red]stop-on-prime header[/COLOR]: 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.
[/QUOTE]

Sieving was deep enough. It's an old machine running old software.

[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]

Now that -f10 appears optimal, it may be worth it to test scripting to 5000 with -f10 then sieving. That may also cut file sizes for the big ranges enough to make script-then-sieve more worth the human-time cost.

Mark, you said that you could not get cllr to work with these large k's. I am having no problem with cllr 3.8.13 using the stop-on-prime switch for n=2500-25K. Perhaps you were referring to smaller tests. I will report my timing on it mid-day Tuesday.

[QUOTE=gd_barnes;405461]Mark, you said that you could not get cllr to work with these large k's. I am having no problem with cllr 3.8.13 using the stop-on-prime switch for n=2500-25K. Perhaps you were referring to smaller tests. I will report my timing on it mid-day Tuesday.[/QUOTE]

On Windows the program was terminating abnormally. I haven't heard from Jean on that yet.

I was running Cllr version 3.8.13 on Windows7.

For the aforementioned n=2500-25K test with the stop-on-prime option; total Cllr running time: 9:16

That is 53 minutes longer than PFGW 3.3.6 for the same range, which came in at 8:23. So PFGW is better in this particular situation.

I got stand-alone primegen built and it doesn't miss any primes < 1G. I don't know why the version of primegen that pfgw was using previously missed primes. I will try to implement that into pfgw this weekend.

[QUOTE=rogue;405614]I got stand-alone primegen built and it doesn't miss any primes < 1G. I don't know why the version of primegen that pfgw was using previously missed primes. I will try to implement that into pfgw this weekend.[/QUOTE]

Does this mean that it will actually get wort it, to tes from n=1 to n=25K, using the script only?

Or was that a whole different approach you have to work out?

[QUOTE=KEP;405615]Does this mean that it will actually get wort it, to tes from n=1 to n=25K, using the script only?

Or was that a whole different approach you have to work out?[/QUOTE]

After Mark creates the new PFGW version, my suggestion is to retest everything on your own setup and see what is the fastest method. Currently it appears that sieving is faster on everyone's setup. It is just that on mine using a PFGW version (3.3.6) that had primegen in it, sieving was only slightly faster. I just chose not to mess with sieving because it was only 15-20% faster.

[QUOTE=gd_barnes;405626]After Mark creates the new PFGW version, my suggestion is to retest everything on your own setup and see what is the fastest method. Currently it appears that sieving is faster on everyone's setup. It is just that on mine using a PFGW version (3.3.6) that had primegen in it, sieving was only slightly faster. I just chose not to mess with sieving because it was only 15-20% faster.[/QUOTE]

Great. I'll keep an eye on this thread, because it could appear that starting up bases is not the most optimal at the moment. Do you btw have an ETA for completion of the range 16G-20G?

I've made the changes and so far so good. With primegen it is nearly two times faster than without (both runs using -f10). I won't have results until tomorrow morning. This assumes that my code changes are correct. A lot more testing will be needed to verify the changes.

[QUOTE=rogue;405640]I've made the changes and so far so good. With primegen it is nearly two times faster than without (both runs using -f10). I won't have results until tomorrow morning. This assumes that my code changes are correct. A lot more testing will be needed to verify the changes.[/QUOTE]

Great job Mark. It appears that 1 of my cores will free up on august 7th, so from around that date, if you need some ressources to test your changes, I can lend you a hand :smile: ... I hope though, that it is fully implemented and tested by then, so I can start up new ranges for R3 :smile: