We Need Your Help!

In advance of the Alan Turing Year challenge (June 20-23), we are inviting everyone do a little bit of CUDA sieving to help prepare the GFN search for its next steps.

While the Alan Turing Year challenge itself is going to use the short (N=524288) WUs, we need more sieving done on the long (N=4194304) WUs. Fortunately, AXN just wrote a CUDA based sieve that is ridiculously fast. It's so fast that with a little help we should be able to complete the sieve -- to DOUBLE the original goal -- before the challenge starts.

So if you're currently using your GPU(s) to crunch GFN (or anything else) -- especially if you're currently crunching short N=524288 WUs -- please consider switching over to GFN sieving until the challenge starts. Lets save those short WUs for the challenge.

The new sieve program is extremely easy to use, so if you've never done manual sieving before and/or want to get some easy PSA credits, this is the way to do it.

For more information please see the Alan Turing Year Challenge and the Generalized Fermat Number Search.

About the Sieving

Manual PSA credits are available for this sieve.

Within a month, we're going to use up all of the N=4194304 work that's been generated, i.e., all candidates for b < 5000. New work with b starting at 5000 will be generated before that happens.

Work is created from the sieve files. A sieve file is the list of all candidates that have not yet been eliminated by the sieving process. The numbers in the sieve file, therefore, are the numbers that we end up testing with GeneferCUDA and GenefX64. With the new fast CUDA sieve program, we can eliminate candidates from the sieve file over 100 times faster than we can test them with GeneferCUDA, so it's clearly beneficial to do as much sieving as possible.

Currently, the sieve is up to 6000P. (After half a year of sieving on CPUs, it had gotten to about 4000P. That was 7 days ago, when we started using the new CUDA sieve. Now it's at 6000P, after one week.) We need to get to 18446P before generating new work. Given the speed of this sieve, that seems easily attainable with a few more people sieving.

Looking beyond that, there's also sieving to be done at N=524288, N=1048576, and N=2097192. Depending on how many WUs get crunched during the challenge, the next sieving priority after N=4194304 will probably be either N=524288 or N=1048576.

As always, of course, you are free to use your computing resources as you see fit and crunch or sieve whatever you wish.

The sieving itself is coordinated over on the Prime Search Forums. Instructions can be located there, as can lots of help if you need it. You can also ask questions here, of course.

NOTE: By default, the sieve program uses b7 (block size), which gives decent speed and almost no screen lag. Most people prefer to run at b11, which is significantly faster, but does have noticeable lag. It's easy and fast to switch back to b7 when you're doing something on the computer where the lag is intrusive, such as watching video.
____________
My lucky number is 75898⁵²⁴²⁸⁸+1

Nice to see more GPU apps becoming available :)
Just started cranking out factors on my GTX 570. For comparison, the speedometer goes back and forth between 56P/day and 62P/day.

Resourcewise it uses about 80% GPU without causing lag. CPU use is negligible.

*bleep* That's one helluva difference by the way... B11 gives me ~87P/day.

Is this particular page down for maintenance or is it just me.

http://uwin.mine.nu/sieves/gfn/instructions/generalized_fermat_number_prime_gfnsvcuda.htm

Immediate crash on Linux:

Immediate crash on Linux:

gary$ ./GFNSvCUDA-0_3b-linux64 22 6400 6405 B11 GFNSvCUDA v0.3b (c) 2012 Anand Nair (anand.s.nair AT gmail) GFN Sieve for k^4194304+1 [k == 2 to 100000000] Using factor file 'f22_6400P_6405P.txt' Using checkpoint file 'c22_6400P_6405P.txt' Floating point exception gary$

Ubuntu 11.04, nvidia driver 295.53. Tried using both the libcudart.so that was in the .zip and the one I already had on my box. Same result. Tried n=20 and n=22, with different p ranges. No luck; identical failure.

The linux client is completely untested. Only the windows client is operational currently.

