Greetings All,

After reading the answers to my recent questions regarding GFN primes and looking at the data analysis provided by Yves for the GFN-13 search, my interest was piqued and I started to look further into the conjecture on Yves' site (http://yves.gallot.pagesperso-orange.fr/primes/stat.htm). I had used the calculator on that page in the past but had not paid much attention to the table Yves posted below it showing the status of the lower GFNs. For GFN2 through GFN12 the maximum b value listed wasn't all that high compared to what I thought possible with newer computers and looking around I couldn't find anywhere that had definitely tested these to a higher b value than was indicated in the table, so I figured that they may have fallen through the cracks into a gap where they were not tested at the time due to lack of available computing power, but now that we have the computing power they are no longer "interesting" to test. There is a forum post from 2009 (http://www.primegrid.com/forum_thread.php?id=1528) which indicates that GFNs 1-4 may have been tested to b=1G and that GFNs 5-12 may have been tested to b=100M, but I could not find the results of that testing and the results are not indicated on the GFN Prime Search Status and History page (http://www.primegrid.com/gfn_history.php) so, in the spirit of Tour de Primes, I decided to embark on my own primes adventure and take GFNs 1-12 to a much higher b value (2G), make the results available, and also to see how well the predicted numbers of primes match the actual numbers.

What I thought would be a relatively quick and simple task proved to be much bigger than anticipated and is certainly still a work in progress, but I figured with GFN6 and GFN7 complete to b=2,000,000,000 and the rest of 1-8 between 40% and 90% complete I would post the GFN6 and GFN7 results with a comparison between predicted and actual prime counts. Everything below is a single-pass over the data tested with LLR (and sieved with AthGfnSv and AthGfn64 v.B306). All primes listed by Yves were found for GFNs 2-7 in my search (I haven't checked 1 and 8 yet), and it appears that none were missed by his search as I have found none not previously listed. It is my plan to update this post with the same data for each of the other GFN n values as the testing is completed. Lists of prime b values for each GFN are available at the link under each table.

The results:

If you are sure your lists are absolutely correct (they do not want sporadic errors (false positives or omissions)), you could add larger b-files to A006316 and A056994. They have "Table of n, a(n) for n=1..1000" right now, in a specific simple format. That could be 1..100000 or similar. /JeppeSN

If you are sure your lists are absolutely correct (they do not want sporadic errors (false positives or omissions)), you could add larger b-files to A006316 and A056994. They have "Table of n, a(n) for n=1..1000" right now, in a specific simple format. That could be 1..100000 or similar. /JeppeSN

Ill give you a hand Kellen, this sonds like fun :)

Ill give you a hand Kellen, this sonds like fun :)

Awesome, thanks Rob! Any files you want from me to do this or you just gonna go for it right from the start for a total DC of everything, sieve included? GFN6 was sieved to 250T and GFN7 was sieved to 500T. It will almost certainly take me longer to upload the factor or candidates files that it did to generate them, but if you do want them, just let me know :)

Also; fun-ness (apparently not a word) enjoyment and fun are two things that I do have 100% confidence in with this. It has been quite the adventure so far!

Yep total DC. I'll probably break your heart with questions mind you ;) so beee prepared ;D

Oh! And one more thing! You will have to add back the low b values for GFN1-4 that get removed by sieving. Some of them are small enough that the sieve removes them even though they are valid candidates and primes ;)

Hi Stream,

Many thanks for your summary!

Are you aware of a problem that AthGfnSv is buggy when b > 1G, and AthGfnSv64 is buggy at low p values? Me and Jim both had wrote own trivial programs which do initial sieving at dangerous area (low p values). Next, AthGfnSv64 could be used.

