gpuOwL: an OpenCL program for Mersenne primality testing

[kriesel]

Originally Posted by preda

Yes, PRP only. LL could be added (back), but it would only make sense for double-checking (not first time); and it would only support offset==0 which I don't know whether is considered OK for DC.

If LL with Jacobi check was incorporated into a current commit, that would be great. (Especially if it meant multiple LL fft lengths.) But its absence is not a showstopper for LL DC with a gpu. We have both old gpuowl versions, and CUDALucas.

[kriesel]

An option to save persistent checkpoints would be good, perhaps every hour or million iterations, especially for when a long computation goes bad, such as the zero residue case encountered recently. See https://www.mersenneforum.org/showpo...6&postcount=60. In that run all the gpuowl save files were bad before the error was spotted.

[storm5510]

Originally Posted by kriesel

If LL with Jacobi check was incorporated into a current commit, that would be great. (Especially if it meant multiple LL fft lengths.) But its absence is not a showstopper for LL DC with a gpu. We have both old gpuowl versions, and CUDALucas.

I did a bit of a comparison yesterday. I am really not sure how much difference there is between PRP and LL. I used the same exponent on gpuOwl and CUDALucas. I started a PRP on gpuOwl. I reported 5 days to complete. I then started a LL on CUDALucas. It reported just under 8 days.

What value this has, I do not know. It is what it is.

[paulunderwood]

Originally Posted by storm5510

I did a bit of a comparison yesterday. I am really not sure how much difference there is between PRP and LL. I used the same exponent on gpuOwl and CUDALucas. I started a PRP on gpuOwl. I reported 5 days to complete. I then started a LL on CUDALucas. It reported just under 8 days.

What value this has, I do not know. It is what it is.

If you discover a Mersenne PRP then you have the prize -- an LL verification is merely a formality because the chances of it not being prime are like winning a lottery every day for a year.

The PRP test is more robust in that the Gerbicz error correction greatly reduces the risk of an error -- a PRP test is better for the project's throughout.

In your case with your hardware PRP it is a win-win situation.

[storm5510]

Originally Posted by paulunderwood

If you discover a Mersenne PRP then you have the prize -- an LL verification is merely a formality because the chances of it not being prime are like winning a lottery every day for a year.

The PRP test is more robust in that the Gerbicz error correction greatly reduces the risk of an error -- a PRP test is better for the project's throughout.

In your case with your hardware PRP it is a win-win situation.

Thank you for the reply.

Given what you wrote. PRP could be used as a substitute for a DC. Is this correct?

[kriesel]

Originally Posted by storm5510

PRP could be used as a substitute for a DC. Is this correct?

One PRP is not the equivalent of 2 LL tests, in multiple ways.
A PRP or an LL on a gpu (or any application, other than mprime/prime95 with its security code, reported manually) could be a complete fabrication by a malicious user. Or could be accidentally incorrectly transcribed by an honest user. There have been PRP results that were affected by software bugs lying outside the code guarded by the GEC. Hardware issues could also hit there. The GEC is very reliable, but Mr. Gerbicz has indicated its error detection miss rate is not zero.

Doublecheck relies on matching residues. So the residues need to be the same type. An LL first test needs an LL DC. A PRP first test needs a PRP DC, of the same residue type.

The error rate of LL is historically 2% so it took ~2.04 LL on average to get a match. PRP would be ~2 tests. That's a 2% improvement.

[paulunderwood]

Originally Posted by storm5510

Thank you for the reply.

Given what you wrote. PRP could be used as a substitute for a DC. Is this correct?

Almost! I leave that to those in the know on how easy it is for a rogue agent to submit fake PRP results.

It would be interesting to know the GIMPS bad PRP ratio anyway.

[kriesel]

Originally Posted by paulunderwood

...how easy it is for a rogue agent to submit fake PRP results.

It would be interesting to know the GIMPS bad PRP ratio anyway.

1) It's trivial to forge a manual gpu result, for LL or PRP or TF NF or P-1 NF. That doesn't stop the miscreants from getting it wrong and making detecting them easier.

2) More data samples are needed to get a sense of PRP error rate "in the wild". Only about 1/10 of the PRP I've done have been double checked or double checks.
The top producer for LL DC is 9850 results, while for PRP DC only 108.

[preda]

Originally Posted by kriesel

An option to save persistent checkpoints would be good, perhaps every hour or million iterations, especially for when a long computation goes bad, such as the zero residue case encountered recently. See https://www.mersenneforum.org/showpo...6&postcount=60. In that run all the gpuowl save files were bad before the error was spotted.

I haven't prioritized persistent checkpoints for P-1 because, in my mind, P-1 is a relativelly fast test. I see one P-1 as taking up to 1h, but in the past I've done quite a bit of 5min/exponent P-1 with both stages (at the wavefront), and it seemed like a relatively good use of my compute (IMO).

As a simple estimation, 24h for a full PRP test; let's allocate 2% of that time for a P-1 test, comes to 30min.

[kriesel]

Originally Posted by preda

I haven't prioritized persistent checkpoints for P-1 because, in my mind, P-1 is a relativelly fast test. I see one P-1 as taking up to 1h, but in the past I've done quite a bit of 5min/exponent P-1 with both stages (at the wavefront), and it seemed like a relatively good use of my compute (IMO).

As a simple estimation, 24h for a full PRP test; let's allocate 2% of that time for a P-1 test, comes to 30min.

That's ok for wavefront PRP & P-1 on fastest gpus (Radeon VII). The 100M digit exponents or higher, or ordinary gpus are another matter. On an RX480, one PRP of 333M is 68 days, one P-1 to 2-tests-saved bounds is 2.2 days. On an RX480, 2-test-saved bounds P-1 of 102M is 4hr 15 min. On an RX550, it will be about 3.5 times that, around 16 hours for 102M P-1, and would be 7 to 8 days for 333M P-1.
Your time to spend how you see fit, of course, including beach vacations.

[storm5510]

Originally Posted by kriesel

One PRP is not the equivalent of 2 LL tests, in multiple ways.
A PRP or an LL on a gpu (or any application, other than mprime/prime95 with its security code, reported manually) could be a complete fabrication by a malicious user. Or could be accidentally incorrectly transcribed by an honest user. There have been PRP results that were affected by software bugs lying outside the code guarded by the GEC. Hardware issues could also hit there. The GEC is very reliable, but Mr. Gerbicz has indicated its error detection miss rate is not zero.

Doublecheck relies on matching residues. So the residues need to be the same type. An LL first test needs an LL DC. A PRP first test needs a PRP DC, of the same residue type.

The error rate of LL is historically 2% so it took ~2.04 LL on average to get a match. PRP would be ~2 tests. That's a 2% improvement.

By security code, I take it that you mean the assignment ID?

If this is the case, gpuOwl might include an AID in its results, if there is one present in the work assignment. It uses a rather different results format than anything I've seen before. It has a name, I know, but I cannot remember it at the moment.

"2 LL tests." A first time and then a DC. I have done DC's with CUDALucas and never had a problem with a mismatched residue. Compared to this, running a LL or DC with Prime95 can be cumbersome regarding the time required. I will always use a GPU whenever possible! Some GPU applications do not pass through an AID when one is present in the work file.. I feel this needs to be corrected. Specifically, mfaktc, CUDAPm1, and CUDALucas. Sorry for going a bit off-topic...