mersenneforum.org new participant reference
 Register FAQ Search Today's Posts Mark Forums Read

 2019-07-15, 15:05 #1 kriesel     "TF79LL86GIMPS96gpu17" Mar 2017 US midwest 22×32×191 Posts new participant reference This is intended as a reference thread. Do not post here. Post comments at https://www.mersenneforum.org/showthread.php?t=23383 instead. Posts placed here may be moved or deleted without warning or recourse. This post New participant guidance https://www.mersenneforum.org/showpo...64&postcount=2 Background https://www.mersenneforum.org/showpo...65&postcount=3 How much work is it to do x https://www.mersenneforum.org/showpo...45&postcount=4 GIMPS glossary https://www.mersenneforum.org/showpost.php?p=533167&postcount=5 Older reference thread https://www.mersenneforum.org/showpost.php?p=533285&postcount=6 Best practices https://www.mersenneforum.org/showpo...18&postcount=7 OS fundamentals for GIMPS GPU application use https://www.mersenneforum.org/showpo...19&postcount=8 Why no one should run LL if they can run PRP with proof generation instead https://www.mersenneforum.org/showpo...06&postcount=9 Nick's Basic Number Theory Series https://www.mersenneforum.org/showpo...5&postcount=10 Assignments background https://www.mersenneforum.org/showpo...0&postcount=11 Proof and Cert handling https://www.mersenneforum.org/showpo...5&postcount=12 tbd if any Top of reference tree: https://www.mersenneforum.org/showpo...22&postcount=1 Last fiddled with by kriesel on 2022-09-15 at 23:40 Reason: added assignments background, proof and cert handling
2019-07-15, 16:04   #3
kriesel

"TF79LL86GIMPS96gpu17"
Mar 2017
US midwest

Background

