Prime95 30.8 (big P-1 changes, see post #551)

[kriesel]

[Dec 6 10:23] Assuming no factors below 2^0 and 10 primality tests saved if a factor is found.

Nearby exponents have been TF to 2⁶⁸. Ten saved seems excessive.
859433 and other low exponents Mersenne primes' early histories are not entirely available in the databases, and many have been polluted with later unnecessary work submissions years after discovery and verification and announcement as Mersenne primes.
For example, 859433, found prime 1994, has a trivial B1=B2=30 entry in 2004. Is there a way to purge such entries and to lock the known primes to prevent future spurious additions?
Consider M127 https://www.mersenne.ca/exponent/127, which shows P-1 attempts to B1=1E6, B2=1E8, by 2 accounts.
(Max possible least factor if it were not prime would be ~2^63.5 ~ 10^19.1; kmax ~ 51,353,613,485,562,134.)
also, M521 https://www.mersenne.ca/exponent/521
M4423 https://www.mersenne.ca/exponent/4423
M9689 https://www.mersenne.ca/exponent/9689
M11213 https://www.mersenne.ca/exponent/11213
M19937 https://www.mersenne.ca/exponent/19937 (3 by same account a year apart)
M86243 https://www.mersenne.ca/exponent/86243
M110503 https://www.mersenne.ca/exponent/110503
M132049 https://www.mersenne.ca/exponent/132049
M216091 https://www.mersenne.ca/exponent/216091
M859433 https://www.mersenne.ca/exponent/859433
M1257787 https://www.mersenne.ca/exponent/1257787 (8 entries to the same 56 bits TF by 4 users, 1 repeating 4 times)
M1398269 https://www.mersenne.ca/exponent/1398269 (6 P-1 entries ranging over 19 years with the last being smaller bounds)
M2976221 https://www.mersenne.ca/exponent/2976221
M3021377 https://www.mersenne.ca/exponent/3021377 (many P-1 attempts and many duplicate TF attempts, 3 userids 1 computerid v4_computers)
M6972593 https://www.mersenne.ca/exponent/6972593 (including bad LL res64 years later)
M13466917 https://www.mersenne.ca/exponent/13466917
M20996011 https://www.mersenne.ca/exponent/20996011
M24036583 https://www.mersenne.ca/exponent/24036583
M25964951 https://www.mersenne.ca/exponent/25964951
M32582657 https://www.mersenne.ca/exponent/32582657
M37156667 https://www.mersenne.ca/exponent/37156667
M42643801 https://www.mersenne.ca/exponent/42643801
M43112609 https://www.mersenne.ca/exponent/43112609
M74207281 https://www.mersenne.ca/exponent/74207281
What we don't find there, are PRP/GEC/proof & Cert. If such were done, they would address the very slight possibility of bugs in LL software giving a false positive. (LL is definitive, if performed without error, but there is no ironclad proof of correctness built in. PRP is "only probably prime", but has an extremely reliable error check and proof of complete correct performance of the math. A composite result would be definitive.) But of all things, PRP/PROOF is refused by the server for known Mersennes, while other result types are let through. PRP for known Mersennes are blocked by the manual submission web page, as is a quick P-1 for it. PrimeNet API still passes B1=50000, B2=1M P-1 for M859433 performed by prime95 even though it is useless. But PrimeNet API blocks submission of a PRP/proof of M216091 from the same prime95 instance. Seems backwards.

[chalsall]

Originally Posted by alpertron

We do not know if these people will accept doing only P-1. Some people only wants to perform PRP because of the prizes. So they would use multithreading to run as many PRP as possible.

Please do note that many participants of GIMPS choose a particular work-type because of their personal preferences.

Some specifically *don't* want to find a new MP for various (valid) reasons, but are more than happy to assist with eliminating candidates with the less expensive TF and (now, seriously less expensive) P-1 which still helps ensure their kit is sane.

[kriesel]

Originally Posted by chalsall

the less expensive TF and (now, seriously less expensive) P-1 which still helps ensure their kit is sane.

There is little in the way of error detection in TF or P-1. How does this help ensure the hardware is sound?

[chalsall]

Originally Posted by kriesel

There is little in the way of error detection in TF or P-1. How does this help ensure the hardware is sound?

Core dumps (on stable code; 30.8b3 is still alpha). Temperatures going out of spec. Processes taking longer than expected to execute. Etc, etc, etc...

[petrw1]

All PMinus1 assignments allowed Prime95 to choose B2. i.e. 600000,0,75
All P1 work is in the 2xM Ranges
The first 4 PCs have Stage 2 time about 25% less than Stage 1 time.
Only the last; the biggest with AVX-512 has B1 time = B2 time.
Correct me if I'm wrong but I believe since Stage 2 is SOOO much faster now the goal is to have B2 Time >= B1 Time.
But I leave these metrics and the final say to those really in the know.
Thanks George et al.

i5-2500 12GB RAM
S1: 42 Min; S2: 30 Min
B1=600K,B2=133xB1

i5-3570 6.4GB
S1=41 Min; S2=31 Min
B1=700K,B2=82x

i5-3570  14GB
S1=36 Min; S2=28 Min
B1=600K,B2=168x

i5-3570K 5GB
S1=44 Min; S2=35 Min
B1=800K,B2=68x

i7-7820x 24.5GB
S1=8.5 Min; S2=8.5 Min
B1=600K,B2=256x

[axn]

Originally Posted by petrw1

Correct me if I'm wrong but I believe since Stage 2 is SOOO much faster now the goal is to have B2 Time >= B1 Time.

Not exactly. The goal is to use B1 & B2 such that : delta B1 / delta p = delta B2 / delta p, where delta B1 (resp. delta B2) is the cost of increasing B1 (resp. B2) by a small amount, and delta p is the corresponding increase in probability. Now, in practice, this might mean that the new stage 2 ends up taking more time than stage 1. Although... if we go by GMP-ECM, then stage 2 should take less time than stage 1

However, George is still tweaking the cost model to correctly estimate the stage 2 run time. Until then, we shouldn't read too much into these ratios.

My guess is, as long as the times are within a factor of two from each other (one way or the other), we're not far off from optimal.

[Prime95]

This build fixes the deadlocking issue. It also adds save files for stage 2 (minimally tested), interruptable stage 2, and some stage 2 output (the percent complete is not fully accurate).

Highest priority next is making polymult more cache friendly.

Windows 64-bit: https://mersenne.org/ftp_root/gimps/p95v308b4.win64.zip
Linux 64-bit: https://mersenne.org/ftp_root/gimps/...linux64.tar.gz

[SethTro]

Originally Posted by axn

Not exactly. The goal is to use B1 & B2 such that : delta B1 / delta p = delta B2 / delta p, where delta B1 (resp. delta B2) is the cost of increasing B1 (resp. B2) by a small amount, and delta p is the corresponding increase in probability. Now, in practice, this might mean that the new stage 2 ends up taking more time than stage 1. Although... if we go by GMP-ECM, then stage 2 should take less time than stage 1

However, George is still tweaking the cost model to correctly estimate the stage 2 run time. Until then, we shouldn't read too much into these ratios.

My guess is, as long as the times are within a factor of two from each other (one way or the other), we're not far off from optimal.

+1

This does assumes you're only doing P-1 once. For small exponents some of us (you especially) save the backup files and re-run with larger bounds so where stage 1 is completely reused while stage 2 is throw away each time. This means it can be "optimal" (for finding a factor in minimum time) to add a little extra time in stage 1 where that extra probability is amortized over several runs.

[petrw1]

Running Stage 1 my cores average about 5 degrees hotter than Stage 2.
Stage 1: 70-78
Stage 2: 65-73

[petrw1]

Originally Posted by axn

Not exactly. The goal is to use B1 & B2 such that : delta B1 / delta p = delta B2 / delta p, where delta B1 (resp. delta B2) is the cost of increasing B1 (resp. B2) by a small amount, and delta p is the corresponding increase in probability. Now, in practice, this might mean that the new stage 2 ends up taking more time than stage 1. Although... if we go by GMP-ECM, then stage 2 should take less time than stage 1

However, George is still tweaking the cost model to correctly estimate the stage 2 run time. Until then, we shouldn't read too much into these ratios.

My guess is, as long as the times are within a factor of two from each other (one way or the other), we're not far off from optimal.

Correct my logic if required:

I looked at the current and new B1/B2.
For example 400K/400K to 600K/100M.
I used prob.php here to compute the current odds of the current B1=B2 and he new higher B1=B2.
This should give me the odds that I find the factor in Stage 1.
Then I checked the time for Stage 1 and computed Minutes/Percent increase.

Then I Computed the odds for the new B1 and B2.
The increase should give the odds that I find the factor in Stage 2.
Again time and compute Minutes/Percent Increase Stage 2.

If for example it takes 15 minutes per 1% increase in Stage 1 and 10 Minutes per 1% in Stage 2 isn't it more beneficial to increase B2 more than B1?

[R. Gerbicz]

Originally Posted by Prime95

D is the traditional step size incrementing from B1 to B2. 120 is eulerphi(1050)/2.
...
A single polynomial multiply evaluates the first polynomial at 403-2*120+1 points. Thus advancing toward B2 in steps of 1050 * 164 = 172200.

If the init cost is small compared to the total cost then why wouldn't use more prime:
In this case if you'd include 11 also, then you need to evaluate in 1/11 less points with 10 times more inits (assuming the same parameters), and note that here you'd still use a symmetrical polynom since c and m-c is coprime at the same time. You can pack the points evenly because eulerphi(n)|eulerphi(m) if n|m.