Go Back > Extra Stuff > Blogorrhea > kriesel

Closed Thread
Thread Tools
Old 2019-07-15, 15:05   #1
kriesel's Avatar
Mar 2017
US midwest

22×32×191 Posts
Default new participant reference

This is intended as a reference thread. Do not post here. Post comments at instead. Posts placed here may be moved or deleted without warning or recourse.
  1. This post
  2. New participant guidance
  3. Background
  4. How much work is it to do x
  5. GIMPS glossary
  6. Older reference thread
  7. Best practices
  8. OS fundamentals for GIMPS GPU application use
  9. Why no one should run LL if they can run PRP with proof generation instead
  10. Nick's Basic Number Theory Series
  11. Assignments background
  12. Proof and Cert handling
  13. tbd if any

Top of reference tree:

Last fiddled with by kriesel on 2022-09-15 at 23:40 Reason: added assignments background, proof and cert handling
kriesel is offline  
Old 2019-07-15, 15:52   #2
kriesel's Avatar
Mar 2017
US midwest

22·32·191 Posts
Default new participant guidance


The Mersenne forum content is almost all expressed in English (a blend of UK and American). For those whose native language is not English, we native English speakers very much appreciate your efforts to communicate in English! covers many different ways of aiding the Great Internet Mersenne Prime Search (GIMPS) progress, through trial factoring, P-1 factoring, Lucas-Lehmer testing, probable-prime testing, double checking, proof certification etc. of Mersenne numbers, 2p-1. (You may see these abbreviated as TF, P-1, LL, PRP or PRP3, DC, LL DC, PRP DC, Cert.)
It also provides a home for a lot of threads about related number types that have no direct connection to finding Mersenne prime numbers, such as Proth numbers, or Cunningham numbers, or activities or programs that have little or no direct connection, such as factoring for general natural numbers as an end in itself.

Most of this description is GIMPS oriented.

There are many different operating systems, and processor types, in common use or development. Most activity is on Windows or Linux, on Intel or AMD processors, or NVIDIA or AMD GPUs, but there is a little Mac activity, and Linux on smaller hardware including Raspberry Pi, Odroid C2, Samsung cell phones, and Intel compute sticks, as well as trial factoring via Mfakto on some models of Intel or AMD integrated graphics processors, and in rare cases gpuowl on IGPs.

Most of the hardware is personally owned or employer owned. (Getting written permission for use of employer-owned gear from an authorized person is very highly recommended. It has happened that someone got permission from the wrong person, and got personally acquainted with how the FBI executes a search warrant, seizing and holding for years, all computer equipment including that of a client of the person being investigated.) Others use cloud computing. Or a combination.

If you have newly signed up to the project, it may take the busy volunteers running things a while to get to approving you for making manual submissions to the PrimeNet server. Please be patient, but if you do not get set up for days, contact them.

When joining the forum:
Some go to considerable length to use an alias and remain essentially anonymous. Others see no reason to do that, and see drawbacks to it. Nearly all the prominent software coders are identified. Use good judgment on what personally identifying information you do and do not disclose.

The forum offers reading and making public posts, optionally including up to 5 attachments of certain specified types and size limits, and sending and receiving private messages (PM) without attachments. There's also a search capability by multiple keywords. Please limit PM sent to the leading software coders. They are volunteers and there is always more to code and test. They are rare and their time valuable.

When posting on the forum:
Take some time to read the existing threads, FAQs, reference information, the Netiquette post, etc., before posting.
Some suggested material is at
Intro to GIMPS and prime95 math (omits PRP etc)
Note: whenever practical, use PRP/GEC/proof generation, NOT LL for first tests.
PRP/GEC/proof generation is also superior in speed and reliability for double-checks.

Do not post to any forum thread:
64-bit residues ("res64") for first tests prior to verification
assignment IDs that are currently valid (active), intended to be shared secrets between you, your GIMPS client software, any proxy software, and the PrimeNet server (and perhaps its administrators) only
MD5 hashes
links to porn sites, malware sites, etc., or links with tracking info included
inflammatory material
Mersenne prime discovery before the official Mersenne Research Inc press release is issued (early disclosure would disqualify you for any prize money)