Usually we do postprocess factor files and removing candidates from the list manually. This procedure also includes check that factor really divides a candidate (it's a very simple powmod() and could be implemented even in scripted language). In this case, you don't need to double-check sieve. It's guaranteed that you'll not erroneously remove a candidate. Even if you've missed some factors - it's not a problem, just few more basic tests but nothing critical.

GFN-11,12 and probably 10 could be unbeatable with your limits. We're running GFN-13 for few years already, and running it on GPUs up to b = 400M. Considering that Genefer processing speed changes 2x-3x on each step (depending on overhead), GFN-12 is definitely a no-way for a single person, and probably should be limited to Genefer range (b < 400M).

I was just having a bit of a think about this and GFN1 has a property that none of the other GFNs have that makes sieving almost unnecessary. Every b value ending in '2' or '8' for GFN1 will result in a multiple of 5, so they can just be discarded with no further work (well, except for b=2). If this is true then 400 million candidates can be easily eliminated without any formal sieving effort.

Are there any other similar and very easy/straightforward rules that can be applied to filter out candidates for the low n value sieves? I can generate a file containing all candidates and then apply simple rules to delete them, but it has to be as simple as "ending in 8" or "ending in 26".

Me and Jim both had wrote own trivial programs which do initial sieving at dangerous area (low p values). Next, AthGfnSv64 could be used.

b values ending in 1, 3, 5, 7, and 9 will result in a multiple of 2, so they can just be discarded with no further work (well, except for b=1).

This rule with 2 (odd/even) works for all n (all GFNn).

Your rule with 5 is not relevant for higher n. Modulo 5, a fourth power is congruent to either 1 (invertible) or 0. So adding one, the expression b^4+1 will be either 2 or 1 modulo 5, so never divisible by 5.

Another way of seeing it is that for n≥2 the divisors must have the form k*2^{2+1} + 1, or 8k+1. And 5 does not have the form 8k+1.

/JeppeSN

b values ending in 1, 3, 5, 7, and 9 will result in a multiple of 2, so they can just be discarded with no further work (well, except for b=1).

This rule with 2 (odd/even) works for all n (all GFNn).

Your rule with 5 is not relevant for higher n. Modulo 5, a fourth power is congruent to either 1 (invertible) or 0. So adding one, the expression b^4+1 will be either 2 or 1 modulo 5, so never divisible by 5.

Another way of seeing it is that for n≥2 the divisors must have the form k*2^{2+1} + 1, or 8k+1. And 5 does not have the form 8k+1.

/JeppeSN

Hi Kellen,

don't sieve small n, a simple Pari-gp program is able to generate small GFN primes more quickly than a sieve:

cnt = 0; forstep (b = 2, 2000000000, 2, p = b^2+1; c = Mod(2, p)^(p-1); if (c == 1, if (isprime(p), cnt++; print(cnt, " ", b))); );

Yves

Hi Kellen,

don't sieve small n, a simple Pari-gp program is able to generate small GFN primes more quickly than a sieve:

cnt = 0; forstep (b = 2, 2000000000, 2, p = b^2+1; c = Mod(2, p)^(p-1); if (c == 1, if (isprime(p), cnt++; print(cnt, " ", b))); );

Yves

PARI/GP will never give wrong result, even with high n and b values. But it will be slow. You can use ispseudoprime instead of isprime, and that will be faster at verifying the PRPs. But with a theoretical probability that it will report a composite number as "prime". But that would be a sensation. No examples are known.

You can use ispseudoprime alone: cnt = 0; forstep(b = 2, 2000, 2, if(ispseudoprime(b^128+1), cnt++; print(cnt, " ", b)))

Of course that is silly when we know p has a form where we can do a fast deterministic test.

You can also use the 2-PRP test alone and leave it to genefer or another program to verify the candidates: cnt = 0; forstep(b = 2, 2000, 2, p = b^128+1; c = Mod(2, p)^(p-1); if(c == 1, cnt++; print(cnt, " ", b)))

You can change to 3-PRP (c = Mod(3, p)^(p-1)) if you are annoyed by the composite Fermat numbers appearing in the output.

/JeppeSN

Of course, to test 54^2 + 1, you sieve with primes of the form p = 4*x + 1, as said already, and you can stop at the square root of the candidate, i.e. at 54 in this case. So you would check p = 5, 13, 17, 29, 37, 41, 53, and if none of them divides 54^2 + 1, then 54^2 + 1 is a prime (primality test by exhaustive trial division).

So I do not know if you can write the sieve program such that it starts sieving candidates for divisibility by p, only from candidates exceeding p^2.

Of course, you could also just insert an extra check just before the divisor is output to check if that divisor is proper or improper (equal to the candidate).

(For comparison, with a candidate 54^1024 + 1, the prime form is p = 2048*x + 1, so you check p = 12289, 18433, 40961, 59393, 61441, . . ., but you would have to check to 54^512 or 10^887 to be "finished", and of course it is not practically possible.)

/JeppeSN

Thanks for your comments everyone!

You can use ispseudoprime alone: cnt = 0; forstep(b = 2, 2000, 2, if(ispseudoprime(b^128+1), cnt++; print(cnt, " ", b)))

I shall look into the code of genefer and write a version dedicated to "small" n. It must be able to test several candidates at the same time and bmax can easily be extended to 2³¹.

this problem exists from GFN-1 to GFN-5 only. Even in GFN-6, first candidate to test is 2^64+1, which is about 18446P - much higher then any reasonable factor (sieving limit) for GFN-6. On GFN-7 and above, even first candidate (2^128+1) = 3,4e38. It exceeds any possible factor by many orders, making this situation (candidate is equal to factor) impossible.

It's correct. Note that output is not some pseudo-primes but some primes because of the if (isprime(p) test.

The GTX 1080 Ti is a 3584-core GPU. On Pascal, the latency of an instruction is 6 cycles. Then we must be able to execute 6*3584 = 21504 independent instructions at the same time. The implementation of genefer uses a base b representation of numbers: the size of b¹⁰²⁴+1 is 1024 words, it is not sufficient to get 100% core utilization.

Yes, the idea is to test 16 or 32 numbers concurrently.

Me and Jim both had wrote own trivial programs which do initial sieving at dangerous area (low p values). Next, AthGfnSv64 could be used.

Usually we do postprocess factor files and removing candidates from the list manually. This procedure also includes check that factor really divides a candidate (it's a very simple powmod() and could be implemented even in scripted language). In this case, you don't need to double-check sieve. It's guaranteed that you'll not erroneously remove a candidate. Even if you've missed some factors - it's not a problem, just few more basic tests but nothing critical.

The file below should be sieving the b range from 2-100M up to p=~1,000,000 for GFN8 and outputting the factors and b values to a text file. It seems to be doing this just fine, but if anyone notices anything strange about it, please let me know.

forstep (x = 1, 1954, 1, y=x*512+1; if (isprime(y), forstep (b = 2, 100000000, 2, p=b^256+1; c=(Mod(p,y)); if(c==0, write("GFN8Factors0-100M_1M.txt", y," | ",b)))));

The file below should be sieving the b range from 2-100M up to p=~1,000,000 for GFN8 and outputting the factors and b values to a text file. It seems to be doing this just fine, but if anyone notices anything strange about it, please let me know.

forstep (x = 1, 1954, 1, y=x*512+1; if (isprime(y), forstep (b = 2, 100000000, 2, p=b^256+1; c=(Mod(p,y)); if(c==0, write("GFN8Factors0-100M_1M.txt", y," | ",b)))));

This may be a bit better:

forstep (y=512+1, +oo, 512, if (isprime(y), forstep (b = 2, 100000000, 2, c=Mod(b,y)^256+1; if(c==0, write("GFN8Factors0-100M_1M.txt", y," | ",b)))))

In your version, b^256 is calculated as a full integer at first. It can have over a thousand figures. When you do Mod(p,y)^256 instead, it may be faster. (Not sure how much it matters.)

For example: Compare the output of 99999998^256 and Mod(99999998,16673)^256.

/JeppeSN

As already said by stream, there is no need to double-check the sieve, as long as you check each factor found. If the line looks like

As already said by stream, there is no need to double-check the sieve, as long as you check each factor found. If the line looks like

959815134871698800641 | 709500654^2097152+1

in the out file from the sieve (example taken from other thread), then maybe you can use some script (PARI/GP is not good with string manipulation) or regular expression to produce a file where it is written as

Mod(709500654, 959815134871698800641)^2097152+1 == 0

This will be extremely fast to evaluate for PARI. You can use: filedescr=fileopen("yourFileName"); while(1, line=filereadstr(filedescr); line==0 && break(); !eval(line) && error("Problem with: ",line); print1(".")); fileclose(filedescr) \\JeppeSN

I don't understand how Mod(b,y)^256+1 = 0 when y is a factor of b^256+1, but it seems to work and is very fast.

You can run these factors thru pfgw where each line is a row like this:

959815134871698800641 | 709500654^2097152+1

I don't understand how Mod(b,y)^256+1 = 0 when y is a factor of b^256+1, but it seems to work and is very fast.

Mod(a, b) not only creates 'a modulo b' but defines the congruence class of a modulo b.
This is not a % b but a such that a in Z/bZ.
Then Mod(b, y)^256 + 1 is still a residue modulo y and you don't have to reduce it again.

Yves's explanation is correct! If you are pedantic, it is really

Mod(b,y)^256+Mod(1,y) === Mod(0,y)

and everything is calculated in the ring Z/yZ. /JeppeSN

You can run these factors thru pfgw where each line is a row like this:

959815134871698800641 | 709500654^2097152+1

If you have grep it would be something like this: pfgw64 factors.txt | grep -v Zero > invalid.txt

I use this to verify the factors found by my sieving programs.

This is what I get when I run the script: ...

This is what I get when I run the script: ...

Check how the split command splits a given line. I would assume it works by splitting the string by spaces, so in order for the python program that Kellen wrote to work you probably need input files of the format:

prime base

instead of

prime | base^256+1

This would explain that it receives more values (in this case three, one substring is just "|") than it expects (two).

I've recreated sieve for GFN-6. It's currently sieved to 54T (0,054P) and contain 140M candidates. I'll try to squeeze more out it with AthGfn64. When it'll be ready, it could be used by a person who wish to double-check Kellen's work. Next I can write scripts to merge and compare results from both crunchers. And we'll have fully double-checked results.

As you can see, my sieving took a while because I had to sieve "dangerous area" where AthGfn64 is buggy (p < b) with own, simple and very slow program. Even being GPU-assisted, it took few days to process. But I found a way to improve it's speed a bit introducing special "AthGfn64 fix" sieve mode (in this mode, no need to test small candidates b < p, they're already removed by AthGfn64). So next sieves will be done faster.

Just got home and checked my GFN6 Candidates file and yeah; yours is way better :) Mine has 147,722,870 Candidates, so there were a lot left in that definitely should have been removed.

