mersenneforum.org  

Go Back   mersenneforum.org > Great Internet Mersenne Prime Search > Software

Reply
 
Thread Tools
Old 2019-05-09, 16:27   #1
wfgarnett3
 
wfgarnett3's Avatar
 
"William Garnett III"
Oct 2002
Bensalem, PA

22×3×7 Posts
Default PRP versus LL first tests for Prime95 / impact on GPU factoring

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
wfgarnett3 is offline   Reply With Quote
Old 2019-05-09, 17:13   #2
M344587487
 
M344587487's Avatar
 
"Composite as Heck"
Oct 2017

5·113 Posts
Default

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.
M344587487 is offline   Reply With Quote
Old 2019-05-09, 17:17   #3
Prime95
P90 years forever!
 
Prime95's Avatar
 
Aug 2002
Yeehaw, FL

683310 Posts
Default

Quote:
Originally Posted by wfgarnett3 View Post
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.

Quote:

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.
Prime95 is offline   Reply With Quote
Old 2019-05-09, 17:41   #4
axn
 
axn's Avatar
 
Jun 2003

4,591 Posts
Default

Quote:
Originally Posted by wfgarnett3 View Post
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!
axn is offline   Reply With Quote
Old 2019-05-09, 18:18   #5
wfgarnett3
 
wfgarnett3's Avatar
 
"William Garnett III"
Oct 2002
Bensalem, PA

22×3×7 Posts
Default

Thanks for the helpful answers everyone!
wfgarnett3 is offline   Reply With Quote
Old 2019-05-09, 21:45   #6
kriesel
 
kriesel's Avatar
 
"TF79LL86GIMPS96gpu17"
Mar 2017
US midwest

5·7·109 Posts
Default

Quote:
Originally Posted by wfgarnett3 View Post
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.
Quote:
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.
Quote:
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.
Quote:
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.

Last fiddled with by kriesel on 2019-05-09 at 21:49
kriesel is offline   Reply With Quote
Old 2019-05-14, 03:43   #7
Madpoo
Serpentine Vermin Jar
 
Madpoo's Avatar
 
Jul 2014

1100101111012 Posts
Default

Quote:
Originally Posted by kriesel View Post
...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...
Madpoo is offline   Reply With Quote
Old 2019-05-15, 01:01   #8
PhilF
 
PhilF's Avatar
 
Feb 2005
Colorado

23·3·19 Posts
Default

Quote:
Originally Posted by Madpoo View Post
. . . 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!
PhilF is offline   Reply With Quote
Old 2019-05-15, 04:55   #9
dcheuk
 
dcheuk's Avatar
 
Jan 2019
Pittsburgh, PA

227 Posts
Default

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?

Last fiddled with by dcheuk on 2019-05-15 at 04:56
dcheuk is offline   Reply With Quote
Old 2019-05-16, 14:22   #10
kriesel
 
kriesel's Avatar
 
"TF79LL86GIMPS96gpu17"
Mar 2017
US midwest

381510 Posts
Default

Quote:
Originally Posted by Madpoo View Post
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 is offline   Reply With Quote
Old 2019-05-16, 14:54   #11
kriesel
 
kriesel's Avatar
 
"TF79LL86GIMPS96gpu17"
Mar 2017
US midwest

5·7·109 Posts
Default

Quote:
Originally Posted by dcheuk View Post
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.
Quote:
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.
Quote:
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<109 is estimated at <10-11; the likelihood of any such occurrence in p<109, <10-5. (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.

Last fiddled with by kriesel on 2019-05-16 at 14:59
kriesel is offline   Reply With Quote
Reply

Thread Tools


Similar Threads
Thread Thread Starter Forum Replies Last Post
Impact of AI xilman Lounge 19 2017-01-26 16:03
What are the Primality Tests ( not factoring! ) for Fermat Numbers? Erasmus Math 46 2014-08-08 20:05
GPU TF work and its impact on P-1 davieddy Lounge 161 2011-08-09 10:27
POWER CONSUMPTION idle versus Prime95 Peter Nelson Hardware 10 2005-01-16 19:42
Prescott impact to prime95. nucleon Hardware 35 2003-07-22 06:02

All times are UTC. The time now is 22:42.

Thu May 28 22:42:08 UTC 2020 up 64 days, 20:15, 1 user, load averages: 1.50, 1.41, 1.45

Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2020, Jelsoft Enterprises Ltd.

This forum has received and complied with 0 (zero) government requests for information.

Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.2 or any later version published by the Free Software Foundation.
A copy of the license is included in the FAQ.