Is it possible that running -f10 or -f5 to 5000 might be faster than -f0 to 5000?
It's nice to see the time cost of the smaller data files earned by running the script to higher n. Nice work!

Mark, just to confirm: All of each test (i.e. script/sieve/test) was done on a single core. Is that correct?

[QUOTE=rogue;405328]If Jean can find and fix the problem with llr, that should improve the speed even more. IMO a 4-core machine should be able to complete a range of 1G in a month.[/QUOTE]

LLR for small tests that we do not collect residues for, does not have very much benefits, even if LLR should be 15% faster than PFGW, LLR will eventually delay due to waiting for writing new result to the excisting resultfile and writing a new LLR.ini file. However I'm glad to see that my results were just confirmed. I expect my Hasswell and also my Sandy Bridge to be able to complete a 1G range faster than 139 days. Simply because sieving and testing for n>2500 to n=7500 and from n>7500 to n=25K doesn't take a total of 80-85 days to complete.

Thanks for your results. Glad that they confirmed what I previously learned about how to run this conjecture the most efficient. With the results you learned Rogue, I expect to be able to complete a 1G range in 75-80 CPU days on my hasswell and 109-120 days on my Sandy Bridge, wich gives a total minimum of 30,416G each year and thereby confirms my previous plan.

Hope you all had a happy 4th of July :smile:

Take care

[QUOTE=VBCurtis;405334]Is it possible that running -f10 or -f5 to 5000 might be faster than -f0 to 5000?[/QUOTE]

No, the trial factoring slows down those tests considerably.

[QUOTE=gd_barnes;405339]Mark, just to confirm: All of each test (i.e. script/sieve/test) was done on a single core. Is that correct?[/QUOTE]

Correct. Each test was running on its own core although there were times that a core wasn't busy.

[QUOTE=KEP;405340]LLR for small tests that we do not collect residues for, does not have very much benefits, even if LLR should be 15% faster than PFGW, LLR will eventually delay due to waiting for writing new result to the excisting resultfile and writing a new LLR.ini file. However I'm glad to see that my results were just confirmed. I expect my Hasswell and also my Sandy Bridge to be able to complete a 1G range faster than 139 days. Simply because sieving and testing for n>2500 to n=7500 and from n>7500 to n=25K doesn't take a total of 80-85 days to complete.

Thanks for your results. Glad that they confirmed what I previously learned about how to run this conjecture the most efficient. With the results you learned Rogue, I expect to be able to complete a 1G range in 75-80 CPU days on my hasswell and 109-120 days on my Sandy Bridge, wich gives a total minimum of 30,416G each year and thereby confirms my previous plan.[/QUOTE]

I suggest that you do the same test using a single core just to compare to my results. That would give you a better estimate. A test of 50M can be completed in well under a day.

[QUOTE=rogue;405345]I suggest that you do the same test using a single core just to compare to my results. That would give you a better estimate. A test of 50M can be completed in well under a day.[/QUOTE]

Well, I'm going to do some tests when I do an official reservation, where I will run a 4G range split over 8 or 10 ranges. Half of these ranges will be done on my Sandy Bridge and the other half will be done on my Hasswell, using PFGW 3.7.9. By completion of the entire 4G range, we will know if I meet the expected result or if I do better or worse :smile:

Thanks for running the tests Mark. I'm happy to be proven incorrect. At some point, I'll have to run the same tests on my older vs. newer machines and see if it's a software or hardware (or both) difference over the last 3+ years that made my tests come out differently.

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.

I am very curious so I am running the range of 30G-30.005G (k=5M range) on my newest machine to n=25K. I am running 4 cores with the following 4 tests:

(1 thru 3) Scripting to n=25K with no sieving. One test each with the following factoring switches:
-f10
-f30
-f50

(4) Scripting to n=2500 with -f0 followed by sieving n=2500-25K and then PFGWing the sieve file.

My machine is vintage 2011. It is in an Intel I7 64-bit with 4 GB ram running Windows 7 at 2.67 Ghz. Yep it's the best and newest that I have. With its 8 cores hyper threading, it is a sieving beast though. lol

I am running what I consider to be the very best version of PFGW for running base 3...version 3.3.6. (Crazy but some later versions seem to run slower on the small primes. Also some had problems with incorrect primes.) I am also running a slightly modified version of the script where I changed it to add 2 to the k each time and stripped out all checks for algebraic factors. I estimate a 1-3% speedup from that.

One caveat when running the script: Be sure and set the output to super quiet. All of the scrolling will slow it down.

I was pretty sure that these were similar tests to when I determined that -f30 was the best factoring for scripting to n=25K. But I can't remember if I tried the sieving test. That is where I may have erred.

It will be interesting to see my timings vs. others much newer software and hardware.

Finally, yeah, some tweaking with sr(x)sieve may speed this up even more.

It would have to be a new sieve. It's just a thought in my head. I don't know if or when I could write it. I'm not 100% convinced that it is doable. I just think it is. I'm sure that someone else on this list could write it as easily as me. I believe that it is something that could be offloaded to a GPU. With such small n, it could be done without a discrete log.

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.

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.

I had previously observed that something changed between the PFGW 3.3.x and PFGW 3.4x (or 3.5x) versions that made it slower for very small tests. That is why I stuck with 3.3.6 for scripting most bases. Newer versions are better for larger tests.

Attached is the slightly modified version of the starting bases script that I am using for base 3 only. It strips out checking for algebraic factors, k's with trivial factors, and increments the k by 2 after completing the test on a previous k. One caveat: Because of this, the minimum k must be an even number.

I will post both Windows and Linux PFGW 3.3.6 after I complete my test. I will be curious if others find the same thing that I did.