Join PrimeGrid
Returning Participants
Community
Leader Boards
Results
Other
drummerslowrise

Message boards :
Generalized Fermat Prime Search :
Guessing the future of GFN22 and DYFL
Author 
Message 

Here is a tough bet: Which will happen first:
 GFN22 reaches the starting point (b = 846'396.7) of DYFL, likely without finding any GFN22 primes, and the two 22subprojects merge
 Someone outside PrimeGrid, likely GIMPS, finds a new world record prime, and DYFL jumps to that new position (resulting in two "holes")
And when?
/JeppeSN  


no.2, July 2021
____________
My lucky number is 6219*2^3374198+1
 

Michael GoetzVolunteer moderator Project administrator
Send message
Joined: 21 Jan 10 Posts: 14011 ID: 53948 Credit: 433,244,369 RAC: 880,036

Here is a tough bet: Which will happen first:
 GFN22 reaches the starting point (b = 846'396.7) of DYFL, likely without finding any GFN22 primes, and the two 22subprojects merge
 Someone outside PrimeGrid, likely GIMPS, finds a new world record prime, and DYFL jumps to that new position (resulting in two "holes")
And when?
/JeppeSN
Almost certainly #2 is going to happen first. GFN22's leading edge took nearly 9 years to get to where it is now at 187K, and it's over three times as far to go to get to the start of DYFL. Additionally, it will exceed both the OCL and OCL4 limits before then, so the tasks will slow down.
GIMPS has been finding new world records every few years, so unless they hit a huge dry patch in Mersenne primes, they'll probably find a new prime decades before GFN22 ends.
____________
My lucky number is 75898^{524288}+1  


Given that a 3090 can run GFN22 in about 14 hrs, but DYFL will run in about 15.5 hrs, which sub project would you choose and which is more "likely" to have a chance of a prime, however remote?
____________
 

RafaelVolunteer tester
Send message
Joined: 22 Oct 14 Posts: 911 ID: 370496 Credit: 551,073,077 RAC: 450,327

Given that a 3090 can run GFN22 in about 14 hrs, but DYFL will run in about 15.5 hrs, which sub project would you choose and which is more "likely" to have a chance of a prime, however remote?
The lower the number, the higher the likelyhood of it being prime, so if you're only looking for A gfn22 prime, don't run DYFL.
With that said, you might as well look for a WR and have a shot at the cash reward / fame, or tone it down and look for the first GFN21 known to man instead.  

GDBSend message
Joined: 15 Nov 11 Posts: 298 ID: 119185 Credit: 4,065,051,142 RAC: 1,956,540

I still think GFN22 is undersieved. I was removing a GFN22 factor every 72 seconds. That's about 1200 times faster than running GFN22.
____________
 


the cash reward
I do not think you will earn a cash reward for beating the world record, here at PrimeGrid.
GIMPS got a cash prize when they found the first croreprime (10'000'000digit prime), and might also find the first 100'000'000digit prime in the distant future. I think GIMPS uses some of this money to give a cash reward to finders. PrimeGrid does not have that.
/JeppeSN  

FrankSend message
Joined: 30 Dec 17 Posts: 27 ID: 964965 Credit: 480,582,336 RAC: 807,370

Sounds interesting GDB, just two questions:
1) Which sieving range (in P) were you checking? 2) And how do you have the full set of bvalues that we are going to check within Primegrid?  


I still think GFN22 is undersieved. I was removing a GFN22 factor every 72 seconds. That's about 1200 times faster than running GFN22.
Just because the sieve program finds a factor doesnâ€™t mean it is removing a candidate. The candidate could have already been removed earlier in the sieve. Itâ€™s also relatively moot if it is a candidate that will realistically not be primality tested anytime soon.
____________
 

GDBSend message
Joined: 15 Nov 11 Posts: 298 ID: 119185 Credit: 4,065,051,142 RAC: 1,956,540

I still think GFN22 is undersieved. I was removing a GFN22 factor every 72 seconds. That's about 1200 times faster than running GFN22.
Just because the sieve program finds a factor doesnâ€™t mean it is removing a candidate. The candidate could have already been removed earlier in the sieve. Itâ€™s also relatively moot if it is a candidate that will realistically not be primality tested anytime soon.
When I said that I was finding a factor every 72 seconds, I was meaning factors that ONLY removed candidates.
What's driving the lack of sieving is someone's definition of "soon". Rather than waste my GPU time running one in ten million GFN22 crapshoots, I'd prefer to use my GPUs to remove millions of candidates.
And I mean MILLIONS. With only my sieving, I could remove 2 million candidates in 5 years. 500 people running GFN22 for 5 years would only remove 500,000 candidates.
____________
 

streamVolunteer moderator Project administrator Volunteer developer Volunteer tester Send message
Joined: 1 Mar 14 Posts: 1033 ID: 301928 Credit: 543,624,271 RAC: 6,563

What is sieving speed of your GPU (P/day) ?
 