The purpose of this post is to describe a shared foundation. Posting claims counter to what's here may indicate someone is an unaware novice, or is a troll. (Once I'm done weeding out my errors, with some help from others, that is.) This necessarily covers some points and leaves out much other material; whole books have been written about individual aspects, such as factorization. It's probably a good idea to read https://www.mersenne.org/various/math.php or watch George Woltman (forum user Prime95) describe the origin and methods of GIMPS, and then maybe return and resume here.
1. "Natural numbers" are the counting numbers 1, 2, 3, ... https://en.wikipedia.org/wiki/Natural_number
2. Expression of math operations here follow usual conventions and so are indicated as follows: addition +, subtraction -, division /, multiplication * or implied (as in the expression 2 k p = 2 * k * p), exponentiation of a to the b power ab, square root sqrt(), modulo a mod b, equal =, less than or equal <=. Operator precedence is standard PEMDAS: parentheses first, then exponentiation, multiplication, division, addition, subtraction, in that order, with ties going to left-to-right evaluation. Innermost parentheses are the first parentheses applied. The uppermost exponent is the first exponentiation applied. Function evaluation is from inside outward. Preference is given for conciseness. So 2*k*p+1 will be expressed as 2 k p + 1; log ( log (x)) will be expressed as log log x. Log without a base specified will be the natural log, loge = ln. Base may be expressed as a number following "log", as log2 or log10 or log10.
3. I use here n, a, b, f or k for natural numbers that may be composite or prime, but p for primes. Occasionally a hopefully helpful subscript is attached.
4. Natural numbers are either prime (having no natural numbers greater than one but smaller than themselves as exact integer divisors), or composite with factor(s) greater than one and less than the composite number. Five is an example of a prime. Six is an example of a composite: 6 = 2 * 3.
5. Finding and verifying a single nontrivial factor (a natural number 1 < f < n) of a natural number n proves it is composite, not prime. By definition. https://en.wikipedia.org/wiki/Prime_number
6. One is not considered a prime, but a more special case.
7. Smallest possible factor candidates are more likely to be factors than larger candidates. Two divides half the natural numbers, 3 a third, 5 1/5, f 1/f. So it's more efficient to search for factors with the smallest potential factors first.
8. The largest possible smallest prime factor of a natural number is, the largest prime natural number no greater than the square root of the number. fmin <= sqrt(n)
9. To search for factors of a number, it's sufficient to check only the primes below the square root of the number. Composite numbers can be skipped as potential factors, since their prime factors will divide any number they would, and some the composites won't. For example, 4 = 2 * 2, 6 = 2 * 3, 2 divides 14, 3 divides 15, but 4 or 6 divide neither. Thirteen is prime and it is sufficient to trial factor it with 2 and 3, since sqrt(13) ~3.6055 and the next prime, 5, exceeds 13's square root.
10. Mersenne numbers are a small subset of the natural numbers, having the form of a simple function M(n) = 2n - 1 where n is a natural number greater than 1.
11. Given a factor a of a number n = a b, the cofactor of a is b = n / a. (definition copied from http://mathworld.wolfram.com/Cofactor.html)
12. Any Mersenne number with a composite exponent n is composite; cannot be a prime. See https://www.mersenneforum.org/showpo...13&postcount=4
13. Mersenne primes are a very small subset of the set of Mersenne numbers with prime exponents. (It is not known whether the set of Mersenne primes is infinite.)
14. Any factors of Mersenne numbers with prime exponents are of the form f = 2 k p + 1, where p is the prime exponent, and k is a natural number. https://primes.utm.edu/notes/proofs/MerDiv.html
15. Numbers 2 k p + 1 can only be factors of Mersenne numbers with prime exponent if 2 k p + 1 = either 1 or 7, mod 8. Again, https://primes.utm.edu/notes/proofs/MerDiv.html
16. Multiple methods of computerized factoring are employed for Mersenne numbers. Which are worthwhile, and the extent or level of effort to which they are worthwhile, depend on the size of the exponent, the efficiency of algorithm and implementation, and characteristics of the computing hardware involved.
17. For some additional background, see https://www.mersenne.org/various/math.php regarding trial factoring, P-1 factoring, and the Lucas Lehmer test, https://www.mersenneforum.org/showpo...17&postcount=9 regarding probable prime testing and the Gerbicz error check, and https://magazine.odroid.com/article/...tical-history/ for an excellent backgrounder including FFT based multiplication of very large numbers (But note that PRP with GEC and proof generation is superior in multiple ways to LL; do PRP first tests, not LL.)
18. Large amounts of effort have been invested in developing and optimizing factoring and primality testing code relevant to Mersenne numbers for Intel CPUs, nonIntel CPUs, and GPUs from NVIDIA, AMD and also trial factoring on Intel or AMD CPUs' integrated graphics processors. There is summary info about these at http://www.mersenneforum.org/showpos...91&postcount=2
19. Trial division is one factorization method. Much more about it is available at https://www.mersenneforum.org/showpo...23&postcount=6 (especially #12 about implementation as modpow rather than long division for greatly increased speed) and https://www.mersenneforum.org/showpo...4&postcount=18 and elsewhere. There's a lot of discussion, and some Pari/GP code in the links of https://mersenneforum.org/showpost.p...21&postcount=8
20. For exponents much smaller than the current GIMPS search area, ECM (elliptic curve method) is also useful. But not at the current Great Internet Mersenne Prime Search (GIMPS) first-test or double-check wavefront of activity.
21. P-1 factoring is another useful method, including at currently active and higher exponents. See also https://en.wikipedia.org/wiki/Pollar...92_1_algorithm and https://www.mersenneforum.org/showpo...4&postcount=17
22. Eventually, factorization attempts produce diminishing returns for increasing computational resources, declining to the point where it is more efficient to run either a conclusive primality test (Lucas-Lehmer test), or a quite reliable probable-prime test (PRP3) that can prove a number composite but cannot prove it prime. See also https://www.mersenneforum.org/showpo...7&postcount=12
23. For the very large numbers involved in primality tests and P-1 factoring, squarings or multiplications are performed using the complex but efficient method of irrational base discrete weighted transforms, modulo the Mersenne number. See https://www.mersenneforum.org/showpo...21&postcount=7
24. In such lengthy computations, errors will sometimes occur. For error rates see https://www.mersenneforum.org/showpo...3&postcount=19
25. The programs contain various error checks that are performed during the computation. These often allow detection of an error and retreating to the point before an error was detected and attempting that portion of the computation again, which can save the lengthy computation if the error is not reproducible.
26. Some applications report the final error counts with the result. Results with counts of detected errors that may be serious concerning result accuracy can be scheduled for early checking.
27. Primality tests were eventually done at least twice, to catch the approximately 2 percent chance of incorrect result per LL test, or lesser error rate with PRP/GEC test, with certain precautions taken to ensure results are arrived at independently. The final result of a test mod 264 (called 64-bit residue or res64) is reported to the PrimeNet server. In the case of mismatches for the same exponent and primality test type, additional runs are made until matches are obtained. A coordinated effort to follow up on mismatches is at https://www.mersenneforum.org/showthread.php?t=24148 In rare cases it takes 4, 5 or 6 LL tests to get two that match. https://mersenneforum.org/showthread.php?t=20034
28. Much more on error types and handling is available at https://www.mersenneforum.org/showthread.php?t=24136
29. An exciting recent development is the PRP proof, certificate, and verification process supported in gpuowl, mprime, prime95 and the PrimeNet server, and being developed for Mlucas, after first deployment in gpuowl. This is expected to replace for new tests the double-check effort described in #27, reducing verification effort to typically less than 1% of the current cost of verifying an LL test or a PRP test without proof generation. Existing completed tests and future runs performed without the proof code present and enabled will still need double-checks. USE PRP/GEC/proof for all first primality tests going forward whenever practical!
30. Upon initial indication of a prime or probable prime by a reliable program, careful checking of the run for possible errors is performed. Multiple independent Lucas-Lehmer retests are made. To be eligible for prize awards, the rules must be followed, including a nondisclosure period while the multiple checks are run.
31. Many have attempted to predict the next Mersenne prime discovery. All predictions that have been sufficiently tested have been shown to have failed. A prediction that is very reliable is the following: any given prime exponent produces a composite Mersenne number. There are only 51 known exceptions currently, out of ~5.76 million tested or factored below 100M as of 2021-01-11 6PM UTC, so the known Mersenne primes compose less than 9 ppm of the candidate exponents in this range. Double checking is complete through 60M as of 2022-04-05.
32. On average, it is conjectured, Mersenne primes will occur at exponent ratios of 2^(1/egamma) where gamma is Euler's constant; this evaluates to approximately 1.475761397. https://primes.utm.edu/mersenne/heuristic.html However this is useless for predicting primes, since the ratio fluctuates widely. Observed values of ratio of exponents of successive known Mersenne primes range from ~1.01099 (43112609/42643801) to 4.10236 (521/127) https://primes.utm.edu/notes/faq/NextMersenne.html
33. An additional factoring method, P+1, has been added as of mprime/prime95 v30.6. This may be useful to those who hunt for additional factors of Mersenne numbers considerably smaller than the current wavefronts of primality testing and verification. It is believed to be unsuitably low productivity for factoring work for the wavefront. It is at a relative performance disadvantage to P-1 in mprime v30.8 or later, and to ECM in mprime/prime95 v30.9 or later. That may change someday.
34. Exponents will sometimes be abbreviated/approximated by suffixes of M or G. Those are powers of 10 as defined in https://www.nist.gov/pml/weights-and...ic-si-prefixes. Elsewhere the binary near equivalent may be used, as in discussing RAM capacity or requirements. https://en.wikipedia.org/wiki/Byte#Multiple-byte_units. The difference at only 2.4% / power of 1000 becomes appreciable; 1 TiB = 1.0995... TB. Hard drives are marketed using the smaller units employing powers of ten, and frequently rounding upward. (A 1TB drive is ~931 GiB.)
35. The progression of a particular exponent in the search for new Mersenne primes is typically as follows:
1. Addition to a database when the database is created, or expanded to cover a larger range of exponents. Usually this includes some very fast TF to a low bit level. Database creation or expansion is a rare event.
2. TF to increasing bit levels, up to a recommended maximum. The maximum is somewhat dependent on the type of hardware used for TF, and significantly dependent on Mersenne exponent, and number of primality tests potentially saved by finding a factor. Since GPUs are far more effective on TF than CPUs, it's recommended all TF be performed on GPUs, none on CPUs. A factor reported to the server is confirmed there and is conclusive proof the Mersenne number is composite.
3. P-1 factoring in a single run with adequate bounds and memory to efficiently perform and retire the task. A factor reported to the server is confirmed there and is conclusive proof the Mersenne number is composite. Sometimes the factor reported is itself composite, delivering 2 or more factors of the Mersenne number.
4. (No ECM, and no P+1, before primality testing)
5. PRP with GEC and proof generation. (Previously, this step was PRP/GEC, followed by verification by PRP-DC/GEC, or earlier, LL first test, LL DC, and sometimes LL TC etc.) Ideally the PRP run is done with the proof power at or near optimal for the exponent.
6. Verification. For PRP/GEC/proof-generation first test, a quick certification run on prime95 / mprime is performed. How quick depends on hardware, software, exponent, and proof power. For proof power 8, it takes less than 0.5% as long as the PRP/GEC/proof. Each additional increment on proof power is about twice as quick to certify. (Previously, verification was by a second PRP-DC/GEC, or for an LL first test, LLDC and sometimes LLTC etc., each taking as long as a first test.) Upon matching LL res64 values for the same exponent and standard seed value 4 (providing they are not known problematic residues & software), or upon matching PRP final res64 values and matching PRP types, or upon PRP/GEC/proof certification, primality testing is complete.
7. Almost always, the result is a factor or composite test result. These will eventually (perhaps years later) draw the attention of the additional-factor hunters, with ECM or P+1, or P-1 with larger bounds, or TF to higher bit levels. Rarely, an initial primality test will indicate prime and without any clear indication of error. These will immediately be retested in parallel with LL on different software and hardware, by multiple persons, to confirm or refute a new Mersenne prime discovery.
36. A factor of a Mersenne number occurs once in the Mersenne number's factorization, not twice or more (f, not f2 or higher power). "It is expected that 2n1 should be squarefree for prime n, but this is still open. A repeated prime factor must be a Wieferich prime (to base 2), and the only known such primes, 1093 and 3511, can't occur as repeated prime factors of 2n1 for prime n. See L. J. Warren and H. G. Bray, "On the square-freeness of Fermat and Mersenne numbers" Pacific J. Math 22 (1967), 563-564. It's available online at projecteuclid.org/journals/pacific-journal-of-mathematics/…KConrad
Jun 27 at 6:04" https://mathoverflow.net/questions/4...rsenne-numbers
37. If there are no known cases of Mersenne numbers of prime exponent having duplicate factors, there are no known cases of Mersenne numbers being composite and squares. Further, to generalize a bit from
Quote:
 Originally Posted by charybdis 2^1277-1 cannot possibly be a square number, as it is of the form 4k-1. If n = 2m is even, then n^2 = 4m^2 which is not of the form 4k-1. If n = 2m+1 is odd, then n^2 = 4m^2 + 4m + 1 = 4(m^2 + m) + 1 which is not of the form 4k-1. So no square can be of the form 4k-1.
for p>1, 2p-1 cannot possibly be the square of an integer. It is of form 4k-1; -1 mod 4.
Odd n, squared, is +1 mod 4.
Even n, squared, is 0 mod 4.
Some additional reading that may be of use at some point includes:
Nick's basic number theory series in this forum
"A Friendly Introduction to Number Theory", Joseph H. Silverman, https://www.math.brown.edu/~jhs/frint.html
The Prime Pages https://primes.utm.edu/
Knuth's Algorithms, Donald Knuth
Prime Numbers and Computer Methods for Factorization, Hans Riesel
Number Theory Web http://www.numbertheory.org/ntw/
"Prime Numbers: A Computational Perspective", Crandall and Pomerance
"Humble Pi", Matt Parker
"The C Programming Language", Kernighan and Ritchie https://en.wikipedia.org/wiki/The_C_...mming_Language
https://en.wikipedia.org/wiki/Prime_number

(Thanks to Batalov, Dylan14, LaurV and Dr. Sardonicus for contributing to the accuracy and readability of this post; see reference discussion thread.)

Top of reference tree: https://www.mersenneforum.org/showpo...22&postcount=1

Last fiddled with by kriesel on 2022-08-08 at 14:49 Reason: added 2 sentences to #33

2019-08-08, 13:35   #4
kriesel

"TF79LL86GIMPS96gpu17"
Mar 2017
US midwest

How much work is it to do x

Effort can be computed at https://www.mersenne.ca/credit.php for TF, P-1 factoring, or LL testing. Effort is expressed in Ghz-Days, the measure of what one core of a Core2 cpu running at 1Ghz could do in a day. Estimated performance of a given GPU is available at https://www.mersenne.ca/mfaktc.php for TF and https://www.mersenne.ca/cudalucas.php for other work types. Gpuowl performance with a recent 6.11-x or 7.x version is considerably better than indicated there.

To TF a Mersenne number with exponent 100M from starting bit level 73 to finishing bit level 76 is 133.9 GhzDays.
Double the exponent is about half the effort for equal bit levels. Each bit level is twice as much effort as the one preceding.
Note, in TF a GhzDay is not comparable to a GhzDay for other computation types, since GPUs are MUCH faster at TF. The ratio can be 11:1 ranging up to 40:1 or higher depending on GPU model and computation parameters.

To P-1 factor a Mersenne number with exponent ~100M to PrimeNet bounds B1=1040000,B2=28080000 is 13.90 GhzDays. This scales similarly to how PRP or LL testing do, ~p2.1.

GCD phase of P-1 or P+1 run time is O(p (log p)2 log log p), and strongly dependent on CPU core speed since known GIMPS implementations use single-threaded gmplib for GCD. For p~110M, Xeon Phi 7210, GCD time ~5.7 minutes. Run time scaling is in the range of p relevant to DC and upward to 1G, ~p1.14. In most applications GCD runs sequentially, stalling other CPU cores of a worker, or a GPU, for the duration of the GCD, while in some versions of Gpuowl it runs in parallel with the next P-1 stage or next assignment if a valid one exists in the worktodo file.

Server confirmation of a reported factor for TF or P-1 is a trivially fast computation.

To LL test a Mersenne number with exponent ~100M is 381.39 GhzDays. For ~110M it is ~482 GHzDays, or about a day on a Radeon VII gpu in a relatively recent version of gpuowl. (But do PRP with GEC and proof generation instead for greater reliability and efficiency.)
Effort scales as p log p log log p per iteration, or about p2.1 per test.

LL Double checking ("LLDC") and the occasional triple check, quadruple check, etc. are the same effort per attempt as a first test for a given exponent. Therefore, first testing using LL should cease as soon as possible. Using PRP with proof generation instead is more than twice as efficient, given LL's real world higher error rate and extremely high verification cost and extreme delays in verification time of occurrence. (Eight years is not unusual.)

To PRP test a Mersenne number is basically the same effort as an LL test. In gpuowl on a Radeon VII that could be a day for ~110M. On a Core 2 Duo it could be 11 weeks or more.

Gerbicz error check (GEC) as a fraction of a PRP, depends inversely on block size, typically ~0.2% of a PRP test at block size 1000. Overhead * blocksize ~ constant.

Jacobi symbol check, as a fraction of an LL test, depends on frequency, typically ~0.3% of an LL test.

PRP DC (without proof and verification as below) is the same effort as a first PRP test for the same exponent. Upgrade to proof generation capability as soon as possible.

PRP proof generation and verification
Total effort, assuming a single verification on a system separate from the PRP tester/proof-generator system and server, is, for a 100M exponent, approximately:
Code:
A) power= 8,  3.2 GB temporary disk space needed, proof file size 113MB, 413K squarings = 0.41% of a full DC, default
B) power= 9,  6.4 GB temporary disk space needed, proof file size 125MB, 239K squarings = 0.24% of a full DC
C) power=10, 12.8 GB temporary disk space needed, proof file size 138MB, 182K squarings = 0.18% of a full DC.
Proof generation as a fraction of a PRP, for a 100M exponent:
Code:
A) power= 8,  3.2 GB temporary disk space needed, proof file size 113MB, computation ~0.02% of a full DC, default
B) power= 9,  6.4 GB temporary disk space needed, proof file size 125MB, computation ~0.04% of a full DC;
C) power=10, 12.8 GB temporary disk space needed, proof file size 138MB, computation ~0.08% of a full DC.
In practice it is somewhat longer, with gpuowl proof generation for power 8 taking about 0.07% of elapsed time, which includes SHA3 hashes, disk reads, misc. other small activities. Temporary space increases about proportionally to exponent, so power 10, 1G would be around 130GB per working instance!

