mersenne.ca "GPU72" target

tuckerkao · 2022-12-16, 00:30

Pminus1 with the recommended bounds from GPU72 typically take less time to complete.

kriesel · 2022-12-16, 01:06

Quote:

Originally Posted by tuckerkao

Pminus1 with the recommended bounds from GPU72 typically take less time to complete.

Running smaller P-1 bounds than optimal for probable time saved by avoiding some primality tests would be quicker for the P-1 but slower on average for the P-1 plus the needed PRP. It seems you're missing the big picture.

chalsall · 2022-12-17, 04:19

Quote:

Originally Posted by James Heinrich

Yes, doing things worse is usually faster. You can lower the bounds to near-zero and be done almost instantly, but that doesn't really benefit anyone. Please let Prime95 decide what bounds should be used based on the exponent status and your available RAM.

Just for the record... As usual, tuckerkao has presented inaccurate information.

GPU72 doesn't have recommended bounds for P-1. It actually gives Pfactor lines with overlly aggressive "Tests saved" values (it shouldn't be 2 anymore; more like 1.3), and let's the Prime95/mprime client choose the correct bounds.

I just wanted to correct the tuckerkao's misrepresentation of reality.

tuckerkao · 2022-12-17, 04:45

Quote:

Originally Posted by chalsall

GPU72 doesn't have recommended bounds for P-1.

Who's the GPU72 that presents the recommendations for the TF bit depth and P-1 bounds(very specific numbers for B1 and B2) on this page - https://www.mersenne.ca/exponent/108377323

Comparison of Actual, Primenet, GPU72, Difference.

Maybe this GPU72 is not your group.

Quote:

Originally Posted by Prime95

The small FFT torture test does not test RAM as much as a blend torture test

I think it's almost certain that you've found the cure. After the memory speed tuned down, Prime95 is no longer experiencing errors for at least several hours.

James Heinrich · 2022-12-17, 04:49

Quote:

Originally Posted by chalsall

GPU72 doesn't have recommended bounds for P-1

No, that's probably my fault -- if you look at the mersenne.ca page for any exponent (e.g. 168455141) there's the "Actual", "PrimeNet" and "GPU72" lines. The TF bitlevel is probably pretty close to what GPU72 recommends, the bounds are a vague approximation of what a machine might pick for that exponent with 1 test saved. But those numbers are not endorsed by GPU72, so I should probably rename my data to something other than "PrimeNet" and "GPU72" (which only applies to the TF level).

James Heinrich · 2022-12-17, 16:22

Quote:

Originally Posted by Andrew Usher

it's surely his settings that caused it to run hot in the first place
CPUs don't normally reach that temperature with default settings
Most people including me have a max CPU temp around 70 C.