GDBSend message
Joined: 15 Nov 11 Posts: 298 ID: 119185 Credit: 4,065,051,142 RAC: 1,956,540

What is sieving speed of your GPU (P/day) ?
With my 2 1080s and 2060, I was doing 800 P per day for n=22 manual sieving.
At a removal rate of 1.5 candidates per P, I was removing 1200 candidates per day.
____________
 

streamVolunteer moderator Project administrator Volunteer developer Volunteer tester Send message
Joined: 1 Mar 14 Posts: 1033 ID: 301928 Credit: 543,624,271 RAC: 6,563

What is sieving speed of your GPU (P/day) ?
With my 2 1080s and 2060, I was doing 800 P per day for n=22 manual sieving.
At a removal rate of 1.5 candidates per P, I was removing 1200 candidates per day.
OK. You're sieving 800 P/day. You see that lot of factors were found.
Question #1. How many of these factors are really removing a candidate (i.e. candidate wasn't removed earlier by smaller factors)?
Yves has formulas for everything related to GFN. He also has a formula to calculate number of candidates left at given sieving depth and range. Current GFN22 sieving depth is 1100000P and range is 2G. How many candidates will be removed between 1100000P and 1100000+800P ? Put both depths to formula and find a difference. The answer is (you have to trust my word) 6055.
Question #2. How many of these 6055 factors are useful to us?
There is a problem with candidates located too far from our current position in search. Sieving can find these factors "for free", up to 2G, but why  if we'll need, for example, 100 years to reach this range?
So we use 5 years prediction for "usable" range, based on progress for few last years. And the sad truth is that prediction (advance of 'b') for GFN22 is only 245000!
You removed 6055 from 2G range. How may candidates are within 245K range?
6055 * 245000 / 2000000000 = 0,7417375
Multiply by two due to DC tasks. So, your whole day of sieving on 3 GPUs saved only 1,5 useful (within next 5 years) tasks.
What is duration of real tasks on these GPUs?  

GDBSend message
Joined: 15 Nov 11 Posts: 298 ID: 119185 Credit: 4,065,051,142 RAC: 1,956,540

What is sieving speed of your GPU (P/day) ?
With my 2 1080s and 2060, I was doing 800 P per day for n=22 manual sieving.
At a removal rate of 1.5 candidates per P, I was removing 1200 candidates per day.
OK. You're sieving 800 P/day. You see that lot of factors were found.
Question #1. How many of these factors are really removing a candidate (i.e. candidate wasn't removed earlier by smaller factors)?
Yves has formulas for everything related to GFN. He also has a formula to calculate number of candidates left at given sieving depth and range. Current GFN22 sieving depth is 1100000P and range is 2G. How many candidates will be removed between 1100000P and 1100000+800P ? Put both depths to formula and find a difference. The answer is (you have to trust my word) 6055.
Question #2. How many of these 6055 factors are useful to us?
There is a problem with candidates located too far from our current position in search. Sieving can find these factors "for free", up to 2G, but why  if we'll need, for example, 100 years to reach this range?
So we use 5 years prediction for "usable" range, based on progress for few last years. And the sad truth is that prediction (advance of 'b') for GFN22 is only 245000!
You removed 6055 from 2G range. How may candidates are within 245K range?
6055 * 245000 / 2000000000 = 0,7417375
Multiply by two due to DC tasks. So, your whole day of sieving on 3 GPUs saved only 1,5 useful (within next 5 years) tasks.
What is duration of real tasks on these GPUs?
If you go to manual sieving, and click on "show stats", it shows stats for all GFN manual sieving. Go to GFN n=22, and click "+" to expand all GFN n=22 stats. Go all of the way to the end of n=22 stats.
User walli shows up last doing 600P jobs, and removes from the sieve about 900 candidates for each job. That's 1.5 candidates removed per P.
It also shows factors found as about 3.8. That means 1.5 candidates removed per P divided by 3.8 factors found = about 40% of factors found result in a candidate removal.
Obviously as you sieve more, the % of factors resulting in a candidate removal will slowly decrease.
As to your question #1, from actual sieve job stats near your range, 800P at 1.5 candidates removed per P = 1200 candidates removed per day, not your 6055.
As to your question #2, your usable range of 245,000 is way too small. Forget about DYFL?
DYFL is already to 925,000 for GFN22. And if a World record GIMP is found, DYFL probably will be bumped. So a much more reasonable 5 year range is 2,000,000.
So, 1200 * 2,000,000 / 2,000,000,000 = 1.2 * 2 (for DC tasks) = 2.4 useful candidates removed per day via manual sieving. Along with the equivalent of 2,400 other candidates removed from sieve.
It seems such a waste of GPU resources to me to remove 1 GFN22 candidate per day instead of 1200 via manual sieving.
____________
 

streamVolunteer moderator Project administrator Volunteer developer Volunteer tester Send message
Joined: 1 Mar 14 Posts: 1033 ID: 301928 Credit: 543,624,271 RAC: 6,563

