mersenneforum.org Problems about PRP proof generation
 Register FAQ Search Today's Posts Mark Forums Read

 2021-06-22, 14:33 #1 Zhangrc   "University student" May 2021 Beijing, China 197 Posts Problems about PRP proof generation Recently I ran a PRP test on M107120777 using proof power 10, taking LOTS of disk space. Also, When I finished the test, It took about an hour to generate the proof file. If I shut down the computer during the process, the proof generation would just run from the start (unlike shutting down in the middle of the LL/PRP test, when it writes a checkpoint file before power off). So I have the following problems: 1. Can Prime95 write temporary checkpoint files during proof generation, especially when it takes more than half an hour? 2. Should CPU credit be given for proof generation? Judging from the time it took, I deserve about 0.9 GHZDays for the proof generation of M107120777; However, the CERT process only cost 0.429 GHZDays (439/2^10?) 3. If the answers are "no," should I use smaller proof power (such as 7 or 8)? I feel that It's not worthy spending so much time allocating disk space, writing proof file and calculating hash, with the risk of shutting down, and no credit given. Last fiddled with by Zhangrc on 2021-06-22 at 14:39
 2021-06-22, 14:51 #2 Viliam Furik     "Viliam Furík" Jul 2018 Martin, Slovakia 5·149 Posts 1. Don't know 2. Don't know 3. Either way, it's not much beneficial to run such exponents with proof power 10. The default 8 is good enough, IMO. Proofs already save a lot of work, using power 10 could be considered inefficient.
 2021-06-23, 06:55 #3 Happy5214     "Alexander" Nov 2008 The Alamo City 23·97 Posts As Viliam said above, the default power is 8. Why are you using power 10 in the first place? Just using the default power should solve your problems. The certification effort saved with a power 10 proof is not worth the extra effort and space for the PRP tester.
2021-06-23, 07:16   #4
Zhangrc

"University student"
May 2021
Beijing, China

3058 Posts

Quote:
 Originally Posted by Happy5214 Why are you using power 10 in the first place? Just using the default power should solve your problems.
Maybe I allocated too much disk space (50GB/worker). I have already written ProofPower=8 from undoc.txt, but it has no effect on the two exponents I'm currently testing.

 2021-06-23, 14:52 #5 kriesel     "TF79LL86GIMPS96gpu17" Mar 2017 US midwest 2×11×277 Posts Proof power 10 is more efficient overall, although it's diminishing returns for exponentially larger disk space, generally available in these days of TB disks. Running proof power 9 or 10 is not wrong. Total effort (of proof generation, server computation, and verification/cert) vs proof power, as % of a full primality test for DC: Code: power effort 8 0.41% (prime95 default) 9 0.24% (0.17% saved vs power 8) 10 0.18% (another 0.06% saved vs power 9) (The above is derived from part of https://www.mersenneforum.org/showpo...45&postcount=4 which summarizes data from George for 100M. Mprime / prime95 support proof powers up to 12. I doubt George would have implemented such high proof powers if they were a bad idea. He also implemented lower powers including an innovative 7x2 for those who are space-constrained. Low proof powers mean much longer Cert runs. A prime95-minimum proof power 5 means the cert is ~3.1% the length of a full DC, ~32 times as long as for power 10.) Last fiddled with by kriesel on 2021-06-23 at 15:39
 2021-06-23, 18:36 #6 Viliam Furik     "Viliam Furík" Jul 2018 Martin, Slovakia 5·149 Posts But if you take into account the time it takes to generate the proof on a slower machine, with proof being run very quickly, I think you will find that total time is longer than if they used power 8, because the tiny amount of saved conputation is not worth it, when the proof file and test are done on a significantly slower machine, than that which runs the certification. I may, however be wrong with my one sentence paragraph.
2021-06-23, 19:19   #7
kriesel

"TF79LL86GIMPS96gpu17"
Mar 2017
US midwest

2×11×277 Posts

Quote:
 Originally Posted by Viliam Furik But if ...
