20210622, 14:33  #1 
"University student"
May 2021
北京
3·11 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 20210622 at 14:39 
20210622, 14:51  #2 
"Viliam Furík"
Jul 2018
Martin, Slovakia
2·3·101 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. 
20210623, 06:55  #3 
"Alexander"
Nov 2008
The Alamo City
2×347 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.

20210623, 07:16  #4 
"University student"
May 2021
北京
3·11 Posts 
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.

20210623, 14:52  #5 
"TF79LL86GIMPS96gpu17"
Mar 2017
US midwest
12431_{8} 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) Last fiddled with by kriesel on 20210623 at 15:39 
20210623, 18:36  #6 
"Viliam Furík"
Jul 2018
Martin, Slovakia
2×3×101 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. 
20210623, 19:19  #7 
"TF79LL86GIMPS96gpu17"
Mar 2017
US midwest
11×491 Posts 
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 overallspeedoptimal proof power. Latencies of Certs are practically instant compared to the multipleyear backlog of conventional DC. (Eightyear 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 20210623 at 19:34 
20210624, 02:54  #8  
"University student"
May 2021
北京
3×11 Posts 
Quote:
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 20210624 at 03:10 

20210624, 05:57  #9 
"TF79LL86GIMPS96gpu17"
Mar 2017
US midwest
1010100011001_{2} Posts 
You are arguing elapsed time, against iterationequivalent numbers I quoted from George. Elapsed wall clock time doesn't matter, throughput does. We have multitasking OSes.
Last fiddled with by kriesel on 20210624 at 05:59 
20210624, 09:53  #10 
Romulan Interpreter
Jun 2011
Thailand
31×311 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. 
20210629, 04:16  #11 
"Alexander"
Nov 2008
The Alamo City
2·347 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.
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 midway. Last fiddled with by Happy5214 on 20210629 at 04:16 
Thread Tools  
Similar Threads  
Thread  Thread Starter  Forum  Replies  Last Post 
Next generation NFS sieving  R.D. Silverman  Factoring  14  20130316 00:38 
Nextgeneration heatsink has no fan at all  Jeff Gilchrist  Hardware  9  20121018 10:49 
Respect for the old generation  Kees  Lounge  27  20061212 08:04 
Next Generation?  R.D. Silverman  Hardware  11  20050808 19:09 
Next Generation : 62 bit+  hbock  Lone Mersenne Hunters  40  20040908 18:59 