So do you have to manually sieve the long tasks or can you use the BOINC client?

I have a Quadro 600 which should be compatible, although it is on a 64 bit OS.

If it is possible to use the BOINC client what settings would I put on it in my preferences tab?

first try with manual sieving.
reserved a 100P range. running smooth with ~85P/day at my non oc gtx580.
could be a little tricky to keep the gpu busy all the time ...

How do you guys keep your gpus loaded?
if i am home and my current range is finished at maybe 2 o'clock in the morning my gpu is idle till the next morning.
Of course i could reserve a new range and start the new range before i go to bed and finish the last range when im home ...

interested to hear some other experiences.
____________

first try with manual sieving.
reserved a 100P range. running smooth with ~85P/day at my non oc gtx580.
could be a little tricky to keep the gpu busy all the time ...

How do you guys keep your gpus loaded?
if i am home and my current range is finished at maybe 2 o'clock in the morning my gpu is idle till the next morning.
Of course i could reserve a new range and start the new range before i go to bed and finish the last range when im home ...

How do you guys keep your gpus loaded?
if i am home and my current range is finished at maybe 2 o'clock in the morning my gpu is idle till the next morning.

first try with manual sieving.
reserved a 100P range. running smooth with ~85P/day at my non oc gtx580.
could be a little tricky to keep the gpu busy all the time ...

How do you guys keep your gpus loaded?

Please, read as suggested in reservation thread, it's all in there.
If using GFNSvCUDA (GPU), please visit the Generalized Fermat Prime Search (GPU Sieving) page for instructions.

Try to leave single CPU core free for GFN sieving, others can run BOINC.
____________
My stats

I'm not sure what range I should reserve and in the guide there was the suggestion of using "22 4000 4100". What does the 22 stand for?

N=4194304, 8100P-8200P Michael_Goetz

N=4194304, 8100P-8200P Michael_Goetz COMPLETE

How do I change it so I get less screenlag when I'm using the computer?

And lastly, is it ok close the command window and it will resume where I was?

Also, would it be unwise to leave BOINC running aswell while doing the sieving (and then just keep it only crunching on CPUs)?

I have put both of my GPU to work here for some nice and easy PSA credit :) We'll see how much work they can complete at 60P/day before the challenge... (I will be crunching shorter intervals, so there may be some down time while I am asleep or at work)
____________

Running on a GTX470 @65P/day (B10 setting), which keeps the GPU happy with 88% load.
Is it just me, or are there a lot of factor is the search range?
Something like 50 factors for every 0.5P ?

Good explanation on those factors found, thanks Michael!

Seeing how many factors are discovered, but a relatively low number (<1%) actually does anything, would it not save a lot of resources if a dat-file was used?

The sieve algorithm is such that the computation is independent of both the range of candidates (b=2 to 100,000,000) as well as the actual list of candidates (27,462,822) that would be there in a dat file. This is true of both the CUDA version as well as CPU version (AthGfnXXX). The only thing a dat file achieves is to limit the factor output to only those candidates that you're interested. It doesn't affect the speed of the program (one way or the other).

The 5300 numbers that you're processing per second are the potential (prime) factors that the program is testing against these candidates (b=2 to 100,000,000). And no, the program doesn't test each of them one by one against all the candidates -- remember the part where 'computation is independent of candidates'?

Bottom line -- dat-file means less redundant factors, but no speed difference.

Those who are of a mathematical persuasion might peruse http://fatphil.org/maths/GFN/maths.html

Exactly. Honza and I resieved n=1048576 from 0P to 1130P using AthGfn64 after an early problem left the factor file missing 935,075 entries. During resieving we used a factor file containing only those entries. Speed was not affected at all. All numbers in the range were still tested, but only those appearing in the sieve were actually output.