Historically, yes, but Zen4 is different, AMD has said they're designed to run at up to 95°C continuously.
But hitting 90+C at 156W indicates a cooling problem (small/inadequate cooler).
I went big with my system (Arctic Liquid Freezer II 420 AIO) and the 7950X is still happy to get above 90°C, especially when running small FFTs, but it takes 230+W of power to do so (nominal TDP is 170W for the 7950X, but it's happy to exceed that up to its thermal limit).

I have queued up those 6 suspect P-1s for re-do (on my non-7950X system so it'll take a few days). Running to a bit higher bounds (especially B2).

James Heinrich · 2022-12-17, 16:35

Quote:

Originally Posted by James Heinrich

I should probably rename my data to something other than "PrimeNet" and "GPU72"

I have decided to remove the "PrimeNet" line entirely, since both the TF level and B1/B2 are irrelevant. I now have "Actual" and "Target", and the "Difference" line makes more sense than it did before.

It's easy to ignore inconsistencies because "it's always been that way", so thanks chalsall for pointing it out.

Andrew Usher · 2022-12-17, 18:43

I was not aware of those specifics, just saying that his symptoms sounded like they could be heat-related. It is not just the CPU that can be affected and cause instabilities. At least it's one thing to try in addressing the problem.

I think your last change may have been hasty. Although it certainly was no help to have two (not much) different P-1 levels there, the Primenet TF level is not wholly obsolete - the server still uses it. More seriously, I think you changed something you didn't intend, because all the bounds at higher exponents have doubled. Only just above 1M is it about the same; going higher it rapidly approaches twice the B1 and B2 that the 'GPU72' was. For example, the recommendation at the OBD level, which Kriesel accepted, was 17M/1G, and is now an unreasonable 32M/2G. At Tucker Kao's level, it has also doubled, and I hope this isn't at attempt to get him to change because while his B2 would have stood doubling (because of the new 30.8 algorithm) his B1 certainly shouldn't be. I would recommended reverting until you figure out what happened (tests saved value changed?) as there certainly should have been no change for most or all exponents. (By the way, the optimums for sub-wavefront exponents are still relevant as they should be used before PRP tests of cofactors if there's been no P-1 or significant ECM yet - a common situation.)

kriesel · 2022-12-17, 18:54

And the target values ought not increase, for exponents beyond the reach of mprime v30.8, which maxes out at 1169M on AVX512, 920M on AVX2, 596M on AVX. The polynomial multiplication implementation is only present in mprime/prime95 v30.8 and up, not lower versions, and not at all in CUDAPm1, Gpuowl, or Mlucas released P-1 implementations.

Andrew Usher · 2022-12-17, 19:02

His bounds are still computed based on the 'old' algorithm (linear/prime-pairing) as always, so _that_ is not the issue. While we are on this subject I'd also advise that 'target' values be removed for exponents below 1M and above 2^32: the former are meaningless and based on a TF value much too far from the actual; the latter are not possible of attainment in the foreseeable future.

James Heinrich · 2022-12-17, 19:15

Quote:

Originally Posted by Andrew Usher

I think you changed something you didn't intend, because all the bounds at higher exponents have doubled.

It was intentional. The P-1 bounds/probability algorithm (of which mersenne.ca uses a simplified version that ignores available RAM and therefore tends to underestimate B2) intrinsically outputs a "minimum", "balanced", "maximum" pair of B1/B2. The former GPU72 line showed "balanced", the new "Target" line shows "maximum". Running the 168M exponent on 32GB Prime95 selects a lower B1 and higher B2 than shown.

Short answer is that P-1 bounds selection is complex and dependent not only on exponent and TF but also available RAM. Actual bounds to be used should always be selected by Prime95/gpuowl/whatever and not based on the rough ballpark estimates on mersenne.ca

Here are a selection on bounds and probabilities selected across a wide range of exponents by Prime95 v30.8b17 with 45GB allocated (targeting 1.0 tests saved):

Code:

Prime95 v30.8b17, 45GB RAM, 1.0 tests saved:
Pfactor=N/A,1,2,1000003,-1,60,1    = B1=  11000, B2= 26088000, 5.13%
Pfactor=N/A,1,2,1333357,-1,60,1    = B1=  13000, B2= 25856000, 5.62%
Pfactor=N/A,1,2,1777823,-1,61,1    = B1=  18000, B2= 27546000, 5.71%
Pfactor=N/A,1,2,2370451,-1,63,1    = B1=  22000, B2= 30218000, 5.01%
Pfactor=N/A,1,2,3160607,-1,64,1    = B1=  31000, B2= 24500000, 4.91%
Pfactor=N/A,1,2,4214173,-1,65,1    = B1=  31000, B2= 30967000, 4.73%
Pfactor=N/A,1,2,5618903,-1,66,1    = B1=  45000, B2= 40113000, 5.00%
Pfactor=N/A,1,2,7491893,-1,67,1    = B1=  59000, B2= 40842000, 4.96%
Pfactor=N/A,1,2,9989191,-1,68,1    = B1=  80000, B2=102211000, 5.65%
Pfactor=N/A,1,2,13318951,-1,68,1   = B1= 108000, B2=101248000, 6.20%
Pfactor=N/A,1,2,17758603,-1,69,1   = B1= 141000, B2=136199000, 6.36%
Pfactor=N/A,1,2,23678147,-1,70,1   = B1= 181000, B2=152884000, 6.34%
Pfactor=N/A,1,2,31570867,-1,71,1   = B1= 228000, B2=156349000, 6.21%
Pfactor=N/A,1,2,42094513,-1,72,1   = B1= 291000, B2=156084000, 6.08%
Pfactor=N/A,1,2,56126053,-1,73,1   = B1= 372000, B2=167054000, 6.01%
Pfactor=N/A,1,2,74834741,-1,74,1   = B1= 463000, B2=161188000, 5.83%
Pfactor=N/A,1,2,99779663,-1,76,1   = B1= 562000, B2=154313000, 5.14%
Pfactor=N/A,1,2,133039553,-1,77,1  = B1= 685000, B2=145504000, 4.95%
Pfactor=N/A,1,2,177386113,-1,78,1  = B1= 891000, B2=147436000, 4.86%
Pfactor=N/A,1,2,236514827,-1,79,1  = B1=1085000, B2=145788000, 4.71%
Pfactor=N/A,1,2,315353107,-1,80,1  = B1=1357000, B2=154771000, 4.63%
Pfactor=N/A,1,2,420470833,-1,82,1  = B1=1609000, B2=138241000, 4.03%
Pfactor=N/A,1,2,560627831,-1,83,1  = B1=2042000, B2=146766000, 3.97%

2022-12-16, 00:30	#1
tuckerkao "Tucker Kao" Jan 2020 Head Base M168202123 2⁴×5×11 Posts	mersenne.ca "GPU72" target Pminus1 with the recommended bounds from GPU72 typically take less time to complete.

Similar Threads
Thread	Thread Starter	Forum	Replies	Last Post
Is "mung" or "munged" a negative word in a moral sense?	Uncwilly	Lounge	15	2020-04-14 18:35
Aouessare-El Haddouchi-Essaaidi "test": "if Mp has no factor, it is prime!"	wildrabbitt	Miscellaneous Math	11	2015-03-06 08:17
Would Minimizing "iterations between results file" may reveal "is not prime" earlier?	nitai1999	Software	7	2004-08-26 18:12
trial factoring of "small" mersenne numbers	antiroach	Lone Mersenne Hunters	6	2003-07-16 23:35

2022-12-17, 18:43	#8
Andrew Usher Dec 2022 3×13² Posts	I was not aware of those specifics, just saying that his symptoms sounded like they could be heat-related. It is not just the CPU that can be affected and cause instabilities. At least it's one thing to try in addressing the problem. I think your last change may have been hasty. Although it certainly was no help to have two (not much) different P-1 levels there, the Primenet TF level is not wholly obsolete - the server still uses it. More seriously, I think you changed something you didn't intend, because all the bounds at higher exponents have doubled. Only just above 1M is it about the same; going higher it rapidly approaches twice the B1 and B2 that the 'GPU72' was. For example, the recommendation at the OBD level, which Kriesel accepted, was 17M/1G, and is now an unreasonable 32M/2G. At Tucker Kao's level, it has also doubled, and I hope this isn't at attempt to get him to change because while his B2 would have stood doubling (because of the new 30.8 algorithm) his B1 certainly shouldn't be. I would recommended reverting until you figure out what happened (tests saved value changed?) as there certainly should have been no change for most or all exponents. (By the way, the optimums for sub-wavefront exponents are still relevant as they should be used before PRP tests of cofactors if there's been no P-1 or significant ECM yet - a common situation.)

2022-12-17, 18:54	#9
kriesel "TF79LL86GIMPS96gpu17" Mar 2017 US midwest 2⁴×3×163 Posts	And the target values ought not increase, for exponents beyond the reach of mprime v30.8, which maxes out at 1169M on AVX512, 920M on AVX2, 596M on AVX. The polynomial multiplication implementation is only present in mprime/prime95 v30.8 and up, not lower versions, and not at all in CUDAPm1, Gpuowl, or Mlucas released P-1 implementations.

2022-12-17, 19:02	#10
Andrew Usher Dec 2022 3·13² Posts	His bounds are still computed based on the 'old' algorithm (linear/prime-pairing) as always, so _that_ is not the issue. While we are on this subject I'd also advise that 'target' values be removed for exponents below 1M and above 2^32: the former are meaningless and based on a TF value much too far from the actual; the latter are not possible of attainment in the foreseeable future.