I should also mention that I am nearly finished a first pass of GFN8 and have started the verification pass on a second computer. Because GFN8 is a much longer set, I will finish the first pass and the 400M worth of verification pass that I have running and then stop until the better sieve is finished. That will save quite a bit of time even if a just a handful of candidates are removed. Everything up to GFN8 was already in progress by the time I gained the ability to generate the small factors and remove them, so I just left it all going.

Is your validation script able to look only at the residues for b values which appear in your candidates file? When comparing to my results files it will have to skip a lot of lines compared to the results files from yours.

I will PM you with a download link for the AthGfn64 Factor files for GFN8 to 2P. GFN9 will be at 10P mid-next-week, so I'll provide all those too (and GFN10 to 30P, 11 to 100P and 12 to 400P as those complete, or farther, if you want).

Yes, I've removed more because AthGfn64 loses many small factors p < b (i.e. below 2,000,000), and these small factors will cancel lot of candidates.
Also I've applied factors from your high sieve you've sent me (up to 250T / 0,25P) and final sieve size is 133,541,769 candidates now.

Factors above 30-50 T will help. Everything below is unnecessary; it takes too much space and I could sieve up to 50T within one day using AthGfn64.

I think you both should post your files (residues) somewhere (like Google Drive), I'll write a script to merge and compare them using my sieve files. I'll post final results somewhere too.