Prime95 will reserve proof generation required disk space at the beginning and hold it for the duration, releasing the temporary disk space upon completion. "As exponents increase, squarings, disk space, and proof size increase roughly linearly." https://www.mersenneforum.org/showpo...1&postcount=75

For Gpuowl, maximum working system ram during proof generation for proof power 9 was observed in Task Manager as ~0.25 GB, which only takes about a minute at the end of a PRP computation for p~104M, occupying 1 cpu core. Ram in use increased as it began at level 1 and successively built higher levels of the proof, with ~0.25 GB seen as it performed the level 9 proof build step.

Server computation related to PRP proof is a small fraction of the total verification effort, at 1414 squarings ~14 ppm of a PRP test for p~100M, power 8; 1577 squarings ~16 ppm for power 9. It's unclear how that varies versus exponent. https://www.mersenneforum.org/showpo...&postcount=189
Note, the server CPU is SSE2 hardware and its code is based on gwnum routines, so is limited to handling up to ~595.8M exponent automatically. Higher requires manual intervention by George.

PRP Proof Verification as a fraction of a PRP or PRPDC, for a hypothetical 100M exponent:
Code:
A) power= 8, proof file size 113MB, topk= ceiling(p/28)*28 = 100M, topk/28 = 390,625 squarings = 0.39% of a full DC
B) power= 9, proof file size 125MB, topk= ceiling(p/29)*29 = 100000256; topk/29 =  195313 squarings ~0.195% of a full DC
C) power=10, proof file size 138MB, topk= ceiling(p/210)*210 = 100000768; topk/210 = 97657 squarings = 0.098% of a full DC.
Power 7 would be 0.78% https://www.mersenneforum.org/showpo...5&postcount=46