The only change I made with the dat-less sieving was to add columns to the GFN Sieve Status page. One set lists raw factors found and their density, the other one lists factors newly removed from the sieve and that density. Dat-less sieving affected the first two of those, but not the last two.

Just a practical question before I'm going to reserve some more P's for sieving. How badly do you want it to be done before the challenge? I.e. would you prefer me to reserve an amount that will most certainly be done before the challenge starts (but leave my GPU unused for some time) or is it also ok if it'll take a couple more hours of computing after the challenge?

Since the CW sieve has been completed for now, would it be possible to bring GFN sieve to BOINC? Some time ago it was quite popular, but now with the new n=20 genefer tasks/challenge people have lost interest. Maybe with a new BOINC project/badge people will renew their interest. And let us not forget the Keplar GPUs are more efficient at sieving than at Genefer.

What I found in the GFN sieve discussion: http://primesearchteam.com/showthread.php?t=40&page=17
Optimal sieve point for n=20 is ~ 100E (100,000P), currently sieved to 26,000P
Optimal sieve point for n=21 is ~ 400E (400,000P), currently sieved to 20,200P
Optimal sieve point for n=22 is ~ 1000E (=1,000,000P), currently sieved to 41,300P

So about 74E + 380E + 959E = 1413E is still needed to reach optimal sieve depth for these N's , while only 87E has been completed so far. To put that in perspective, that is more than 5000 million BOINC credits worth left to sieve.

April 2015 update:
n=20 sieved to 37,400P, ultimate goal 100,000P, 37.4% sieved to optimal level, sieve suspended
n=21 sieved to 44,600P, ultimate goal 400,000P, 11.1% sieved to optimal level, current goal 50,000P
n=22 sieved to 105,200P, ultimate goal 1,000,000P, 10.5% sieved to optimal level, current goal 120,000P

So about 62,600 + 355,400 + 894,800 = 1,312,800P still needed to reach optimal sieve depth, while 187,200P has been completed so far.

April 2015 update:
n=20 sieved to 37,400P, ultimate goal 100,000P, 37.4% sieved to optimal level, sieve suspended
n=21 sieved to 44,600P, ultimate goal 400,000P, 11.1% sieved to optimal level, current goal 50,000P
n=22 sieved to 105,200P, ultimate goal 1,000,000P, 10.5% sieved to optimal level, current goal 120,000P

So about 62,600 + 355,400 + 894,800 = 1,312,800P still needed to reach optimal sieve depth, while 187,200P has been completed so far.

Okay so, now that OCL4 can do up to 400.000.000 B on any range.... shouldn't we change the sieving program to add those candidates as well? Or does that go beyond the sieve algorithm?

Okay so, now that OCL4 can do up to 400.000.000 B on any range.... shouldn't we change the sieving program to add those candidates as well? Or does that go beyond the sieve algorithm?

Okay so, now that OCL4 can do up to 400.000.000 B on any range.... shouldn't we change the sieving program to add those candidates as well? Or does that go beyond the sieve algorithm?

Okay so, now that OCL4 can do up to 400.000.000 B on any range.... shouldn't we change the sieving program to add those candidates as well? Or does that go beyond the sieve algorithm?

This puts us in a somewhat similar (but not identical) situation with GFN as we've always been with LLR. All the sieves for LLR projects have an upper limit. That limit is based not upon the absolute upper limit of the capability of the LLR program, but upon which numbers we expect to be testing in the foreseeable future.

The new abilities of the OCL4 program put us in a similar situation with GFN. It used to be that sieving to 100M was absolutely sufficient because not only did we not expect to ever search that high, but there was no version of genefer that could even test numbers beyond b=100M.

Now we have a GPU version of Genefer that can go higher. But will we ever need it? It's unlikely that we'll see n=17 or above ever get above 100M, or anywhere close to it. 15, and to a lesser degree 16, could possibly get that high after quite a few years. In theory. Remember, however, that there's no CPU version of Genefer that can go that high -- the CPU version of Genefer's limits, with the x87 transform, are similar to the OCL2 limits. For part of the push to 100M, therefore, it would be just GPUs doing the work. And that's assuming we want to run a GPU-only project, which is something we prefer not to do.

