mersenneforum.org  

Go Back   mersenneforum.org > Great Internet Mersenne Prime Search > Software

Reply
 
Thread Tools
Old 2021-11-05, 16:56   #100
techn1ciaN
 
techn1ciaN's Avatar
 
Oct 2021
U. S. / New York, NY

9416 Posts
Default

Is there any way to continue to P-1 stage 2 even if a factor was found in stage 1? I'm thinking of how the MFakt[x] applications will stop immediately after finding a factor by default, but can be configured to finish out the bit level anyway.

I Ctrl+F'd "p-1" in undoc.txt but didn't find anything that seemed relevant.
techn1ciaN is offline   Reply With Quote
Old 2021-11-05, 17:23   #101
kriesel
 
kriesel's Avatar
 
"TF79LL86GIMPS96gpu17"
Mar 2017
US midwest

1BBF16 Posts
Default

Quote:
Originally Posted by techn1ciaN View Post
Is there any way to continue to P-1 stage 2 even if a factor was found in stage 1?
I recommend against doing that routinely. It diverts computing time away from productively advancing GIMPS' primary goal, of finding new Mersenne primes. One factor is enough to eliminate a Mersenne number from further consideration.
From https://www.mersenneforum.org/showpo...8&postcount=22 in the reference info,
a single worktodo entry can be added back if you want to explore pursuing additional P-1 factors, of the form
Pminus1=[<AID>,|N/A,|<nul>]<k>,<b>,<n>,<c>,<B1>,<B2>[,"comma-separated-list-of-known-factors"]

Last fiddled with by kriesel on 2021-11-05 at 17:23
kriesel is offline   Reply With Quote
Old 2021-11-05, 19:09   #102
lisanderke
 
"Lisander Viaene"
Oct 2020
Belgium

109 Posts
Default

Quote:
Originally Posted by Prime95 View Post
The stage two 100% complete error should be harmless. I'm looking into why it occurs.

I've updated to 30.7 b7 (in hopes of doing faster P-1 work) and I seem to have encountered the 100% complete error.

I'm currently re-doing P-1 for exponents that previously had only B1 done from https://www.mersenne.ca/pm1_worst.php.

The error started popping up when worker #1 went from stage 1 -> stage 2 and forced worker #2 (already in stage 2) to restart using new memory allocation. (2 workers, 3 cores each)
When I noticed the erroneous logging behavior I promptly restarted Prime95 but worker #2 continued logging 100% complete throughout the assignment. This affected expected completion date, it constantly assumed the assignment on worker #2 would complete in that minute.

The assignment finished within its usual time frame and was registered successfully!
Thought this was worth reporting since no-one had specified they were able to recreate this bug.
Below are some screenshots attached. Unfortunately I did not capture the moment the erroneous behavior started.


Also, I've queued up a little under 300 exponents spread over these 2 workers and whenever the Test->Status... window is opened my Prime95 window freezes up for 10 seconds before the status window is shown. It sometimes enters "Prime95 not responding" before the status window is shown.
Not sure if this is expected behavior with this many exponents queued in Prime95 or if this is a bug.
Attached Thumbnails
Click image for larger version

Name:	Screenshot 2021-11-05 194947.png
Views:	75
Size:	77.1 KB
ID:	26053   Click image for larger version

Name:	Screenshot 2021-11-05 194929.png
Views:	79
Size:	84.2 KB
ID:	26054   Click image for larger version

Name:	Screenshot 2021-11-05 200312.png
Views:	76
Size:	92.3 KB
ID:	26055  

Last fiddled with by lisanderke on 2021-11-05 at 19:17 Reason: Typos
lisanderke is offline   Reply With Quote
Old 2021-11-05, 19:38   #103
lisanderke
 
"Lisander Viaene"
Oct 2020
Belgium

109 Posts
Default

I assume this error is as easily reproducible for others as it is for me . Please disregard previous post about 100% complete error. (See file attached)
Attached Thumbnails
Click image for larger version