The script is not ready yet but it'll be a quite trivial Perl or PHP program. It should read a candidate from sieve, find corresponding residues in files presented by two crunchers (both residues must exist), and compare them. This sounds simple but may need some tricks and optimization because all these files are huge and straightforward approach may not work. It's not a problem for me. And yes, some results will be unused because my sieve is smaller then yours, but it also is not a problem.

And of course you could write this thing yourself as a programming exercise :)

OK, I've started making optimal GFN-8 sieve right now, so you'll have less work to do.

It's OK to send 10T+ files as is, no need spend your time and remove small factors manually unless they took too much space on your Google Drive. A program which removes factors will handle duplicates without problems.

OK, I've started making optimal GFN-8 sieve right now, so you'll have less work to do.

This is very much appreciated. I will finish what is running now then run the DC with the better files. GFN8 is where things really slow down, so a smaller file saves a lot of time.

For GFN8 we have the interesting property that already prime number nine, namely 2116^256 + 1, can really be "simplified" to a GFN9, namely 46^512 + 1.

In ancient days I suggested Yves put square brackets around 2116 on this page, if I recall correctly.

/JeppeSN

I've got GFN7 candidate files 1 to 19 complete or running but having trouble with the 20th candidate file. So I'm downloading the lot again.

I'll keep you informed.... :)