As to your question #1, from actual sieve job stats near your range, 800P at 1.5 candidates removed per P = 1200 candidates removed per day, not your 6055.
Manual sieving stats are rescaled to 400M sieving range. Sieving was started on 400M range and lately resieved to 2G, but Jim decided to keep all graph and stats in "old style" to simplify coding.
1200 candidates removed in 400M range are equal to 6000 candidates removed in 2G range. Your numbers matches my numbers exactly.
As to your question #2, your usable range of 245,000 is way too small.
As any prediction, it may be wrong, but it's based on facts about our throughput on each GFN project.
I recalculated predictions using current data.
20191020, GFN22 leading edge was 159180.
20210104, GFN22 leading edge is 188590
For more then a year. 'b' was advanced only by 29410 !
The prediction model is exponential, it considers that throughput in every year will be faster by 30% then previous one. After applying the formula, we'll get that in next 5 years leading edge of GFN22 will be advanced by 285,5K  it's a bit better then our previous estimation of 245K, but not much. Expected leading edge in 2026 will be 474K. (This is mostly an answer for first post in this thread  GFN22 is still on a looong way to meet DYFL).
Forget about DYFL?
DYFL is already to 925,000 for GFN22. And if a World record GIMP is found, DYFL probably will be bumped. So a much more reasonable 5 year range is 2,000,000.
Well... You're partially correct here.
You're absolutely wrong about "bumping". It's not working this way. It does not matter how far we bump starting point. We can start from anywhere, it'll not change number of usable candidates. What matter is how many candidates we test per year (and how far 'b' advances "naturally", by removing tested candidates).
You're right about... that we really forgot about DYFL! Candidates tested by DYFL were not included in our calculation of "usable ranges", although these two numbers should be summed up.
A prediction on DYFL is much better then on GFN22. It may be advanced by 404K in 5 years. Summing this usable range with 285,5K from main search and rescaling number of factors to this sum, we'll have much better results  your system removes 2,09 usable candidates per day.
Now I'm asking once again: what are runtimes of real GFN22/DYFL tasks on your GPUs? When I'll know runtimes, I can calculate how efficient sieve will be and how far it should go to stay efficient in your setup.
 


Now I'm asking once again: what are runtimes of real GFN22/DYFL tasks on your GPUs? When I'll know runtimes, I can calculate how efficient sieve will be and how far it should go to stay efficient in your setup.
The last line of his latest post may mean that the Genefer runtime is about a day. /JeppeSN  

GDBSend message
Joined: 15 Nov 11 Posts: 298 ID: 119185 Credit: 4,065,051,142 RAC: 1,956,540

To get specific current timing for each GPU, I'll need to run small manual GFN22 sieve on each. Do you want the time for a GFN22 and/or DYFL for each card?
____________
 

Michael GoetzVolunteer moderator Project administrator
Send message
Joined: 21 Jan 10 Posts: 14011 ID: 53948 Credit: 433,244,369 RAC: 880,036

Now I'm asking once again: what are runtimes of real GFN22/DYFL tasks on your GPUs? When I'll know runtimes, I can calculate how efficient sieve will be and how far it should go to stay efficient in your setup.
The last line of his latest post may mean that the Genefer runtime is about a day. /JeppeSN
Need to know *which* GFN you're talking about. DYFL uses a slower transform than GFN22, so it takes about 25% longer to run.
____________
My lucky number is 75898^{524288}+1  

GDBSend message
Joined: 15 Nov 11 Posts: 298 ID: 119185 Credit: 4,065,051,142 RAC: 1,956,540

Now I'm asking once again: what are runtimes of real GFN22/DYFL tasks on your GPUs? When I'll know runtimes, I can calculate how efficient sieve will be and how far it should go to stay efficient in your setup.
The last line of his latest post may mean that the Genefer runtime is about a day. /JeppeSN
Need to know *which* GFN you're talking about. DYFL uses a slower transform than GFN22, so it takes about 25% longer to run.
So, my question is do I run GFN22 and/or DYFL for each card?
____________
 

streamVolunteer moderator Project administrator Volunteer developer Volunteer tester Send message
Joined: 1 Mar 14 Posts: 1033 ID: 301928 Credit: 543,624,271 RAC: 6,563

So, my question is do I run GFN22 and/or DYFL for each card?
Yes please. As Mike noticed, both GFN22 and DYFL must be tested because they're using different transforms.
If you're familiar with command line, it may be simpler to run tests manually, using, for example, candidates from current leading edges:
188626^4194304+1
925078^4194304+1
No need to run full test  after 23 minutes, Genefer will print "estimated time for ...". Write down the time, you can abort test at this point. I found one DYFL task in your results, Genefer' estimate was 54 hours and real runtime was 55 hours. Such precision will be enough.
If you're not familiar with command line, you can run tasks in Boinc and abort them after 5 minutes. We will see estimated runtime in stderr output of your tasks.
 

Message boards :
Generalized Fermat Prime Search :
Guessing the future of GFN22 and DYFL 