PRP versus LL first tests for Prime95 / impact on GPU factoring

[wfgarnett3]

Hello,

For first time tests using Prime95 if I switch from LL to PRP and the test finishes with no errors using Gerbicz error checking does this mean 100% that there will be no need in the future for a double-check (like GIMPS presently does with LL)?

If this is a true statement then when my current LL test finishes with Prime95 I will start doing PRP for first time tests (and use the new Prime95 version to have the latest and greatest instead of using 29.4).

My CPU (Dell tower Intel CPU i3-4150) and GPU (EVGA GeForce GTX 1050 SC Gaming 02G-P4-6152-KR 2 GB from Newegg) have been 100% reliable so I anticipate no errors anyway.

2nd question -- doing the actual factoring/LL test timings on my GPU and using the math below from GIMPS website it made sense for me to go to 76 bits for GPU72.com on my video card with mfaktc when comparing to how long it takes to do 2 LL tests on my video card with CUDALucas.

------

factoring_cost < chance_of_finding_factor * 2 * primality_test_cost

"Looking at past factoring data we see that the chance of finding a factor between 2X and 2X+1 is about 1/x."

------

I have changed recently and now only go up to 75 bit on my GPU because PRP on the CPU (with no errors) eliminates the need to do a 2nd test as a double-check in the future -- is this a correct/fair interpretation? (I know this isn't an apples to apples comparison as CUDALucas on the GPU does not do PRP I believe so I am comparing to Prime95 using PRP for the initial test and not needing a 2nd future double-check). Plus there is no way of knowing after my 75 bit test if the actual GIMPS user later does LL or PRP (and in reality the GIMPS math formula is only valid for present state comparing GPU factoring to GPU primality testing (LL only) and separately CPU factoring to CPU primality testing (LL or PRP)).

Also FYI I only use CUDALucas for manual LL double-checking - never first time tests.

Bonus question :) if anyone knows the answer -- does the new Geforce 1650 get a big factoring boost like the other new cards (i.e. -- how many GHZ Days per day)?

My Geforce 1050 (that EVGA slightly overclocks) gets slightly over 250 GHZ Days per day. -- it is nice the 1050/1650 support 300 Watt towers so can easily slide in with no power connector.

Thanks for all the answers.

William

[M344587487]

There still needs to be a double check with PRP. Using PRP means that errors are greatly reduced so the need for triple checks is greatly reduced. It also makes large exponents viable to test.

[Prime95]

Originally Posted by wfgarnett3

For first time tests using Prime95 if I switch from LL to PRP and the test finishes with no errors using Gerbicz error checking does this mean 100% that there will be no need in the future for a double-check (like GIMPS presently does with LL)?

Good question. Most likely we will still do double-checking, but with less urgency. There are still vulnerabilities.

One is fraud. Who would bother to submit fake results? Well, for 22 years no one. This year we have our first deranged individual finding pleasure doing this.

Two is programmer error. Prime95 29.4 had an bug where it would report that it had done Gerbicz checking but did not. There were also small windows where it was vulnerable to a hardware error. Does gpuOwl or prime95 29.6 have any small windows where they are vulnerable to a hardware error?

Three is human error in copying/pasting manual results. We've seen this happen recently in TF results.

If this is a true statement then when my current LL test finishes with Prime95 I will start doing PRP for first time tests (and use the new Prime95 version to have the latest and greatest instead of using 29.4).

My CPU (Dell tower Intel CPU i3-4150) and GPU (EVGA GeForce GTX 1050 SC Gaming 02G-P4-6152-KR 2 GB from Newegg) have been 100% reliable so I anticipate no errors anyway.

2nd question -- doing the actual factoring/LL test timings on my GPU and using the math below from GIMPS website it made sense for me to go to 76 bits for GPU72.com on my video card with mfaktc when comparing to how long it takes to do 2 LL tests on my video card with CUDALucas.

I have changed recently and now only go up to 75 bit on my GPU because PRP on the CPU (with no errors) eliminates the need to do a 2nd test as a double-check in the future -- is this a correct/fair interpretation? (I know this isn't an apples to apples comparison as CUDALucas on the GPU does not do PRP I believe so I am comparing to Prime95 using PRP for the initial test and not needing a 2nd future double-check).

You should still go to 2^76. The answer would be different if there was a CUDA program that did PRP and GIMPS decided not to do double-checking. Your goal is to maximize the number of exponents your GPU can clear in a given time period. What prime95 does and gpuOwl does is irrelevant. You can only clear exponents by either TF or LL which definitely requires double-checking.

[axn]

Originally Posted by wfgarnett3

Bonus question :) if anyone knows the answer -- does the new Geforce 1650 get a big factoring boost like the other new cards (i.e. -- how many GHZ Days per day)?

My Geforce 1050 (that EVGA slightly overclocks) gets slightly over 250 GHZ Days per day. -- it is nice the 1050/1650 support 300 Watt towers so can easily slide in with no power connector.

I don't have a 1650, but I do have a 1660 Ti. Running it power-limited to 70w gives me about 1400 Gd/d. I would estimate a 1650 to deliver about 1000 Gd/d (give or take). Go forth and upgrade!

[wfgarnett3]

Thanks for the helpful answers everyone!

[kriesel]

Originally Posted by wfgarnett3

Hello,

For first time tests using Prime95 if I switch from LL to PRP and the test finishes with no errors using Gerbicz error checking does this mean 100% that there will be no need in the future for a double-check (like GIMPS presently does with LL)?

No it does not mean that. But switch to PRP anyway as soon as you can, where you can. The Gerbicz check is that good. Its overhead is only of order 0.2%. So if you could run PRP, or LL with Jacobi check, which catches half of LL errors, primality testing (twice) with PRP takes 2.004 effort, while LL takes 2.02 or more.