For GFN8 we have the interesting property that already prime number nine, namely 2116^256 + 1, can really be "simplified" to a GFN9, namely 46^512 + 1.

In ancient days I suggested Yves put square brackets around 2116 on this page, if I recall correctly.

/JeppeSN

So it looks like Rob is good to do the GFN8 second pass! This is fantastic, and with this news I will cancel my own second pass and instead put those resources towards sieving. I plan to sieve to 5P this weekend and can sieve deeper throughout next week if it would be beneficial. That should save a few million candidates from needing to be tested.

I will post factor files later this weekend ;)

GFN1-5 are completed and either double or triple checked with the PARI/GP script, LLR, or both.

Below are links for comprehensive lists of prime b values for each of these N values for anyone interested:

GFN1:https://drive.google.com/open?id=1dLGypMgI6LEf00UiMbgQUU5K9nFwk_r2
GFN2:https://drive.google.com/open?id=166asD5omJO_SvHfXruHrUmAEpMKIWi_G
GFN3:https://drive.google.com/open?id=1deX2w6Tt6s_yA_FYqlvvNZqCKd3JuKgA
GFN4:https://drive.google.com/open?id=1ya3EnygKi3v4UrfVZWkxuiCFALRQdP7V
GFN5:https://drive.google.com/open?id=13Z2FCOrojW_V2aiy_dN53tXN3ch1mj8S

And some stats for fun :)

I'm late to the party...

I'd be willing to run some GFN10, GFN11, GFN12 tests if it were easy enough. I'm putting together a 2nd remodeled Penguin Box with GPUs that would be perfect for this task. At least if it were to be done on a GPU up to 400M. Perhaps after GFN13/14 finish up these could be added to the Private GFN Server as a project? Or are the tasks far too small and the data rate too high to manage?

I'm late to the party...

I'd be willing to run some GFN10, GFN11, GFN12 tests if it were easy enough. I'm putting together a 2nd remodeled Penguin Box with GPUs that would be perfect for this task. At least if it were to be done on a GPU up to 400M. Perhaps after GFN13/14 finish up these could be added to the Private GFN Server as a project? Or are the tasks far too small and the data rate too high to manage?