Available software (cpu and gpu summary) listing is found at (and its historical thread
reference material compilation (large!)
cloud computing subforum
prime95 v30.8 for CPUs
prime95 v30.7 for CPUs
GPU Trial Factoring FAQ (old)
GPU LL testing FAQ (old)

(And again, do PRP/GEC/proof whenever practical for first tests, NOT LL! GPUs that can't run a recent version of gpuowl should only do LL DC, or TF. They're probably too old to be reliable enough for P-1 without much error checking implemented, as in CUDAPM1 which has very little checking built in. They're probably too old to be energy efficient, and are candidates for retirement)

Some of the threads are very long. Some show the history of development of certain applications. It can be useful to take notes as you go through those threads, including URL's for easy return to the more informative or seminal posts.
Some content may not mean much to you when first encountered, but will later, after enough is learned, for its importance to be apparent, or its content to be better understood. It can be useful to read again or skim the same thread six months or a year later.

The forum is not the place for submitting unremarkable results of GIMPS computations.
To apply your GPU to needed work, and improve your chances of avoiding unneeded duplication of someone else's work, go to or to reserve work assignments.
To report the results, copy and paste into
Or make use of a relevant client management package. See and note that some applications have a separate work reservation and/or result submission script.

It's standard for PrimeNet to assign some double-check (DC) work to a new computer. This is to qualify it as reliable, and helps with the backlog of double-checks, which is currently several years long. It's also a good idea to run a qualifying double check on anything you manage manually or via one of the client management tools. If the DC matches, great, that justifies confidence in the system. But if the DC does not match, it might not be a problem with your hardware, but with the other system that did the first test. What's needed is a tie-breaker triple check (TC) to determine if either is correct. These can be requested at

Be courteous; avoid sounding hostile or rude. People do get temporarily banned if going too far. A long pattern can get long bans. Occasionally, permanent bans. It's generally preferable to apply some principles from Dale Carnegie's book "How to Win Friends and Influence People." If someone goes way over the line, the offensive post can be reported by clicking on the little red and white triangle at the lower left of the post.

Above all, avoid profanity, bullying, threats or harassment or the appearance of such. A "smily" attached does not mean there are no limits on what will get you blocked, banned, or into legal trouble.

Realize that there's a real person at the other end. Realize that text without mannerisms such as smiles as in person comes across as more negative. When posting, be generous and make an effort to keep tone positive. Effective communication is more likely when no one is annoyed, offended, insulted, disparaged, or feels those whether it was intended or not. Conversely, when reading, realize perceived offense may be unintended. Its appearance may be due in part to cultural or language differences, hurry, frustration, history, various maladies, etc.

Remember that this is a worldwide community, including people from many nations, cultures, age brackets, occupations, educations, perspectives etc. Anyone from about age 13, to published number theory professors or world-class programmers/software engineers, to retired & senior citizens.

Use an existing topic-specific thread when practical.

Use the existing already-posted answers when possible.

If English is not your native language, tell us. Responses will be more tolerant if so.

Understand that people get tired of answering the same questions asked year after year from people who don't bother to read program documentation or reference posts or previous answers or use the search function first. Making an effort to find an answer yourself first helps, especially if you tell us that you did.

Proofread your draft of a post. Preview before submit. After submitting it, you'll have a limited time to edit it (about an hour currently). For complex posts, an ordinary editor may be more useful; copy/paste from a draft in the forum page's editing window, to the separate editor, and back again. Use the quote and code and other tags to organize and format the post. Learn this from examining others' usage in posts that you quote.

Make an effort to provide an easily read complete set of the needed context information in the same post with a question or bug report. If you're asking why something is not working how you expect, tell us at the beginning what software you're asking about, what version of the software, what OS you're running it on, what OS version or flavor, what hardware, what computation type (for mprime / prime95, Gpuowl, Mlucas or any other software that can perform more than one computation type), stage if relevant, exponent, bounds or bit levels as applicable, non-default tuning, any parameters it seems to be having difficulties with, and any other pertinent information. If asking about Linux, what version of what distribution. In the case of a GPU related question, include the GPU model, driver name and version, and perhaps hardware specs that are relevant (GPU ram for example, or NVIDIA compute capability level). A little time spent once, providing that info in a convenient format, can save many readers and the original poster a little time each, and reduce the need for Q&A that sometimes follows when such information is missing, or hidden away somewhat in a long code box line. It's especially important to be considerate of the time of the rare few very talented volunteer programmers.

If posting benchmark information, specify not only time per exponent or iteration or whatever, but the exponent, computation type, details such as the TF bit level or P-1/P+1/ECM bounds, FFT length if applicable, non-default tuning parameters, the hardware, the OS, etc. so that it is meaningful. An under-specified benchmark result is not useful; a fully specified one is useful.

If posting code, please indicate in a comment at the top of the code, what language the code is. There are so many programming or scripting languages, that it is very unlikely all readers will recognize any language you might use unless perhaps it is an exceedingly common one. It would also be helpful if you post what version of the language it's known to work in, or versions of popular compiler it works with. Depending on the code, it might also be useful to know operating system or hardware requirements.

There are thousands of users and thousands of threads. Don't expect us to remember what hardware you own, what OS and version you run, etc. We forget, or never saw that one time or ten you posted it elsewhere. Tell us again, when and where it is relevant. It's simple enough to make a little description file once, and then copy and paste it into your posts as needed. Do this when it's helpful, and not otherwise. (We don't need or want to see anyone naively bragging in their every post about how many cores are in the one overpriced medium performance system they bought instead of a more efficient system or GPU.)

Be especially rigorous and forthright if posting in math or number theory threads. Some participants may be very assertive regarding unclarity or error or what appears to be ignorance of the prior art, getting terms switched, proposing "improvements" that reduce reliability or lengthen run times, etc. A lot of very skilled people have worked the area for a long time. Extraordinary claims require extraordinary evidence, and will be met with considerable skepticism and lots of questions. It's not personal. It may help to consider questions as demonstration of a desire to understand your position, and feedback as interest in helping you.

Minimize the use of idioms. They're less likely to be understood well by people whose native language is not English. An idiom example is "a piece of cake." The non-idiom equivalent is "very easy."
Avoid the use of "gratuitously obscure lingo". If in your best judgment use of the obscure term would help make a post substantially more concise, or is a term the learning of which would benefit numerous participants, include a parenthetical definition or a link or both at the term's first use in the post.

Clear writing, with good spelling, punctuation, grammar, and structure, is always appreciated. The care in writing is paid once. The benefit is lasting. It is considerate of the other forum participants to post clean content.

It's considered impolite to ask another member how much computing gear or throughput they have access to. Even if the reason you ask is to understand their perspective. Or to brag about how many cores and GPUs you have control of. Let your work speak for itself. Specifying what hardware produces a puzzling result or a fast benchmark is fine. People are happy to have (well-specified) benchmark results posted for the newest GPU or CPU models. It may help with someone else's purchasing decisions.

Please read and for guidance what to do or how to do it, and perhaps for what not to do or how not to do it. Other parts of the Other Stuff/Forum Feedback subforum may also be useful.

Do not post assignment IDs for current assignments, or 64-bit residues for results not yet verified, or MD5 hashes for proof files.

Refrain from trolling or activity that will likely be interpreted as such. "a person who posts inflammatory, insincere, digressive,[1] extraneous, or off-topic messages in an online community (such as social media (Twitter, Facebook, Instagram, etc.), a newsgroup, forum, chat room, or blog), with the intent of provoking readers into displaying emotional responses,[2] or manipulating others' perception." Such behavior may earn a spot on individual forum users' "ignore list" (how-to-add here), or other pushback, or progressive discipline from forum moderators, consisting of reprimands, warnings, loss of blogger or moderator status, temporary ban from posting on the forum, permanent ban from the forum, or perhaps other measures.

User names display in a few different colors next to their posts. As I understand it, blue is ordinary user; green is blogger (moderator privileges in his own blog and a select few other areas of the forum); red is super moderator; purple is banned user (may be temporary, "permanent", or really permanent ban); Xyzzy the forum owner displays blue. Here's another description.

The different subforums and threads have differing purposes. Some are rather more informal and for entertainment or humor. Others are seriously oriented to a single specific purpose, such as development or support of one GPU application.
Values in the more serious ones include:

Please consider how you may contribute positively, other than in computing throughput, toward the project's goals. Do you have skills in programming, in a flavor of C/C++/C#, Python, CUDA, OpenCL, multithreading, assembler, profiling, web scripting, databases, etc? Technical writing? Software testing? Math or number theory specifically? Other ways to help? See also and the many other online tutorials to help develop such skills.

(note, an earlier version of this was available at for comment since April 17 2019)

Top of reference tree:

Last fiddled with by kriesel on 2022-03-19 at 13:22 Reason: added caution on obscure terms
kriesel is offline  
Old 2019-07-15, 16:04   #3
kriesel's Avatar
Mar 2017
US midwest

1ADC16 Posts
Default 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 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, ...
  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.
  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
  12. Any Mersenne number with a composite exponent n is composite; cannot be a prime. See
  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.
  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,
  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 regarding trial factoring, P-1 factoring, and the Lucas Lehmer test, regarding probable prime testing and the Gerbicz error check, and 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
  19. Trial division is one factorization method. Much more about it is available at (especially #12 about implementation as modpow rather than long division for greatly increased speed) and and elsewhere. There's a lot of discussion, and some Pari/GP code in the links of
  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 and
  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
  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
  24. In such lengthy computations, errors will sometimes occur. For error rates see
  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 In rare cases it takes 4, 5 or 6 LL tests to get two that match.
  28. Much more on error types and handling is available at
  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. 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)
  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 Elsewhere the binary near equivalent may be used, as in discussing RAM capacity or requirements. 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…KConrad
    Jun 27 at 6:04"
  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
    Originally Posted by charybdis View Post
    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,
The Prime Pages
Knuth's Algorithms, Donald Knuth
Prime Numbers and Computer Methods for Factorization, Hans Riesel
Number Theory Web
"Prime Numbers: A Computational Perspective", Crandall and Pomerance
"Humble Pi", Matt Parker
"The C Programming Language", Kernighan and Ritchie
"Recreations In The Theory of Numbers", Albert Beiler

(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:

Last fiddled with by kriesel on 2022-08-08 at 14:49 Reason: added 2 sentences to #33
kriesel is offline  
Old 2019-08-08, 13:35   #4
kriesel's Avatar
Mar 2017
US midwest

1ADC16 Posts
Default How much work is it to do x

Effort can be computed at 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 for TF and 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:
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:
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."

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.
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:
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%

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 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:
Attached Files
File Type: pdf 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
kriesel is offline  
Old 2019-12-18, 15:15   #5
kriesel's Avatar
Mar 2017
US midwest

22×32×191 Posts
Default GIMPS Glossary

See also the background post.

Software application names are intentionally omitted from this glossary. See the "Available Mersenne prime hunting software" table for those.

100Mdigit: There's an Electronic Frontier Foundation prize for finding the first prime large enough to occupy 100 million digits (100 megadigits). A GIMPS subproject is to search for such a prime and win that prize. This requires an exponent of at least 100,000,000/log10(2) = 332,192,807 for the Mersenne number. The smallest prime exponent above that minimum is 332,192,831.

assignment identifier: The 32 hexadecimal character unique identifier that the PrimeNet server and clients use to identify and communicate about a specific assignment. These appear in worktodo entries, results output, and internet traffic. AIDs are to be kept confidential while they are valid (active). If they are not kept confidential they could be abused by some miscreant. A fundamental rule of GIMPS etiquette is to never post on the forum a valid AID. Moderators will intervene and remove such content. Don't make more such work for the moderators which may annoy them.

assignment: designation by the PrimeNet server, through either automated or manual operation, of a specific computation task (one specific work type, for one exponent) as reserved to one GIMPS user. See for what the various forms of closely associated worktodo entries look like. Manual assignments are obtained through or for exponents <1G; from for higher exponent TF or P-1. Note these assignments can expire before completion and result report. See also "Assignments background"

base: in P-1 or PRP, the starting number which is raised to successive powers. Usually 3.

bit level: in TF, indication of how far TF has been performed. For example, 74 corresponds to attempting factors up to 274 in size.. A single bit level would be advancing the TF performed by one, such as from 273 to 274.

bound: a limit. Specific to P-1 factoring, an upper limit on the set of primes used in a stage of factoring, referred to as B1 and B2.

certificate:a file showing completion of a PRP proof verification. Such a file can be very rapidly verified as valid by a server.

CERT: depending on context, a worktype, or the performance of the work. Mprime / prime95 support receiving CERT assignments via the PrimeNet API, receiving the required hashed input file generated by the PrimeNet server (from a proof file the server received from a client earlier), and computing from the received hashed file a CERT type result record for upload to the PrimeNet server.

counterfeit:a deliberate fake, a fraud (crime) perpetrated seeking fame or fortune. In GIMPS results, a fabricated result for work not performed, or only slightly performed. In computing hardware, devices disguised and sold to seem to be more than they are. USB external SSDs are one current example, and high capacity flash drives appear to be another. The PrimeNet server implements some anti-counterfeiting measures. Hardware buyers beware, and be prepared to test hardware upon receipt.

CPU: central processing unit. Can be used for any GIMPS computation, although CPUs have largely been supplanted by GPUs for trial factoring within the p<232 exponent range.

CUDA: "CUDA is a parallel computing platform and programming model invented by NVIDIA." It is proprietary and only usable on NVIDIA GPUs. There are many different version levels. As of 2021-05-29, latest is v11.3.

DC: abbreviation for double-check

double-checking: running a second primality test on an already tested exponent, with the same primality test type, seed, residue-type, as applicable. If the runs are independent, and error counts are low, matching res64 values are presumed to both be correct.

ECM: Elliptic curve method of factoring. This is suitable for Mersenne numbers with exponents below 40 x 106. It is not suitable at the current GIMPS wavefronts or above.

expiration: the end of an assignment before it's completed, because time ran out. Expiration is an action by the server during periodic application of assignment rules. Expiration occurs earlier if there's no progress reported in the work assigned. Time from assignment to expiration depends on the assignment type, exponent, and last date of progress reported on that same assignment if any. (Some other work types performed or reported, such as TF or P-1 no-factor results, on the same exponent, by the same user or others, may have no effect on PRP or LL assignments' expiration. Reporting a factor found or completed primality test will expire an assignment. See also poaching, which is discouraged. See also reserve, and unreserve)

exponent: for a Mersenne number, the power, or number of times 2 is multiplied together, as the 3 in 23=2x2x2=8 before subtracting a 1, yielding M(3)=23-1=7

extension: adding additional time to complete an assignment. See

FFT: Fast Fourier Transform; Finite Fourier Transform

fft length: number of double precision words length of an FFT used for computing products or squares. In the range of exponents of current GIMPS wavefront interest, fft length ~ exponent/17.5. For more, see

FPGA: Field programmable gate array. To my knowledge there have been many suggestions/proposals to use FPGAs in GIMPS over the years, but no working designs or compatible software created or announced or demonstrated or shared. See for a recent iteration.

Gerbicz error check: a highly reliable error check on the PRP test, identified by Robert Gerbicz, with nearly 100% detection for errors in the PRP iteration process, which allows resuming from an earlier saved state and trying again. It is independent of earlier error detection methods. The high detection rate for software or hardware error in computing PRP iterations provides MUCH higher reliability for completed tests than a Lucas-Lehmer test on the same software and hardware for large exponents. See Other errors not caught by this are possible and have been observed, rarely. The check is built into PRP code of recent versions of gpuowl, Mlucas, mprime, prime95.

GHzDay: in GIMPS, a unit of computing work equivalent to what a 1 Ghz Core2 processor core would accomplish in a day with efficient GIMPS code.

GhzD/day: in GIMPS, a computing rate equivalent to what a 1 GHz Core2 processor core would accomplish. Note that the same hardware may have very different ratings for very different computation types. CPUs generally have ratios between TF and other computations that are near one, while GPUs can be very different; ratios of 11:1 to 40:1 faster TF have been observed.

gigadigit: There's an Electronic Frontier Foundation prize for finding the first prime large enough to occupy 1000 million digits (1000 megadigits). A small subproject is to search for candidates for such a prime and hypothetically someday win that prize. This requires an exponent of at least 1,000,000,000/log10(2)-3.3 = 3,321,928,092 for the Mersenne number. The smallest prime exponent above that minimum for which no factor has yet been found is 3,321,928,307. Note that sufficient TF depth for such a Mersenne number is 91 or 92 bits, representing a total TF effort investment per exponent of up to ~151,000 - 302,000 GHD TF. Preparatory P-1 to sufficient bounds (B1 17,000,000, B2 1,000,000,000) is estimated in 2021 to require about a year each exponent on some available higher end consumer hardware, and require 16GiB ram for stage 1, 64 GiB ram for stage 2. Software to do PRP with proof generation at this exponent level does not yet exist. PRP run time estimates in 2021 are of order 5 years each try on a Radeon VII GPU, much longer on available CPUs. Such exponents are outside the server range (by 3.322 times), so preliminary TF & P-1 effort is being coordinated in "Operation OBD" forum threads. As the exponent increases, the odds of a prime diminish, while the testing effort grows rapidly.

GIMPS: the Great Internet Mersenne Prime Search

GPU: graphics processing unit.

hoard: to obtain assignments, especially a large number of them, and do nothing with them for much of the assignment lifetime. Manual assignments performed on applications which are not PrimeNet interfaced for status update may appear to be hoarded while actually quietly making unreported progress toward completion.

IGP: integrated graphics processor. A CPU and IGP together on one chip or in one package share power budget and memory bandwidth. IGPs tend to be low performance compared to discrete GPUs. For more see

Jacobi check: computation of a Jacobi symbol value. Applied to the LL interim full residue, it has a 50% chance of detecting a software or hardware error affecting the LL iterations, which allows resuming from an earlier saved state and trying again. It is independent of earlier error detection methods. If applied after every iteration, it would have a 75% chance of detecting error. It is too computationally expensive for that. It is typically applied every several hours. It is not applicable to TF or PRP. It is also somewhat applicable to P-1 but quite expensive to do there. See also
The check is built into LL code of recent versions of gpuowl, Mlucas, mprime, prime95, except that LL has been dropped from gpuowl versions V7.0 and higher.

latency: the time from beginning to end of a specific computing task. Reducing latency can come at the cost of lowered throughput.

LL: Lucas-Lehmer test which is a conclusive primality test for Mersenne numbers if performed accurately. Without the Jacobi check, the LL test observed residue error rate is about 2% historically, increasing with run time. Beginning with seed value 4 is standard.

LLDC: Repeating the LL on the same exponent, ideally by a different participant, shift, software, and hardware, but same seed value, in an attempt to verify the first LL test by producing a matching final Res64 value. See DC and double checking above. If either LL test has an error affecting the final result, a triple check (or more) becomes necessary.

Mx: see (1) below.

Mx: in the GIMPS context,
(1) the Mersenne number with exponent x. For example, M7 would represent 27-1 = 127, the fourth entry in the list of known Mersenne primes
(2) the xth known Mersenne prime. Note this usage, while historically common, both conflicts with (1) and creates ambiguity.
Generally the ambiguity can be resolved by context, or noting suffix values significantly greater than that for the highest known Mersenne prime exponent, #51*, p=82589933, very likely indicate exponent, not sequence number. The ambiguity remains for small prime x for which 2x-1 is also prime; 2 3 5 7 13 17 19 31.
To reduce ambiguity, and the need for every reader to reason out which is meant, please avoid the second usage going forward.

Mpx or Mp#x: the x-th known Mersenne prime in sorted order. Its ranking is regarded as provisional and it is followed customarily by an asterisk * or sometimes a question mark "?" if verification of all others below its exponent has not yet completed. For example, Mp48 but Mp49* and above currently, since double-checking has not yet completed up to 74207281 as of 6 October 2021. Mp#4 is 27-1 = 127.
(There is not to my knowledge, usage of the analogous Mnx, which would be the Mersenne number (composite or prime) given by the x-th prime exponent.)

milestone: finding a new Mersenne prime or proving a known Mersenne prime is the nth in the sorted set is considered a major GIMPS milestone. Completing an additional range of million exponent value, in first test or successful double-check, is considered a minor milestone. There's a web page for those.

necropost: post in an existing thread which has had no posts in the past several months or years. It's mildly discouraged. Sometimes it's useful, as in cases where the hardware technology or number theory have advanced in a relevant way.

numerology: unsound or baseless mathematical reasoning. See also

OEIS: the Online Encyclopedia of Integer Sequences. OEIS includes (Mersenne primes) and (exponents of Mersenne primes)

offset: an integer number of bit positions to which the seed or base is initially shifted. Shifting the computations differently causes the expected numerical errors in floating point FFT computations to affect the operands differently. Different, pseudorandomly selected, and nonzero shift counts are preferred.

OpenCL: "OpenCL is a framework for writing programs that execute across heterogeneous platforms consisting of central processing units, graphics processing units, digital signal processors, field-programmable gate arrays and other processors or hardware accelerators." It is a standard supported by AMD, Intel, NVIDIA, and ARM.

OpenGL: "a cross-language, cross-platform application programming interface (API) for rendering 2D and 3D vector graphics. The API is typically used to interact with a graphics processing unit (GPU), to achieve hardware-accelerated rendering."
(while reportedly OpenGL has been used to perform nongraphics computations, there is no known GIMPS application using OpenGL)

overclock: running computing hardware faster than the rated frequency. This tends to reduce reliability of the output, reduce performance per watt-hour, and can reduce hardware lifetime.

P-1: A factoring technique for finding factors with the special property that they are one greater than a number with many small prime factors; a standard part of the TF, P-1, primality test, and verification sequence applied in the GIMPS hunt for new Mersenne primes

P+1: A factoring technique for finding factors with the special property that they are one less than a number with many small prime factors. This method is thought to be too unproductive to be a part of the GIMPS hunt for new Mersenne primes, but may be useful in searching for additional factors of smaller Mersenne numbers, as an additional capability introduced in mprime / prime95 v30.6

poach: work on and report a result for an exponent and computation type combination that was currently assigned to someone else. This is frowned upon, both because it can irritate the person with the assignment, and because it often results in wasteful duplication of computation.

PrimeNet: the API, software, and server that enables automated issuance of assignments and submission of results from GIMPS client software such as mprime and prime95 and updating of a central GIMPS database.

Proof:computations accompanying a PRP test, after preserving residues at selected points, creating a file allowing independent verification of the PRP test's completion and correctness. Generating a proof requires (a) software that supports it (currently sufficiently recent versions of gpuowl, mprime, prime95), (b) configured to use sufficient available disk space to hold all the needed temporary files, (c) a PRP run not LL, (d) from (almost) the beginning of the test. Proof-capable software is required before the iterations reach ~p/2proof_power.

PRP: Probably prime test, a primality test that is conclusive when performed accurately and indicating composite, and highly likely to have identified a prime if it indicates probably prime, but requiring a conclusive primality test, such as LL, be run to confirm the prime. PRP tests are much more reliable than LL, when guarded by the excellent GEC error detection. There are several different PRP test types. For final residues to match for the same exponent, tests must use the same PRP test type and seed. See residue type.

QA: quality assurance, the act of testing computations on a wide variety of exponents, fft lengths in primality testing or P-1, bit levels in TF, unusual hardware, and reporting in detail any anomalies encountered, and testing one software against another for matching results, relying on the likelihood they are both right rather than both wrong in such a way as to give matching results

relative prime, or relatively prime:Two (or more) numbers are said to be relatively prime if they have no factors in common, i.e. their greatest common divisor is 1.

: 64-bit residue, the least 64 bits of a larger number, usually represented in ASCII hexadecimal in console output

reserve: obtain an assignment for a specific work type on a specific exponent, from a server. This may be a user action manually by a web page, or automatic action through the PrimeNet API by prime95/mprime application, or a helper program for other software, or through gpu72 scripts, etc. While holding an assignment for primality testing, prime95/mprime may determine additional TF is needed, or P-1 is needed, and perform that if it is beneficial, as determined by a computation indicating a probability of computation time savings.

residue type: in PRP, there are at least 6 identified residue types. For the residues to match, the residue types must match. Those obtaining manual assignments for PRP DC should take care to ensure they reserve assignments that fit in residue type the capability of the software they intend to use to run the double-checks. For PRP, type 1 is standard. For PRP-CF, type 5 is standard. See also

scaling: how run-time or memory requirements vary with exponent or other relevant variables for a given software application. Number theory provides lower limits to what is possible scaling. Testing by sampling at widely spaced variable values provides an indication of achieved scaling.

Schrodinger number: a number which someone has claimed is prime and has also claimed is composite, without proof in either case, or has claimed that the discovery of a prime factor is irrelevant. Analogous to Schrodinger's cat. Sort of like an illegitimate child; it's not their doing either. Two examples.

seed: in LL testing, the starting value to which the LL iterations are successively applied. Standard seed for GIMPS LL primality testing is 4. Other values, such as 10 or 2/3, are valid for finding a Mersenne prime, but are not used, since differing seed values make full-residue values, res2048 values, and res64 values for composites not match between tests of differing seed values, with serious negative consequences for double-checking. In PRP testing, the starting value on which successive powerings are performed. Standard seed for GIMPS PRP primality testing is 3.

shift: an alternate term for offset

smooth: having small factors. A number that has no factors greater than n is called n-smooth. For example, 42 = 2 * 3 * 7 is 7-smooth.

straggler: exponent that is late in completing, delaying reaching minor milestones.

TC: triple check. When a doublecheck residue does not match the first-test residue, for the same test type and seed, a tie breaker is needed, so a third check is run, and occasionally a fourth, etc, until matches are obtained, with acceptably low error counts. Around 2% of LL tests get triple checks. (More if the exponent is much larger than wavefront exponents or the hardware is unusually slow.) A much lower fraction of PRP tests get triple checks since the Gerbicz error check performed along the way in most PRP tests makes PRP test results much more reliable.

TF: trial factoring

throughput: the long term rate of production of computational results. See also latency

TPU: "Tensor Processing Units (TPUs) are Google’s custom-developed application-specific integrated circuits (ASICs) used to accelerate machine learning workloads. TPUs are designed from the ground up with the benefit of Google’s deep experience and leadership in machine learning."
There is currently no known GIMPS application that makes use of TPUs for exponents of current interest.

tuning: adjusting various parameters in the command line or ini file or configuration file of an application, usually to increase throughput

underclock: running computing hardware slower than the rated frequency. This tends to increase reliability of the output, increase performance per watt-hour, and can cause equipment to run at lower temperatures and extend hardware lifetime.

undervolt: operating computing hardware at lower than the nominal voltage, to reduce power dissipation. The reduced power at a given clock rate may in turn allow additional overclocking.

unreserve: give up an assignment for a specific work type on a specific exponent. Assignments that would take too long to run and expire before completion should be promptly unreserved, to avoid long delays and eventual waste of effort on tasks not practical to complete. Unreserving is a user action, typically done via a web page that is user-account-specific.

verifiable delay function. The function that made the low cost PRP proof generation and independent certification possible, and in turn, allowed reducing DC work required per PRP test to less than 0.5% from 100% of the effort of a first test.

verification: generally, confirming correctness of a first primality test by repetition independently. More recently, performing the independent "CERT" check beginning with a PRP proof file that has been processed by the PrimeNet server and downloaded to a CERT-capable client.

wavefront: the range of exponents, for a given computation type, where the bulk of the activity is occurring. It moves upward over time. See for a definition and some historical values

wildcat: (proposed; not in common use) work on tasks without assignments to anyone. This is relatively low but not zero risk in P-1 or primality testing above ~350M. TF this way is both more common and more problematic. This is sometimes less than accurately referred to as poaching, which is activity in conflict with assignments to others. Possible synonyms or variants are squat, or "working off the books" (which is also a term for tax evasion, so has a negative connotation not justified in context, and it's just too long and wordy); pioneer if working somewhat ahead of the wavefront; scout if working substantially ahead of the wavefront; explorer if working all over the range or beyond 1G.

worktodo entry: a single line of text in a GIMPS application's worktodo file, describing a work task. Supported formats and work types vary somewhat among the various GIMPS applications. Most also support comment lines, which can be thought of as null work, just text for the user. See for what the various forms of worktodo entries look like, and which work types are supported by which applications.

zombie: (proposed; not in common use) exponent or system that is making little or no progress. It could be the hardware is slow, the assignment follows another being worked on, the error rate and retry is high, or the application has stopped or the system was upgraded and application not relaunched. See also straggler.

Top of reference tree:

Last fiddled with by kriesel on 2022-09-15 at 20:53 Reason: minor format & content edits, add assignment background link to assignment
kriesel is offline  
Old 2019-12-20, 16:55   #6
kriesel's Avatar
Mar 2017
US midwest

22·32·191 Posts
Default Older reference thread

There is a reference thread from 2003 by PrimeMonster at

Top of reference tree:

Last fiddled with by kriesel on 2019-12-20 at 16:58
kriesel is offline  
Old 2020-01-16, 14:44   #7
kriesel's Avatar
Mar 2017
US midwest

22·32·191 Posts
Default Best practices

In general, what would constitute best practices for GIMPS effort? My proposal:
  1. Use the most efficient algorithm and software for the task and hardware (example: gpuowl not cllucas for AMD GPU primality testing; gpuowl not CUDALucas on most NVIDIA GPUs; v6.11-380 is quite efficient and versatile); first primality tests with PRP with GEC & proof generation, not PRP without either, much less LL. DON'T RUN LL FIRST TESTS IF YOU CAN AVOID IT! (In my testing, the productivity of gpuowl PRP/GEC with proof is over triple that of CUDALucas LL with consequent need of LLDC & occasional LLTC etc. on the identical hardware!)
  2. Select the most efficient hardware for the task (examples: use an RTX20xx for TF, use a good CPU or Radeon VII for PRP or P-1; use GPUs with relatively greater single precision performance compared to double precision for TF, those with relatively greater double precision performance compared to single precision for PRP, LL or P-1 factoring. Don't use CPUs for production TF, since GPUs are so much more effective at it.) Most recent NVIDIA consumer GPUs (RTX20xx, GTX16xx, RTX30xx; those with high SP/DP performance ratios, 16:1, 32:1, 64:1) are more effective for TF than for other GIMPS computation types; most NVIDIA Tesla GPUs and AMD GPUs with low SP/DP ratios (16:1 or lower) are suitable for PRP, P-1, or LLDC. Radeon VII is 4:1, some Teslas are 2:1. CPUs are typically DP:SP 0.5 to 2, and should not be used for TF if it can be avoided.
  3. Use a very recent version of the chosen software. Temper that with what is most efficient and reliable. With the latest version sometimes come the latest bugs. Sometimes there are speed regressions. Benchmark.
  4. Use the most effective settings for the given software (examples: PRP with GEC and proof generation whenever practical as a first test, not PRP without proof generation, definitely not LL first tests if PRP/GEC/proof can be done; optimal throughput by benchmarking prime95/mprime for throughput versus number of cores/worker versus various fft lengths, analyze, and reconfigure when appropriate). PRP with proof provides about double the effective throughput for the project vs. PRP without proof .
  5. Use judiciously chosen inputs, for reasonable run time and feasibility of completing the task accurately. A run that takes years is not only likely to expire before completion, it is unlikely to complete accurately unless it is protected by the GEC.
  6. Always log the runs. Some applications have logging built in. Others will need tee or redirection. Run command-line GIMPS applications in terminal sessions that will remain after program termination, so that you have time to read error messages. Some programs employ both stdout and stderr, and redirection for both may be useful.
  7. Tune the application for the specific software version and hardware involved and exponents & other parameters being run. (For example, mfaktc's optimal tune may differ for the same hardware for differing exponent or bit level.)
  8. Run at least one double-check, and a memory test, per piece of hardware (CPU or GPU), to test the reliability of the hardware & software combination, before beginning production running. Only run GIMPS work on systems confirmed to be reliable.
  9. Regularly review the logs for errors. Either manually or with an analysis tool.
  10. Repeat double-check or self-test and memory test at least annually. Hardware reliability changes over time. Generally for the worse. Remedy unreliable hardware, by repair, or by removing it from GIMPS service.
  11. Re-tune if substantially changing the exponents being run, or when a new version of the software is deployed.
  12. Reserve assignments first. Then expeditiously finish and report them. Don't poach the assignments of others. Don't reserve more than you complete in a reasonable amount of time, ~ a month, less if their expiration is shorter. Don't hoard assignments.
  13. Select work types and assignments appropriately to the capabilities of the hardware and software, so that assignments complete in a reasonable amount of time. (In most cases that will be under two months.)
  14. Contribute at least about 1/5 of your primality testing effort as double-checking, while a double-checking backlog remains.
  15. Prioritize advancing the GIMPS wavefronts of TF, P-1, first primality testing, and verification. This is the most effective at advancing the state of knowledge about Mersenne primes.
  16. When P-1 factoring, use the full GPU72 bounds given for the exponent at when possible. (That is the most effective strategy while exponents are being both primality tested and verified, as they currently are. And improvements in P-1 factoring performance in prime95 v30.7 & v30.8 and gpuowl v7.x make higher bounds than before productive.)
  17. Be vigilant and relentless about controlling error rate. Use PRP with GEC whenever it fits the work and the hardware. Use CUDALucas for LL only for DC on old GPUs that can't run a current version of Gpuowl with PRP or LLDC. Take corrective measures as required to force mean GEC indicated error rate below 1 error detected and corrected/GPU/month or CPU worker/month. (what's the right error rate threshold here?)
  18. Become familiar with the normal behavior of the GIMPS GPU applications you run. It makes it easier to spot when something is not right.
  19. If making manual additions to worktodo files, err on the side of giving complete information to the program.
  20. For project efficiency, use PRP with GEC and proof generation whenever practical, not mere PRP or LL. This greatly reduces verification effort, by ~99+% yet provides greater confidence in the result than matching res64 values from double checks.
  21. Have fun!
  22. What else?
see also

Top of reference tree:

Last fiddled with by kriesel on 2022-04-24 at 14:16 Reason: added to #1 & #6 & #7 & #16, & minor edits elsewhere
kriesel is offline  
Old 2022-01-02, 14:32   #8
kriesel's Avatar
Mar 2017
US midwest

22×32×191 Posts
Default 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:
  1. How to launch a command line session that will remain for review until the user intentionally closes it.
  2. How to obtain help in general or specific to one command or command option from the command line.
  3. Proper syntax of essential commands and some of their options.
  4. How to obtain a directory listing.
  5. How to display and modify file and directory ownership and permissions, and which are needed.
  6. How to create, move, or delete a file or directory.
  7. How to change current directory.
  8. How to edit an existing text file and save the changed file to the same filename or different filename.
  9. How to launch a program from the command line.
  10. How to redirect program input and output.
  11. The difference between stdout and stderr.
  12. How to download and install a program.
  13. How and whether to obtain, install, and use a tee program.
  14. The difference between append and overwrite.
  15. How to find, obtain, and install third-party utilities.
  16. How to obtain and install OS updates.
  17. How to obtain and install graphics card, OpenCL or CUDA drivers.
  18. How to check that a graphics card, OpenCL, or CUDA driver is installed and functional.
  19. Basic troubleshooting techniques.
  20. How to create and use and modify batch files on Windows or shell scripts on Linux.
  21. How to check and document OS & version, application and version, program inputs and outputs, etc.
  22. 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.
  23. 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.)
  24. What all the preceding mean.
(Are there more?)

Some possible resources for learning these things can be found online, such as
There are also "help" on Windows and "man" on Linux.

Top of reference tree:

Last fiddled with by kriesel on 2022-01-02 at 19:20
kriesel is offline  
Old 2022-02-10, 18:04   #9
kriesel's Avatar
Mar 2017
US midwest

22·32·191 Posts
Default 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:
Ten years:

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, 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:

Last fiddled with by kriesel on 2022-09-15 at 20:30 Reason: correction re status of Mlucas current version
kriesel is offline  
Old 2022-02-17, 12:55   #10
kriesel's Avatar
Mar 2017
US midwest

1ADC16 Posts
Default Nick's Basic Number Theory Series

This series comes well recommended.

Basic Number Theory 1 & 2
Basic Number Theory 3: gcd, lcm & Euclid's algorithm
Basic Number Theory 4: a first look at prime numbers
Basic Number Theory 5: rationals & intro to modular arithmetic
Basic Number Theory 6: functions and the Chinese Remainder Theorem
Basic Number Theory 7: idempotents and Euler's function
Basic Number Theory 8: equiv. relations and Fermat's little theorem
Basic Number Theory 9: a primality test and a cryptosystem
Basic Number Theory 10: complex numbers and Gaussian integers
Basic Number Theory 11: Gaussian primes
Basic Number Theory 12: sums of two squares
Basic Number Theory 13: Pythagorean triples and a few Diophantine equations
Basic Number Theory 14: a first look at groups
Basic Number Theory 15: Lagrange's theorem, cyclic groups and modular arithmetic
Basic Number Theory 16: unit group structure in modular arithmetic
Basic Number Theory 17: quadratic reciprocity
Basic Number Theory 18: quadratic equations modulo n
Basic Number Theory 19: Introducing rings and fields
Basic Number Theory 20: polynomials
Basic Number Theory 21: ideals and homomorphisms
Basic Number Theory 22: Euclidean domains, PIDs and UFDs

Top of reference tree:

Last fiddled with by kriesel on 2022-02-17 at 12:56
kriesel is offline  
Old 2022-09-07, 01:58   #11
kriesel's Avatar
Mar 2017
US midwest

153348 Posts
Default Assignments background

(once-checked then revised draft; independent reviews requested by PM)

This post is written mainly oriented to activity at or above the wavefront for DC (double check) and below exponent 1G (109). There are other work types such as PRP-CF (probably-prime-cofactor) and low exponent ECM (elliptic curve method factoring), not addressed here.
  1. Assignments are not the same as worktodo entries. Some elements are in common.
  2. Assignments for Mersenne numbers with exponent < 109 come from's PrimeNet server; assignments over limited range above 109 from
  3. Assignments obtained from consist of at least the following elements:
    1. Assignment ID (see also for more detail)
    2. PrimeNet V5 User ID
    3. Date & time assigned
    4. Exponent
    5. Work type, e.g. one of TF (trial factoring), P-1 factoring, LL (Lucas-Lehmer first test), PRP (probably prime first test), Cert (proof completed of complete and accurate PRP), LLDC (Lucas-Lehmer double check), etc.
    6. In the case of primality test assignments (LL, LLDC, PRP), category number at time of assignment
  4. Assignments from do not include Assignment IDs, and use different user identification. Work types are limited to TF or P-1 currently.
  5. Assignments are stored at the PrimeNet server for exponents below 1G (109); TF or P-1 assignments for 1G < exponents <232 are stored at with date but not time.
  6. Assignments are obtained either:
    1. by PrimeNet API for prime95 / mprime or via helper applications for other software, or through, or
    2. "manually". Manual assignments are obtained through or for exponents <1G; from for higher exponent TF or P-1.
    3. Additionally there may be forum threads offering special Cert, P-1, or perhaps other type assignments on occasion. Examples include strategic DC, TC (triple check) & special Certs, or strategic P-1 for DC
  7. Assignment rules for LL and LL DC are described at
  8. While it does not (yet) state so, these also apply to PRP. Note there the information about expiration deadlines.
  9. There's a recent discussion thread of the rationale for assignment categories and rules at
  10. Assignments are completed by reporting a result, or the assignment will eventually expire.
  11. Assignments expire quicker without progress being reported in to the relevant server.
  12. How long primality test assignments have until expiration in either the progress-reported or no-progress-reported case depends on where the assignment stands relative to the category boundaries.
  13. Category boundaries get revised over time as work progresses up the exponent scale.
  14. The server applies later, the expiration rules (category boundaries) that applied at time of assignment issue. After expiration, at reassignment, is when expiration rules get updated for the exponent.
  15. Preferred progression of assignments sequence for a given exponent, somewhat enforced by server assignment issue or nonissue, is:
    1. TF to a sufficient level, performed in ascending bit-level order for a given exponent;
    2. P-1 to sufficient bounds in a single attempt;
    3. Primality test (PRP with proof generation preferred; near-optimal proof power preferred)
    4. Cert (very economical) or DC (much more costly, but required if first test was LL or PRP without successful proof generation & upload & processing). If Cert from first test is not available, the preferred DC type is PRP with proof generation, for a combination of reliability and efficiency.
    5. TC etc as needed. If there is a mismatch between residues of same type primality tests, additional testing will be performed until there is a match of primality test type and residues, or there is a PRP & successful Cert for it. LL once and PRP once does not constitute a verified composite. Differing PRP types do not constitute a verified composite. Same PRP type but differing last 64-bit residues do not constitute a verified composite
    6. In the rare case of a prime initial result, it is more likely than not a computing error. (CUDALucas was notorious for these.) A discovery will not be disclosed on the forum or elsewhere, and the user should not disclose it at all, until a press release is issued after intensive verification by multiple trusted participants with differing hardware and software. See
  16. For a given exponent, only one assignment, of one work type, to one user, may be made and outstanding at a time. So a randomly selected exponent will have zero or one assignment pending.
  17. Work types are mutually exclusive, for obtaining an assignment for a given exponent.
  18. Only progress reported to the relevant server on the given assignment's work type, or in the case of assigned PRP or LL and PrimeNet API connection, reported progress in either primality testing or needed preparatory factoring, matters in regard to delaying possible expiration of an assignment, or updating the exponent's progress status. (I think that a PrimeNet-connected client reporting progress on needed P-1 or TF factoring indicated as needed in the PRP assignment assigned to that same prime95 worker instance will count as progress toward the PRP and delay expiration of the PRP assignment. But GPUs are so much more effective at TF, that performing TF on CPUs should be avoided whenever possible. Also, do PRP, avoid LL.)
  19. The same user or system, manually reporting results on a different work type, but the same exponent, not containing the pending assignment's assignment ID, will NOT count as progress on the current assignment for the exponent or delay the assignment's expiration. If you hold a PRP assignment, it could expire quickly after you manually report TF or P-1 results for the same exponent, because from the point of view of the server, you have reported NO PROGRESS on the PRP assignment, the only assignment existing for the exponent. The required assignment ID would not even be present in mfaktx results output, even if it was present in the mfaktx worktodo entry. (I'm told the server would not process an assignment ID manually inserted into an mfaktc manually reported result, rejecting the result instead. I don't recall testing whether a manually reported result with matching assignment ID manually inserted would be accepted for TF reported for an exponent with a currently pending primality test assignment, or if prime95 P-1 format or mlucas P-1 format with matching assignment ID manually reported would count as assignment progress and delay primality test expiration, the actual assignment. Gpuowl v7.2-53 format P-1 NF result reported manually including the matching assignment ID does not affect the stage/% complete field or the PRP assignment expiration displayed. I think the server should preserve the existing primality test assignment, such as for gpuowl v7.x that may produce a P-1 result long before the PRP result generated from a single assignment.)
  20. Reporting progress via PrimeNet API on a different primality test type than the assigned type will show progress of a different type under the assigned assignment and work type. For example, a user downgrading manually an issued PRP assignment will result in an assignments page showing LL and % progress in the "stage" column of a PRP assignment row. Similarly, if PRP was assigned, but P-1 was needed first, stage will show S1, then S2, then PRP as work progresses.
  21. Reporting a different type primality test result will retire a primality test assignment.
  22. Occasionally we will see that reporting a different work type's result for the same exponent will expire an assignment.
    1. I believe that if TF NF or P-1 NF (no-factor results) expire another work type assignment, it is a server scripting error that should be reported so it can be investigated and resolved.
    2. Reporting a factor-found result (of any method) will expire all assignment types for the exponent. (Thanks James Heinrich.) Presumably that's only for a factor that passes validation at the server, and is a new factor. I think it makes sense for the report of a factor found by any means (TF, P-1, P+1, ECM) to expire a primality test or factoring assignment at the wavefront.
    3. If an expired assignment result is reported in, the server will often reply that the result was unneeded. Or in the case of a primality test it might serve as a useful double-check.
  23. Another cause of early assignment expiration is poaching: running and reporting before them, results for a work type and exponent combination assigned to someone else. Please don't. It wastes computing time and annoys people.
  24. Reporting any TF result will expire the TF assignment, no matter how many bit levels were selected during manual assignment. Run the reserved levels to completion before reporting any of them. Be conservative in how many levels reserved at once, as run time is exponential with level, doubling at each increment.
  25. The server exponent status summaries are date sorted, and can get a bit less readable, by users having reported TF results for an exponent other than in ascending order. Perform and report them in ascending order. 74 then 75 then 76 ... 81 for 100Mdigit, for example. Do not repeat old lower levels that may no longer appear in the summary. You can be sure that 1-63 or whatever were done long ago, whether listed or not.
  26. It's more efficient to do one factoring type at a time on an exponent. But if for some reason you're in a hurry, and run TF and P-1 in parallel on the same exponent, reporting the no-factor-found result before any factor-found may be to your advantage, with the server accepting and crediting more of your work.
  27. Listings of your own assignments can be found at Clicking on column headings in the first list will sort according to that column; clicking the same heading again will reverse the sort order.
  28. Assignments that expire can adversely affect a computer's qualification for lower category primality assignments.
  29. Assignments can be manually unreserved if obtained in error, lost, or likely to expire before completion, the assigned user would like to abandon them, or the assigned user is quitting the project, at

Top of reference tree:

Last fiddled with by kriesel on 2022-09-16 at 07:56
kriesel is offline  
Closed Thread

Thread Tools

Similar Threads
Thread Thread Starter Forum Replies Last Post
prime95-specific reference material kriesel kriesel 14 2022-09-25 17:08
Mfaktc-specific reference material kriesel kriesel 9 2022-05-15 13:21
gpu-specific reference material kriesel kriesel 4 2019-11-03 18:02
Available software and reference info kriesel Information & Answers 3 2019-05-06 16:34
NFS reference 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

Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2022, 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.

≠ ± ∓ ÷ × · − √ ‰ ⊗ ⊕ ⊖ ⊘ ⊙ ≤ ≥ ≦ ≧ ≨ ≩ ≺ ≻ ≼ ≽ ⊏ ⊐ ⊑ ⊒ ² ³ °
∠ ∟ ° ≅ ~ ‖ ⟂ ⫛
≡ ≜ ≈ ∝ ∞ ≪ ≫ ⌊⌋ ⌈⌉ ∘ ∏ ∐ ∑ ∧ ∨ ∩ ∪ ⨀ ⊕ ⊗ 𝖕 𝖖 𝖗 ⊲ ⊳
∅ ∖ ∁ ↦ ↣ ∩ ∪ ⊆ ⊂ ⊄ ⊊ ⊇ ⊃ ⊅ ⊋ ⊖ ∈ ∉ ∋ ∌ ℕ ℤ ℚ ℝ ℂ ℵ ℶ ℷ ℸ 𝓟
¬ ∨ ∧ ⊕ → ← ⇒ ⇐ ⇔ ∀ ∃ ∄ ∴ ∵ ⊤ ⊥ ⊢ ⊨ ⫤ ⊣ … ⋯ ⋮ ⋰ ⋱
∫ ∬ ∭ ∮ ∯ ∰ ∇ ∆ δ ∂ ℱ ℒ ℓ
𝛢𝛼 𝛣𝛽 𝛤𝛾 𝛥𝛿 𝛦𝜀𝜖 𝛧𝜁 𝛨𝜂 𝛩𝜃𝜗 𝛪𝜄 𝛫𝜅 𝛬𝜆 𝛭𝜇 𝛮𝜈 𝛯𝜉 𝛰𝜊 𝛱𝜋 𝛲𝜌 𝛴𝜎𝜍 𝛵𝜏 𝛶𝜐 𝛷𝜙𝜑 𝛸𝜒 𝛹𝜓 𝛺𝜔