My CPU (Dell tower Intel CPU i3-4150) and GPU (EVGA GeForce GTX 1050 SC Gaming 02G-P4-6152-KR 2 GB from Newegg) have been 100% reliable so I anticipate no errors anyway.

Hardware becomes less reliable with age. Please run double checks at least once or twice a year on each.

2nd question -- doing the actual factoring/LL test timings on my GPU and using the math below from GIMPS website it made sense for me to go to 76 bits for GPU72.com on my video card with mfaktc when comparing to how long it takes to do 2 LL tests on my video card with CUDALucas.
------
factoring_cost < chance_of_finding_factor * 2 * primality_test_cost
"Looking at past factoring data we see that the chance of finding a factor between 2X and 2X+1 is about 1/x."
------
I have changed recently and now only go up to 75 bit on my GPU because PRP on the CPU (with no errors) eliminates the need to do a 2nd test as a double-check in the future -- is this a correct/fair interpretation?

Please go up to the gpu72 bounds for the given gpu model and two primality tests saved.
There are charts for each gpu model available at James Heinrich's site, for example
https://www.mersenne.ca/cudalucas.ph...n=90&mmax=1000
Or for single exponents, for example https://www.mersenne.ca/exponent/93000067
But any additional level is welcome, and there's plenty of work to go around. Whatever you don't complete, someone else is likely to get assigned. Investigate tuning your mfaktc.ini for max performance if you haven't already.

Also FYI I only use CUDALucas for manual LL double-checking - never first time tests.

Thank you for the LL double checks. Many more are needed. A good gpu and a proper CUDALucas installation can be quite reliable, even though there's no Jacobi check in it. I've not had any bad LL gpu results in over 1.5 years. There's no such thing as CUDAPRP yet.

[Madpoo]

Originally Posted by kriesel

...The Gerbicz check is that good. Its overhead is only of order 0.2%. So if you could run PRP, or LL with Jacobi check, which catches half of LL errors, primality testing (twice) with PRP takes 2.004 effort, while LL takes 2.02 or more...

Along that line of thought, it really will be nice if someone with bad hardware is able to catch it early and do something about it.

During my analysis, it's amazing how many machines out there had just been churning out one bad result after another, and it was only years and years later that we realized this, once they started getting double-checks and the trend was spotted.

If the Gerbicz error detecting lives up to the promise, it will definitely help out, even if we do still find mismatches down the road.

Right now, LL double-checking is pretty far behind the first time tests, and I still have my theory (with no evidence to back it up) that we've missed a prime somewhere in the < 57M range.

Ultimately that's the real problem, that we may have missed something but it'll be a decade before we know. Ultimately no harm done, but still...

[PhilF]

Originally Posted by Madpoo

. . . I still have my theory (with no evidence to back it up) that we've missed a prime somewhere in the < 57M range.

Now there's a way to create some double-check incentive!

[dcheuk]

What is the likelihood of someone completing a valid proof of the conjecture where there exists an infinite number of Mersenne Primes? What will happen to the project?

Is it necessary for the proof, if valid, contains some formula/theorem that can be exploited for generating mersenne primes?

Otherwise I don't think we have anyway of knowing if we skipped a prime or not ... unless we run all those tests again. What is the likelihood two computers returns the same bad residue though?

[kriesel]

Originally Posted by Madpoo

Along that line of thought, it really will be nice if someone with bad hardware is able to catch it early and do something about it.

During my analysis, it's amazing how many machines out there had just been churning out one bad result after another, and it was only years and years later that we realized this, once they started getting double-checks and the trend was spotted.

I think it would be a plus if future releases of primality testing software performed a brief self test before beginning each primality test, and if found unreliable, AT THAT TIME, refused to proceed with a primality test, instead providing the user with recommendations for improving reliability. Perhaps a fast small block of PRP/Gerbicz check, even if what's being run is LL; on the same exponent/fft length, to test more closely what's about to be run.

[kriesel]

Originally Posted by dcheuk

What is the likelihood of someone completing a valid proof of the conjecture where there exists an infinite number of Mersenne Primes? What will happen to the project?

It would be an encouragement but have little practical effect. If the converse occurred, a proof that only x Mersenne primes could exist, the project would have a potential end point, if x was near the current number found. If x>57, the project still has centuries to run.

Is it necessary for the proof, if valid, contains some formula/theorem that can be exploited for generating mersenne primes?

Very unlikely. It's unlikely any such exists.

Otherwise I don't think we have anyway of knowing if we skipped a prime or not ... unless we run all those tests again. What is the likelihood two computers returns the same bad residue though?

The likelihood of a random error causing a match for the same exponent is trivially small. The likelihood of 1 random erroneous res64 matching any exponent's res64 in p<10⁹ is estimated at <10^-11; the likelihood of any such occurrence in p<10⁹, <10-⁵. (See https://www.mersenneforum.org/showpo...3&postcount=19). There are some known error types that are known to not be random, and these are checked for in current software, including symptoms of them along the way, to minimize wasted compute time. The known nonrandom errors produce res64 values at or near zero, or at a much lower rate, near maximum. The LL false-positive zero res64 has historically been about ten times as common as all other identified nonrandom error res64 outcomes combined. (Details at https://www.mersenneforum.org/showpo...40&postcount=4)
A check of the existing PRP data for GIMPS showed no coincidence of res64 values among 9945 exponents, admittedly a small sample.

The methodology of 2 matching res64 results per exponent has been checked, by systematically triple checking small/fast exponents <3M, with encouraging results.