A smaller iteration count (higher power) Certification task is better suited to a slower machine, than a larger iteration count (lower power) cert task, or a much larger full PRP with proof, on the same machine. A power 8 cert for M642589933 on an AVX512 laptop took George ~2 days; power 9 (as the maximum available in the gpuowl version used) would have taken half the iterations, so ~1 day.
The difference between power 8 and power 10 is 0.02% vs 0.08% nominally of a full primality test for proof generation. If the 0.06% difference is significant run time on a system, surely the 100% PRP run time is very large, and the system is probably too slow to be doing production PRP tests.
When proofs must go through the server and certs be issued from there, the user performing the PRP test and proof won't have a way of knowing or controlling whether it's a fast medium or slow system doing the Cert that follows. What matters and is in our control is computational efficiency, as controlled by selecting overall-speed-optimal proof power. Latencies of Certs are practically instant compared to the multiple-year backlog of conventional DC. (Eight-year lags were common; cases of 9 years and higher are known.) Elapsed time does not interest me as much as efficiency. But for the same hardware, overall efficiency helps total elapsed time too.

Last fiddled with by kriesel on 2021-06-23 at 19:34

2021-06-24, 02:54   #8
Zhangrc

"University student"
May 2021
Beijing, China

197 Posts

Quote:
 Originally Posted by kriesel The difference between power 8 and power 10 is 0.02% vs 0.08% nominally of a full primality test for proof generation.
Really? I have the impression that the difference is 0.07% vs 0.3%.

During proof generation of M107120777, I luckily opened another worker (working on M108228649 which has about the same size) to see how much time and work did it cost. I shut the computer down when it was generating hash3. When I restarted my computer, I found that proof generation started all from the beginning. It took me over 45 minutes to finish the proof generation, and when the generation was over, the M108228649 had shown about 0.25% progress. Considering the extra cost of shutting down and rebooting, it should be more than 0.3%.

Maybe you are just referring to CPU time. However, it costs lots of disk time to write, read and check a 14GB file, even on SSD. Also, the proof generation time (and space) grows exponentially with proof power, with no credit given. So I intend to give up power 10. I consider using power 8 or 9 instead.

Last fiddled with by Zhangrc on 2021-06-24 at 03:10

 2021-06-24, 05:57 #9 kriesel     "TF79LL86GIMPS96gpu17" Mar 2017 US midwest 10111110011102 Posts You are arguing elapsed time, against iteration-equivalent numbers I quoted from George. Elapsed wall clock time doesn't matter, throughput does. We have multitasking OSes. Last fiddled with by kriesel on 2021-06-24 at 05:59
 2021-06-24, 09:53 #10 LaurV Romulan Interpreter     "name field" Jun 2011 Thailand 22×5×17×29 Posts Please do not confuse generating the proof with verifying the proof. On slow hard disks, generating the proof files MAY take a LONG while. Like anteposters said, use P95 default power, and all your problems are solved. Or, if you really have a slow, or full, HDD, go lower, 7 or 6. On colab instances we usually go 6 or 5.
2021-06-29, 04:16   #11
Happy5214

"Alexander"
Nov 2008
The Alamo City

77610 Posts

If someone wants to use up a ton of their own disk space to speed up the proof process later on, that's their prerogative, and we welcome the help, but most users need not bother with that. Higher proof powers would certainly help with the 100M+ digit ranges.

Quote:
 Originally Posted by Zhangrc Maybe I allocated too much disk space (50GB/worker). I have already written ProofPower=8 from undoc.txt, but it has no effect on the two exponents I'm currently testing.
The proof power is set at the start of the test, since it has to know which interim residues to collect along the way, and it cannot be changed mid-way.

Last fiddled with by Happy5214 on 2021-06-29 at 04:16

 Similar Threads Thread Thread Starter Forum Replies Last Post R.D. Silverman Factoring 14 2013-03-16 00:38 Jeff Gilchrist Hardware 9 2012-10-18 10:49 Kees Lounge 27 2006-12-12 08:04 R.D. Silverman Hardware 11 2005-08-08 19:09 hbock Lone Mersenne Hunters 40 2004-09-08 18:59

All times are UTC. The time now is 11:50.

Wed Jan 19 11:50:18 UTC 2022 up 180 days, 6:19, 0 users, load averages: 1.81, 1.37, 1.32