Overall, LL vs. PRP compared:
LL + DC + occasional TC, QC, etc, ~2.04 tests at ~100M exponent, ~2.5 tests at 100Mdigits, to get a matched pair of res64s, which are presumed to constitute verification of those two runs. (There are some bugs which will cause erroneous residues that are far from random.)
PRP with GEC & proof generation & cert: ~1.01 test equivalent, to get a proven correct result.
PRP's error detection is far superior, and the overall project efficiency is more than double that of LL. (Increasingly so at larger exponents.)
That's why first time LL assignments are no longer issued by the PrimeNet server.
The reliability of LL has historically been a declining function with exponent increase. Longer run times create more chance of computing error that may escape detection.
That strengthens the case against LL which inherently has inferior error detection and recovery, as exponent and run time increase.

For first tests, run PRP with GEC & proof generation whenever possible. Only run LL with its lesser error detection and lesser efficiency, if PRP is not possible.
The preceding is for implementations of equal efficiency on equal or equivalent hardware. If comparing recent gpuowl to CUDALucas or ClLucas, add about another factor of 2 disadvantage for LL, and note neither of them include the Jacobi symbol check. Just don't LL!

To find the next Mersenne prime, compared to the current largest. R D Silverman lays it out at https://www.mersenneforum.org/showpo...58&postcount=8 as approximately 8 times as much effort, based on conjectures about the expected distribution. GIMPS has had a very lucky run for the past several years where the Mersenne primes have been more closely spaced recently, than expected on the average.