I am on board. Ideally we would add the project to the private gfn server (if stream wants it as well), but I am also fine with running it privately.

I am on board. Ideally we would add the project to the private gfn server (if stream wants it as well), but I am also fine with running it privately.

It's possible for GFN-12 and probably -11. Other tasks are too short (even in -12 I should send many candidates to test in single WU).

Sieving will be completed to 200P on the 11th of April.

I wrote a GFN sieve https://github.com/galloty/gfsieve that runs 100% on GPU (CPU load = 0).
On a GTX 1050, GFN-12 sieve rate is 24 P/day. Maybe it can be used to extend GFN-12 sieving. The rate on a GTX-2080 should be > 100 P/day.

A binary for Windows of gfsieve is available here.
This version is based on 96-bit arithmetic. I will generate a new version where 64-bit arithmetic is used if p <= 9223 P (2^63).

You can compute the number of remaining candidates with the following formula:
#candidates = e^-gamma · C_n · B_max / log(p_max)
where e^-gamma = 0.5614595, C₁₀ = 8.0193435, C₁₁ = 7.2245969, C₁₂ = 8.4253499 and B_max = 2·10⁹.

Sieving must be extended for GFN-10, GFN-11 and GFN-12: if p_max = 200P, a sieve on GPU is able to test 100P / day and in 200P-300P, 2,000,000 candidates are removed. The rate is about 25 removals / seconde.
The optimal sieve limit should be around 10000P/100000P (depending on n).

Wow. This sieve is FAST! This will free up a ton of CPU resources to power through the rest of GFN9 and will make GFN10 viable for going to b=2G, as it had not yet been decided how GFN10 would be tackled. Now we can do up to 400M with Genefer as I was leaning towards, but the remaining portion to 2G can be done with LLR.

I think GFN11 is still too big to take to 2G with LLR, so we will stick with 400M and Genefer for that and GFN12.

Thanks again!

A new binary is available (gfsieve 0.5.0).

A 64-bit mode was added for p < 2^63 (9223 P).
The speed improvement with 64-bit arithmetic is about 60%.

Good luck with huge files!

# P/day was not correct when p_max - p_min > 1.
Computations and results were correct, only the displayed value was wrong.
This is fixed in gfsieve 0.5.1

# P/day was not correct when p_max - p_min > 1.
Computations and results were correct, only the displayed value was wrong.
This is fixed in gfsieve 0.5.1

gfsieve 0.6.0:
- save and restore checkpoint
- doesn't display factors on the screen by default. The command line -p can be selected to print them.
- save factors on disk within a separate thread. GPU will stay hot :o)

GPU load is 100% and GPU-MCU load is about 1% then I don't think that running more than once instance would be helpful.

Note that the minimum value for p is 1P. The number of factors is so large in 0-1P that it's more efficient to test this range on CPU.
gfsieve doesn't double-check the divisibility of GFNs. Normally another program is used for this task. It can be a Pari-gp program or a small C code compiled with a multiple precision arithmetic library (GMP, libtommath, NTL, boost multiprecision, ...).

We are now finished everything up to, and including, GFN8!

Here are the download links for files containing the prime b values for each GFN:

GFN1:https://drive.google.com/open?id=1dLGypMgI6LEf00UiMbgQUU5K9nFwk_r2
GFN2:https://drive.google.com/open?id=166asD5omJO_SvHfXruHrUmAEpMKIWi_G
GFN3:https://drive.google.com/open?id=1deX2w6Tt6s_yA_FYqlvvNZqCKd3JuKgA
GFN4:https://drive.google.com/open?id=1ya3EnygKi3v4UrfVZWkxuiCFALRQdP7V
GFN5:https://drive.google.com/open?id=13Z2FCOrojW_V2aiy_dN53tXN3ch1mj8S
GFN6:https://drive.google.com/open?id=1zM7NPdZHUS1YiXZxwHXKWdZwog0psOqC
GFN7:https://drive.google.com/open?id=1WzGsRSxrXhjUH4UkjzEgf3kMBL04V3Vu
GFN8:https://drive.google.com/open?id=1pSyYwGYItixvkII0h_46gz47cdkHCgD-