Name:	Screenshot 2021-11-05 203612.png
Views:	79
Size:	82.0 KB
ID:	26056  
lisanderke is offline   Reply With Quote
Old 2021-11-05, 20:26   #104
kruoli
 
kruoli's Avatar
 
"Oliver"
Sep 2017
Porta Westfalica, DE

100110101012 Posts
Default

Quote:
Originally Posted by techn1ciaN View Post
Is there any way to continue to P-1 stage 2 even if a factor was found in stage 1?
Yes, look here:
Quote:
Originally Posted by kruoli View Post
[...] Now, you need to set it to Stage1GCD=-1.
kruoli is offline   Reply With Quote
Old 2021-11-05, 21:46   #105
techn1ciaN
 
techn1ciaN's Avatar
 
Oct 2021
U. S. / New York, NY

22·37 Posts
Default

Quote:
Originally Posted by kriesel View Post
I recommend against doing that routinely. It diverts computing time away from productively advancing GIMPS' primary goal, of finding new Mersenne primes.
It is my personal preference to turn in "complete" assignments. I use StopAfterFactor=0 with MFaktC for this reason.

In re: "wasting" cycles, my laptop runs standalone P-1 full time. The automatically set bounds seem to give me a chance of a bit less than 5% to find a P-1 factor for any given exponent. We might assume that half of these (not empirical; just my spitball) would be found within stage 1, and continuing to stage 2 in these cases would represent (approximately) only half the effort of a full P-1 run. So, unless my math or my assumptions are grossly wrong, continuing to stage 2 for every P-1 run should not cost me much more than a percent of my total computing time. I think I'm fine with that.
techn1ciaN is offline   Reply With Quote
Old 2021-11-05, 22:35   #106
kriesel
 
kriesel's Avatar
 
"TF79LL86GIMPS96gpu17"
Mar 2017
US midwest

7,103 Posts
Default

For test case PFactor=aid,1,2,107181343,-1,76,1
bounds for 1 test saved 403000, 15491000, determined by prime95
runtime for 1 saved est 6:09 (h:mm); 10/31/21 15:16 start s1, 16:52 s1 gcd done, 20:17 s2 & gcd done, actual 5:01 elapsed, 7.2853 GHD, NF
S1/s2 time ratio 1:36 vs 3:25; 96 min vs 205 min, <1/2
S1/total was 96/301 = 31.9% of total P-1 runtime, less than a third. Had a factor been found in stage 1 and stage 2 skipped, it would have been more than 3 times as productive as forcing stage 2 to run despite an already-found factor that eliminated the possibility of the same Mersenne number being prime. Saving over 3 hours, which could be applied effectively to following assignments.
Over the course of a year, 365*24*60/301 = 1746 exponents could be P-1 factored to such bounds. Odds of factoring was estimated as 3.36%. That's ~59 factored. Suppose 29 factors are found in stage 1, AND stage 2 skipped for those. 29 * 205 = 5945 minutes saved (over 4 days), enough to P-1 factor both stages for ~20 more in the same time, ~1.1% more.
Our rare few top programmers work hard to squeeze out the last few % of performance. Seems a shame to give it up so readily. But your kit your call.

Last fiddled with by kriesel on 2021-11-05 at 22:38
kriesel is offline   Reply With Quote
Old 2021-11-06, 01:36   #107
Prime95
P90 years forever!
 
Prime95's Avatar
 
Aug 2002
Yeehaw, FL

22×43×47 Posts
Default

build 8 now available
Prime95 is offline   Reply With Quote
Old 2021-11-09, 19:35   #108
nordi
 
Dec 2016

53 Posts
Default

RESOLVED
Turns out I mis-edited my worktodo.txt to read "Pminus1=N/A,2,11996279,-1" instead of "Pminus1=N/A,1,2,11996279,-1". That makes mprime crash. I guess that shouldn't happen either, but at least it is a crash that is easy to reproduce.