If the remaining number of Mersenne primes with exponent p<109 fits conjectures, there are 6 left to find. A rough estimate of time to complete the search of p<109 is 150 years. If they are equally spaced in time that's 25 years apart. That's far longer than GIMPS previous experience, averaging ~17/25 ~ 0.68 per year.

(Particular thanks go to Preda and Prime95 who helped me understand the proof and verification resource usage)

Top of reference tree: https://www.mersenneforum.org/showpo...22&postcount=1
Attached Files
 prp preferable.pdf (21.8 KB, 251 views)

Last fiddled with by kriesel on 2021-10-02 at 16:41 Reason: add GCD time, P-1 scaling, update discovery rate, misc edits

 2019-12-20, 16:55 #6 kriesel     "TF79LL86GIMPS96gpu17" Mar 2017 US midwest 22·32·191 Posts Older reference thread There is a reference thread from 2003 by PrimeMonster at https://www.mersenneforum.org/showthread.php?t=1534 Top of reference tree: https://www.mersenneforum.org/showpo...22&postcount=1 Last fiddled with by kriesel on 2019-12-20 at 16:58
 2022-01-02, 14:32 #8 kriesel     "TF79LL86GIMPS96gpu17" Mar 2017 US midwest 22×32×191 Posts OS fundamentals for GIMPS GPU application use Modern OSes offer both GUIs and command line interaction. Learn the fundamentals of both, before attempting to run GIMPS GPU applications. GIMPS GPU applications are not GUI applications, they are console text applications. As such they can be invoked from Windows batch files or Linux shell scripts. Attempts to launch GPU applications from the GUI side might work, but if they don't, which is almost certain the first tries, you probably will not get a chance to see what's wrong. Run them from the command line in a session that will remain long enough to show and allow capture of the output including error messages from the program or OS. A new user will not be successful in running GIMPS GPU applications without understanding adequately most of the following, for the OS in use: How to launch a command line session that will remain for review until the user intentionally closes it. How to obtain help in general or specific to one command or command option from the command line. Proper syntax of essential commands and some of their options. How to obtain a directory listing. How to display and modify file and directory ownership and permissions, and which are needed. How to create, move, or delete a file or directory. How to change current directory. How to edit an existing text file and save the changed file to the same filename or different filename. How to launch a program from the command line. How to redirect program input and output. The difference between stdout and stderr. How to download and install a program. How and whether to obtain, install, and use a tee program. The difference between append and overwrite. How to find, obtain, and install third-party utilities. How to obtain and install OS updates. How to obtain and install graphics card, OpenCL or CUDA drivers. How to check that a graphics card, OpenCL, or CUDA driver is installed and functional. Basic troubleshooting techniques. How to create and use and modify batch files on Windows or shell scripts on Linux. How to check and document OS & version, application and version, program inputs and outputs, etc. How to write a complete accurate useful actionable specific trouble report when first asking for help from others; how to THOROUGHLY & PRECISELY yet concisely document EXACTLY what was attempted and what the resulting responses were. Know the difference between the environment strings, command line environment, the command prompt, and the various commands that can be used at the command prompt. (Even some so called experts who advise others online in commercial blogs get some of those distinctions wrong.) What all the preceding mean. (Are there more?) Some possible resources for learning these things can be found online, such as Linux: https://ubuntu.com/tutorials/command...ers#1-overview Windows: https://docs.microsoft.com/en-us/win...ndows-commands There are also "help" on Windows and "man" on Linux. Top of reference tree: https://www.mersenneforum.org/showpo...22&postcount=1 Last fiddled with by kriesel on 2022-01-02 at 19:20
 2022-02-10, 18:04 #9 kriesel     "TF79LL86GIMPS96gpu17" Mar 2017 US midwest 22·32·191 Posts Why no one should run LL if they can run PRP with proof generation instead Run time, reliability, efficiency. All new first primality tests should be PRP type, with proof generation whenever possible. PRP/GEC/proof/Cert is much more reliable, and effectively twice as fast, since it essentially eliminates the typical 2% LL error rate leading to occasional triple checks or further, and reduces verification to typically under 1% of what an LL DC requires (>99% reduction!). If the choices are between Gpuowl PRP or CUDALucas LL, the savings are even more dramatic, nearly 4:1. PRP with proof generation also provides much faster indication of system reliability (typically hours), than does LL. (Typically years, 8.2 in that example, for an LL DC to occur; examples over 9 years also exist, including: https://www.mersenne.org/report_expo...6440291&full=1 https://www.mersenne.org/report_expo...7890291&full=1 https://www.mersenne.org/report_expo...5182317&full=1 https://www.mersenne.org/report_expo...4926731&full=1 https://www.mersenne.org/report_expo...7082673&full=1 https://www.mersenne.org/report_expo...5916561&full=1 https://www.mersenne.org/report_expo...7224663&full=1 https://www.mersenne.org/report_expo...7357359&full=1 https://www.mersenne.org/report_expo...7458873&full=1 https://www.mersenne.org/report_expo...7939197&full=1 etc. Ten years: https://www.mersenne.org/report_expo...2197123&full=1) Since the reliability advantage of PRP/GEC over LL also applies to double checking, most LL first tests will never have LLDC run. They will instead be verified composite more reliably and more quickly by a first time PRP/GEC/proof and cert. So in the usual >999,999 ppm case of a composite Mersenne number, an LL first primality test is a complete waste of time and computing resources. (An LL DC on an LL first test is also a small percentage waste of time, and is much less reliable than PRP/GEC. As is LL TC, LL QC, etc compared to PRP/GEC/proof/cert for reasonably close to optimal proof powers.) Mprime/prime95 (~v30.3 or higher), and GpuOwl (~v6.11-316 and later) are available in proof-capable forms. Mlucas proof file generation capability was planned for V20.x, but I think that slipped past v20.1 to V21 because P-1 implementation in V20 took a lot of effort, followed by some bug finding and fixing fun, with current latest available Mlucas at V20.1.1 2022-07-06. (Lucas-Lehmer tests will still be used if/when PRP returns a probable prime indication for a suspected new Mersenne prime discovery, to confirm by multiple independent tests by separate hardware, software, and participants. The person reporting a PRP probable prime indication from a first test would still be regarded as the discoverer.) In occasional sampling ~2021-01-24 of over 130 primality testing assignments in 101-102M, 38% were LL, 62% PRP. That LL frequency was much too high. As of 2021-01-27 1540 UTC in 101-102M primality testing of 273 active assignments, 57 LL, 21%, better. For 101M-103M as of 2021-03-28 ~2010 UTC, 23 LL of 132, 17%. On 2021-04-21 ~1500 UTC, for 102M-104M, first 1000 contained only 41 LL, 4.1% On 2021-04-30 ~1800 UTC, for 102M-104M, first 1000 contained only 11 LL, 1.1%. Let's keep moving away from inefficient LL first tests, that are very slowly double-checked, toward complete conversion to the far more reliable and efficient PRP/GEC/proof/Cert that also provides very rapid verification. A check of "recently cleared" 2021-07-19 showed a mix of primality tests for exponents >100M, 12 LL (mostly elapsed time over a year) vs. 924 PRP, ~1.3%. Drive LL percentage toward 0%, PRP with proof generation toward 100%. As of 2021-08-28, https://www.mersenne.org/assignments...chk=1&excert=1 shows only PRP in 1000 queued tests. It's unclear how many will produce a proof file. GPUs that can run either CUDALucas or Gpuowl should run PRP/GEC/proof on Gpuowl as primality tests, not LL, and not CUDALucas. (That would include all Google Colab GPU models. The Google Drive free space is sufficient.) Exceptional cases If attempting primality testing above 1G exponent, there is currently nowhere to submit proof files or primality test results, and no software to certify them above 1.17G. Proof files should be preserved where they are generated and held until that changes. PRP DC with GEC is likely to work. LL is likely to take dozens of attempts, or paired attempts with frequent interim residue comparison manually, to obtain matching final residues. If running on very low storage space hardware, run low proof power PRP with proof. (Mprime/prime95, and numerous versions of gpuowl can do that. Eventually Mlucas will also have proof generation capability.) If running on GPUs or CPUs so old that PRP is not available for them, consider replacing with newer more energy efficient hardware. If part of the select small team confirming a PRP-P result is in fact a new Mersenne prime discovery, then LL is necessary to prove primality, and should be performed on the fastest available reliable hardware in differing software by multiple individuals. For large exponents it is likely comparison of interim residues will be useful in indicating reliable progress or detecting computation errors along the way. Top of reference tree: https://www.mersenneforum.org/showpo...22&postcount=1 Last fiddled with by kriesel on 2022-09-15 at 20:30 Reason: correction re status of Mlucas current version

 Similar Threads Thread Thread Starter Forum Replies Last Post kriesel kriesel 14 2022-09-25 17:08 kriesel kriesel 9 2022-05-15 13:21 kriesel kriesel 4 2019-11-03 18:02 kriesel Information & Answers 3 2019-05-06 16:34 Jushi Math 2 2006-08-28 12:07

All times are UTC. The time now is 03:16.

Thu Oct 6 03:16:21 UTC 2022 up 49 days, 44 mins, 0 users, load averages: 1.50, 1.25, 1.20