Jim,

A very sincere and heartfelt thanks for being so quick in confirming and assigning pending credit with PPR12M each and every time we return our results!!!

Jim,

A very sincere and heartfelt thanks for being so quick in confirming and assigning pending credit with PPR12M each and every time we return our results!!!

Jim,

Do you have access to any stats in relation to GPU and performance (minimum turnaround time)?

I am looking at a custom build and I would like to begin with the GPU and proceed accordingly.

I'm not the author of any of that code. I believe a simple change would make the GFNSvCUDA report factors for up to b=400M, but I'm not certain. The only n's it could possibly apply to are 15 and 16. We won't ever get high enough in the others. Even for n=15 we're talking about a few years before we run out of candidates. We're not currently sieving n=15 and given that it's only sieved to 1100P it wouldn't take long to redo for b=0-400M.

Would it even be necessary to redo anything? Couldn't you just add in sieve entries 100 - 400M, and then start sieving from the current P for b = 0-400M? It would seen a waste to redo anything since factors are usually found multiple times during sieving.

The factor density at the beginning of sieving is very very high. Have a look at http://www.primegrid.com/sieving/gfn and see just how high. Sieving would have to be redone starting at p=0. In fact between p=0-1P the GPU programs can't be used. I'll have to check the older Windows code from David Underbakke to make sure his b limits go that high.

OK, so you might redo 0-1P. But to redo everything seems such a waste. Currently, we're almost at 12% of the optimal sieving range. That means we still have 7 times as much work remaining to do. Since each factor is likely to be found multiple times over the sieving range, it just seems a lot of rerun work to eliminate a few factors that MIGHT not be eliminated in the remaining 88% work to do.

Current GPU work is low in the OCL/OLC3 range. Any sieving we do is better focused on NEW sieving ranges to eliminate new OCL/OCL3/OCL2 factors than to redo everything, and find ZERO new OCL/OCL3/OCL2 factors.

You're kidding, right? We're talking about sieving up to a higher b-limit rather than stopping at b=100M like now. A quicy-and-dirty calculation suggests that resieving 0-1100P to b=1G will result in 388 million additional candidates being sieved out. That's because there will be ten times the potential candidates that there are now. Candidates that were not found the first time because anything over 100M was not reported. Candidates that we'll start primality-testing within two years.

Look at the graph here and think about it going from b=100,000,000 in height (which it is now) to ten times that high or b=1,000,000,000. That's where the additional candidates come from. So we stand to discover 9x (1G - 100M = 900M) as many new factors for any sieving range. In fact we might as well sieve to the limit of the program, which is 2^32-2 or 4,294,967,294. It'll take exactly the same time as sieving to 100M did, the factor files will just be that much larger. The sieve files will also be larger, but that's something that only exists on my computer. A 5GB sieve file (uncompressed) is not all that large. I have 500GB+ of various generations of PPS/RSP sieves here for n=0-12M, with two full backups on other computers.

We're not talking about redoing n=22. We're talking about redoing n=15.