I had a crash today on build 5, so I updated to build 8 and got another crash after 45 minutes of running. Mprime's last words were
Quote:
[Worker #7 Nov 9 18:59] ECM on M304331: curve #40 with s=4906294320036236, B1=250000, B2=TBD
[Worker #2 Nov 9 18:59] Stage 1 complete. 25612656 transforms, 1 modular inverses. Total time: 890.428 sec.
[Worker #2 Nov 9 18:59] Available memory is 11000MB.
[Worker #8 Nov 9 18:59] M12000979 stage 2 complete. 1350170 transforms. Total time: 1907.737 sec.
[Worker #8 Nov 9 18:59] Stage 2 GCD complete. Time: 2.086 sec.
[Worker #8 Nov 9 18:59] M12000979 completed P-1, B1=400000, B2=21200000, Wi8: 37EA4735
[Comm thread Nov 9 18:59] Sending result to server: UID: nordi/sweet16, M12000979 completed P-1, B1=400000, B2=21200000, Wi8: 37EA4735
[Comm thread Nov 9 18:59]
[Worker #8 Nov 9 18:59]
mprime: malloc.c:3829: _int_malloc: Assertion `chunk_main_arena (bck->bk)' failed.
The first crash had also happened just after the Comm thread was sending a result.

Previously, mprime ran crash free for weeks. What has changed is that I now have 4 (very memory hungry) workers on P-1 work, which I previously never did. Note that the "Available memory is 11000MB" is due to a per-worker config that limits most worker to 11GB (and some to 18GB). There is no "out of memory" message in the system log.

Right now, mprime crashes when starting the 8th worker, which is a P-1 worker. The dmesg tool shows
Quote:
[7615784] traps: mprime[25587] general protection ip:53ef89 sp:7f0f7d430900 error:0 in mprime[400000+21db000]
[7615892] traps: mprime[25715] general protection ip:53ef89 sp:7ff38a78e900 error:0 in mprime[400000+21db000]
[7615970] traps: mprime[25968] general protection ip:53ef89 sp:7f8963d30900 error:0 in mprime[400000+21db000]
[7616156] traps: mprime[26076] general protection ip:53ef89 sp:7fb1ab0ac900 error:0 in mprime[400000+21db000]

Last fiddled with by nordi on 2021-11-09 at 19:56 Reason: Resolved
nordi is offline   Reply With Quote
Old 2021-11-10, 05:02   #109
Zhangrc
 
"University student"
May 2021
Beijing, China

22·67 Posts
Default

Quote:
Originally Posted by kriesel View Post
Odds of factoring was estimated as 3.36%. That's ~59 factored. Suppose 29 factors are found in stage 1, AND stage 2 skipped for those.
I calculated in https://www.mersenne.ca/prob.php?exp...3000&b2=403000 that the stage 1 only probability is 1.15%, so you should suppose that only 20 (59*0.0115/0.0336) are found in stage 1.

Quote:
Originally Posted by kriesel View Post
Our rare few top programmers work hard to squeeze out the last few % of performance
It's never the lase few percent. People are continuing to explore new factoring methods and optimizing the code.

Last fiddled with by Zhangrc on 2021-11-10 at 05:06
Zhangrc is offline   Reply With Quote
Old 2021-11-11, 00:18   #110
kriesel
 
kriesel's Avatar
 
"TF79LL86GIMPS96gpu17"
Mar 2017
US midwest

7,103 Posts
Default

Quote:
Originally Posted by Zhangrc View Post
It's never the lase few percent. People are continuing to explore new factoring methods and optimizing the code.
Actually there are indications of diminishing returns over the life of the prime95 software. P+1 factoring is irrelevant to wavefront GIMPS work. Performance improvements early on were 5%, 15% or even sometimes 40% on the same hardware.
The program uses a large percentage of the theoretical maximum memory bandwidth for specific hardware.

Last fiddled with by kriesel on 2021-11-11 at 00:19
kriesel is offline   Reply With Quote
Reply

Thread Tools


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


Fri Dec 9 15:50:16 UTC 2022 up 113 days, 13:18, 0 users, load averages: 1.16, 1.21, 1.17

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.

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