The bottom line is that just because OCL4 can test numbers up to 400M doesn't imply we need to sieve that high, and there's certainly no urgency about it. I don't expect us to ever need a sieve file b>100M for anything other than n=15 and maybe n=16. N=15 isn't currently being sieved, so the only sieve currently running where we would even theoretically be able to use those factors is n=16. That need is a long, long way off.

But if it really comes at no cost, might as well do it....

We're approaching the 120,000P sieving limit for n=22. Is it going to be increased?

Just wondering a few things:

1- To do sieving on n=13 for external testing, I had to use AthGfn64. And it got me thinking: couldn't we use it to allow manual sieve on the CPU?
2- Why is the CUDA app limited to n>= 15? Why can't it do 14 and below?
3- Can we add an "optimal sieve depth" field somewhere? Whether it be on the stats page or reservation page, or anywhere else, it would be pretty nice to know.

Just wondering a few things:

1- To do sieving on n=13 for external testing, I had to use AthGfn64. And it got me thinking: couldn't we use it to allow manual sieve on the CPU?
2- Why is the CUDA app limited to n>= 15? Why can't it do 14 and below?

3- Can we add an "optimal sieve depth" field somewhere? Whether it be on the stats page or reservation page, or anywhere else, it would be pretty nice to know.

We're not testing n<15.

And the lower the n, the slower the GFN sieve runs. I'm not sure it's worth using a GPU there. Also, I don't believe the algorithm used has been tested at those n's.

Plus, some time in the week or so we're coming out with 64-bit GFN sieving program for both CUDA and OpenCL under both Windows and Linux. The 64-bit code has a pretty decent speed advantage over the 32-bit plus it has an option to use a lot less CPU for higher n's. That would render any current optimal point obsolete. I might possibly recalculate the optimal sieving depth after that.

It's not even a matter of "being worth it" or not, it's straight up "the program doesn't work at that range".That's why I'm asking: why?

.... but it's still GPU software, people would need graphics cards to run it. AthGFNsv, on the other hand, is a CPU program, which feels the gap. That was the actual point of the question: COULD we use that for, say, n=16?

Putting it other words, if reserved a range and ran it with the CPU program instead of the GPU app, would it work (much like I can run "amd genefer OCL" on an Intel GPU, as the output is the exact same)?

Plus, some time in the week or so we're coming out with 64-bit GFN sieving program for both CUDA and OpenCL under both Windows and Linux. The 64-bit code has a pretty decent speed advantage over the 32-bit plus it has an option to use a lot less CPU for higher n's. That would render any current optimal point obsolete. I might possibly recalculate the optimal sieving depth after that.

I returned a n=22 factor file for range 122667P-122867P. The factor file had 1808 factors, but the results table shows 1807 factors found. Why the difference? Usually they"re the same. The only difference that I noticed in the factors for this range was that one factor (2962) is unusually small (<10000). Maybe small factors aren't counted?

Plus, some time in the week or so we're coming out with 64-bit GFN sieving program for both CUDA and OpenCL under both Windows and Linux. The 64-bit code has a pretty decent speed advantage over the 32-bit plus it has an option to use a lot less CPU for higher n's. That would render any current optimal point obsolete. I might possibly recalculate the optimal sieving depth after that.

Plus, some time in the week or so we're coming out with 64-bit GFN sieving program for both CUDA and OpenCL under both Windows and Linux. The 64-bit code has a pretty decent speed advantage over the 32-bit plus it has an option to use a lot less CPU for higher n's. That would render any current optimal point obsolete. I might possibly recalculate the optimal sieving depth after that.

So, I've just randomly remembered about this... obviously it has been more than a week. Any news / ETA?