GFN9 is ~50% complete, and will be done in the next month or two, but after that there will be a short testing hiatus while the sieving is completed for GFN10-12. With Yves' new sieve we can very likely get GFN10 sieved deep enough to make an LLR search up to b=2G viable, and GFN11 and GFN12 will be run on Genefer.

Many thanks to everyone who has contributed so far! We are making some very solid progress :)

GFN9 is now complete to b=2G!

GFN9 Prime b Values:https://drive.google.com/open?id=1nIFzQtVywesH0y9lBw_-Vbfo7It_9umG

Many thanks to all who contributed to these efforts! This one was much more of a distributed project than the lower GFNs.

Stay tuned for GFN10-12 testing; we have something special in the works that should make it a lot more fun ;)

Very nice! It looks like there are 1437157 of them. Yves's calculator predicts 1436750, so this is 407 (0.028%, or 0.34 standard deviations) more than expected.

Very nice! It looks like there are 1437157 of them. Yves's calculator predicts 1436750, so this is 407 (0.028%, or 0.34 standard deviations) more than expected.

Bah! Pure coincidence and evil demons' work. I still think there are only finitely many of them. /JeppeSN

Very nice! It looks like there are 1437157 of them. Yves's calculator predicts 1436750, so this is 407 (0.028%, or 0.34 standard deviations) more than expected.

Bah! Pure coincidence and evil demons' work. I still think there are only finitely many of them. /JeppeSN

Aren't we expecting infinitely many primes for fixed exponent and varying base?

Very nice! It looks like there are 1437157 of them. Yves's calculator predicts 1436750, so this is 407 (0.028%, or 0.34 standard deviations) more than expected.

Bah! Pure coincidence and evil demons' work. I still think there are only finitely many of them. /JeppeSN

Well! No posts for a while, but we have been busy with this one and it is certainly time for an update.

GFN9, GFN10 and GFN11 are complete, and all primes verified! There remains some validation efforts for GFN11, but it is expected that those will go through without issue.

The results:

A huge congrats on this achievement and to all involved! I will definitely help out with some GFN12 work when it goes online. Will it run on GPUs too or CPUs only?

Also I'm curious about the statistics. Would you mind posting a table of expected and actual number of primes for all N=1 to 11?

The final bit of news is that GFN12 will be run from the Private GFN Server! This will likely happen after GFN14 is finished, so everyone who wants to run GFN12 should turn their GPUs in that direction and help get GFN14 done asap ;)

Hi lots to read here can you let us know how to participate in simple language and easy instructions or best to stick to projects available on primegrid preferences part of the website ?

Is GFN12 going to be cpu or gpu?

Hi lots to read here can you let us know how to participate in simple language and easy instructions or best to stick to projects available on primegrid preferences part of the website ?

Thanks wasnt as bad as I feared it's now doing GEN14 GPU :)

Thanks wasnt as bad as I feared it's now doing GEN14 GPU :)

Table from Yves. ...

Thanks!
Interesting that there are more GFN8 primes than GFN7 primes in your search range :)
And the accuracy of the estimates is quite remarkable.

Got my 3090 doing the GFN14s, seems to like doing these, runs 20 celcius cooler than when doing other work :)

I saw this page which is refreshed every 6 hours, just wondering is there version that is updated more often ? http://boincvm.proxyma.ru:30080/test4vm/user_profile/gfnxx_all_status.html

was running 4 tasks at about 40 seconds each. task manager shows 100% utilisation so left at 4