Prime95 v30.4/30.5/30.6

Prime95 · 2021-01-04, 02:32

Prime95 version 30.5 build 2 is available.

I consider this pretty stable software. Those doing P-1 and ECM work should upgrade. First time PRP testers can consider upgrading for the minor speed boost doing P-1 required prior to some first-time assignments.

From whatsnew.txt:

Code:

1) Faster P-1 stage 2.
2) Faster ECM stage 1 and stage 2.
3) Gwnum library overhauled.  Many functions deprecated.  Replaced by more
powerful gwmul3.  New functions that compute (a+b)*c and (a-b)*c with less
memory accesses.  Faster conversion to and from binary.
4) ECM and P-1 can find the best B2 value for the amount of memory prime95
is allowed to use.  For ECM, this happens when the worktodo.txt line sets
B2=100*B1 which is the default assignment from the PrimeNet server.  For P-1, the
best B2 is chosen when the worktodo.txt line specifies the trial factoring depth.
  For example, "Pminus1=1,2,20000003,-1,500000,0,70" chooses the best B2
bound for B1=500000 given that M20000003 has been trial factored to 2^70.

Download links:
Windows 64-bit: https://mersenne.org/ftp_root/gimps/p95v305b2.win64.zip
Linux 64-bit: https://mersenne.org/ftp_root/gimps/...linux64.tar.gz
FreeBSD 64-bit: https://mersenne.org/ftp_root/gimps/...SD11-64.tar.gz
Source: https://mersenne.org/ftp_root/gimps/...5b2.source.zip
Windows 32-bit: https://mersenne.org/ftp_root/gimps/p95v305b2.win32.zip
Linux 32-bit: https://mersenne.org/ftp_root/gimps/...linux32.tar.gz
Windows Service 64-bit: https://mersenne.org/ftp_root/gimps/...64.service.zip
Windows Service 32-bit: https://mersenne.org/ftp_root/gimps/...32.service.zip

You can find info on the first 4 v30.4 builds as well as some questions and answers on new features starting here in the 20M thread

Please report any bugs you may find.

Prime95 · 2021-01-04, 02:33

1) After ECM stage 2 memory is not freed back to the OS in Linux leading to process killed due to out-of-memory. Fixed in build 6.
2) Continuing from an old P-1 save file in stage 2 crashes. Fixed in build 6.
3) Rare P-1 and ECM infinite loops during stage 2 init (well, technically until another worker exits stage 2). Fixed in build 6.
4) PRP on 1435648^131072+1 hangs. Fixed in build 6.
5) Memory corruption and crash possible when ECM chose N^2 modular inverse pooling (occurs when available stage 2 memory is very low). Fixed in build 7.
6) Possible crash bug in stage 2 init when initial stage 2 plan used too much memory. Fixed in build 9.
7) There were no small all-complex FFTs defined for Zen architecture. Thus, ECM on small Fermats gave a "cannot initialize FFT" error. Fixed in 30.5 build 1.
8) PRP roundoff errors during the last 50 iterations are possible (for a small range of exponents below the FFT limit). Fixed in 30.5 build 1.
9) Interrupting P-1 in stage 2, then changing worktodo.txt to a higher B1 and restarting could cause a crash. Fixed in 30.5 build 2.
10) Torture testing is broken!! Fixed in 30.6 build 4

lycorn · 2021-01-04, 12:46

I have not yet installed Build 5, so the following observation relates to Build 4 (and possibly 3). I don´t think it will make a difference, though.

I have Prime95 running 24/7, and it has ever been running pretty smoothly on my quad core i5-7400 at default settings. I installed v30.4b2 just before Christmas and later upgraded to build 3 and then 4, as they were being made available. Everything ok, except for two times now I happened to note Prime95 had died while I was away from the computer. No messages on screen, the small green square had simply vanished and there was no trace of the process in Task Manager..
Digging Windows logs, I found that on the two occasions (first one on the 29th of December, second on the 3rd of January), the cause was an Application Error, said application being Prime95, with an Exception Code 0xc0000005. This code refers to a Address Violation, i.e., the program appears to have used non allocated memory and hence was shut down by the OS. I did a SFC and found no errors, and saw no other occurences of this error for a really long time (never on this machine, actually).
Apart from this, the new version seems to be pretty stable and have already found some ECM factors, both on windows and Linux (I´m running it on several colab instances where, by the way, I didn´t (yet?) have this problem).
Any ideas/thoughts/suggestions?
Note: Upon installing build 3 and then 4, I got a message from the OS to confirm I was really willing to run the exe file, as its origin was not confirmed/trusted. I am not running any AV, just Windows Defender.

UBR47K · 2021-01-04, 14:54

I'm noticing a small speed decrease with ECM on M1277 (even with PracSearch=1) compared to 30.3b6 on Haswell i5.

Can someone confirm this? (I'm using OutputIterations=30000000)
30.3b6:

Code:

M1277 curve 2 stage 1 at prime 4520437637 [59.47%]. Time: 9.504 sec.
M1277 curve 2 stage 1 at prime 4522699141 [59.50%]. Time: 9.598 sec.

30.4 with PracSearch=1 (default gives around 10.xxx sec)

Code:

M1277 curve 1 stage 1 at prime 178990073 [2.35%]. Time: 9.711 sec.
M1277 curve 1 stage 1 at prime 181260257 [2.38%]. Time: 9.712 sec.

PhilF · 2021-01-04, 15:16

Quote:

Originally Posted by UBR47K

I'm noticing a small speed decrease with ECM on M1277 (even with PracSearch=1) compared to 30.3b6 on Haswell i5.

Are you using Prime95 or mprime? Several of us, including myself, have noticed minor slowdowns like that in mprime, triggered by simply stopping and restarting the program.

So for linux at least, I would suggest that valid time comparisons can be made only if performed after a fresh reboot of the system it's running on.

UBR47K · 2021-01-04, 15:34

Quote:

Originally Posted by PhilF

Are you using Prime95 or mprime? Several of us, including myself, have noticed minor slowdowns like that in mprime, triggered by simply stopping and restarting the program.

So for linux at least, I would suggest that valid time comparisons can be made only if performed after a fresh reboot of the system it's running on.

Using mprime here. You're right, the timings are a bit different after another run.

I'm hitting another issue right now, mprime gets killed by OOM:

Code:

...
[Worker #4 Jan 4 15:24] M1277 curve 1 stage 1 at prime 333859213 [4.39%]. Time: 9.595 sec.
[Worker #1 Jan 4 15:24] Stage 1 complete. 6467614 transforms, 1 modular inverses. Time: 324.497 sec.
[Worker #1 Jan 4 15:24] Optimal B2 is 154*B1 = 38500000.
[Worker #4 Jan 4 15:24] M1277 curve 1 stage 1 at prime 336129743 [4.42%]. Time: 9.594 sec.
[Worker #1 Jan 4 15:24] D: 4620, relative primes: 6955, stage 2 primes: 2325683, pair%=92.66
[Worker #1 Jan 4 15:24] Stage 2 uses 5270MB of memory, 2 FFTs per prime pair, 3-mult modinv pooling, pool size 7693.
[Worker #4 Jan 4 15:24] M1277 curve 1 stage 1 at prime 338402387 [4.45%]. Time: 9.722 sec.
[Worker #1 Jan 4 15:24] Stage 2 init complete. 196757 transforms, 1 modular inverses. Time: 10.625 sec.
[Worker #4 Jan 4 15:25] M1277 curve 1 stage 1 at prime 340669547 [4.48%]. Time: 9.713 sec.
[Worker #4 Jan 4 15:25] M1277 curve 1 stage 1 at prime 342940799 [4.51%]. Time: 9.674 sec.
[Worker #4 Jan 4 15:25] M1277 curve 1 stage 1 at prime 345207923 [4.54%]. Time: 9.672 sec.
[Worker #4 Jan 4 15:25] M1277 curve 1 stage 1 at prime 347478463 [4.57%]. Time: 9.672 sec.
[Worker #4 Jan 4 15:25] M1277 curve 1 stage 1 at prime 349751357 [4.60%]. Time: 9.672 sec.
[Worker #4 Jan 4 15:25] M1277 curve 1 stage 1 at prime 352022999 [4.63%]. Time: 9.672 sec.
[Worker #4 Jan 4 15:25] M1277 curve 1 stage 1 at prime 354290843 [4.66%]. Time: 9.673 sec.
[Worker #4 Jan 4 15:26] M1277 curve 1 stage 1 at prime 356560163 [4.69%]. Time: 9.671 sec.
[Worker #4 Jan 4 15:26] M1277 curve 1 stage 1 at prime 358833499 [4.72%]. Time: 9.672 sec.
[Worker #4 Jan 4 15:26] M1277 curve 1 stage 1 at prime 361107037 [4.75%]. Time: 9.672 sec.
[Worker #4 Jan 4 15:26] M1277 curve 1 stage 1 at prime 363374651 [4.78%]. Time: 9.672 sec.
[Worker #4 Jan 4 15:26] M1277 curve 1 stage 1 at prime 365644387 [4.81%]. Time: 9.671 sec.
[Worker #4 Jan 4 15:26] M1277 curve 1 stage 1 at prime 367912399 [4.84%]. Time: 9.672 sec.
[Worker #1 Jan 4 15:27] Stage 2 complete. 2672527 transforms, 1 modular inverses. Time: 132.611 sec.
[Worker #1 Jan 4 15:27] Stage 2 GCD complete. Time: 0.044 sec.
[Worker #1 Jan 4 15:27] 
[Worker #1 Jan 4 15:27] ECM on M615749: curve #10 with s=8879663910729420, B1=250000, B2=TBD
[Worker #4 Jan 4 15:27] M1277 curve 1 stage 1 at prime 370186381 [4.87%]. Time: 9.653 sec.
[Worker #3 Jan 4 15:27] Stage 1 complete. 6467614 transforms, 1 modular inverses. Time: 356.077 sec.
[Worker #3 Jan 4 15:27] Optimal B2 is 154*B1 = 38500000.
[Worker #3 Jan 4 15:27] D: 4620, relative primes: 6955, stage 2 primes: 2325683, pair%=92.66
[Worker #3 Jan 4 15:27] Stage 2 uses 4921MB of memory, 2 FFTs per prime pair, 3-mult modinv pooling, pool size 7693.
Killed

Specs: i5-4690K, 2x4GB DDR3 RAM

4 Workers, 1 Core each:

Code:

[Worker #1]
ECM2=N/A,1,2,615749,-1,250000,25000000,330

[Worker #2]
ECM2=N/A,1,2,579331,-1,250000,25000000,330

[Worker #3]
ECM2=N/A,1,2,588893,-1,250000,25000000,330

[Worker #4]
ECM2=N/A,1,2,1277,-1,7600000000,7600000000,1

PhilF · 2021-01-04, 17:10

I don't remember if the P-1/ECM memory allocation refers to per worker or not.

If it does, then you can't have more than one worker doing stage 2 at a time since you have only 8GB of total memory, unless you lower the memory allocation to 1GB per worker.

nordi · 2021-01-04, 19:29

I tried out the PracSearch parameter and compared the perfomance of stage 1 in 30.4b5 against version 29.8, using my Ryzen 3950X (=Zen2 architecture):

M1277

PracSearch=1 52.7s
PracSearch=7 57.0s
version 29.8 55.6s

M10,061

PracSearch=1 24.5s
PracSearch=7 24.2s
PracSearch=14 25.1s
version 29.8 24.6s

M100,069

PracSearch=7 33.3
PracSearch=10 32.9
PracSearch=14 33.1
version 29.8 37.5s

M1,000,003

PracSearch=7 55.3
PracSearch=14 55.8
version 29.8 69.5s

Considering the measurements aren't super precise, it seems PracSearch=7 is a very good choice overall, except for extremely small exponents like M1277. With correct PracSearch parameter, the new version is always faster in stage 1. Very, very nice!

ixfd64 · 2021-01-04, 19:37

Quote:

- deprecate Brent Suyama (more efficient to put that effort into a larger B1)

Is there a way to optionally enable the Brent–Suyama extension? Or has the feature been removed from the code entirely?

nordi · 2021-01-04, 19:45

Quote:

Originally Posted by UBR47K

I'm hitting another issue right now, mprime gets killed by OOM:

I was also running into OOM problems when testing earlier builds of 30.4. They were supposed to be fixed in the new version, though. Which operating system are you using?

Prime95 · 2021-01-04, 21:25

Quote:

Originally Posted by ixfd64

Is there a way to optionally enable the Brent–Suyama extension? Or has the feature been removed from the code entirely?

See undoc.txt. Please run a test on a known B-S factor.

2021-01-04, 19:29	#8
nordi Dec 2016 2²×5×7 Posts	I tried out the PracSearch parameter and compared the perfomance of stage 1 in 30.4b5 against version 29.8, using my Ryzen 3950X (=Zen2 architecture): M1277 PracSearch=1 52.7s PracSearch=7 57.0s version 29.8 55.6s M10,061 PracSearch=1 24.5s PracSearch=7 24.2s PracSearch=14 25.1s version 29.8 24.6s M100,069 PracSearch=7 33.3 PracSearch=10 32.9 PracSearch=14 33.1 version 29.8 37.5s M1,000,003 PracSearch=7 55.3 PracSearch=14 55.8 version 29.8 69.5s Considering the measurements aren't super precise, it seems PracSearch=7 is a very good choice overall, except for extremely small exponents like M1277. With correct PracSearch parameter, the new version is always faster in stage 1. Very, very nice!

2021-01-04, 02:32	#1
Prime95 P90 years forever! Aug 2002 Yeehaw, FL 8678₁₀ Posts	Prime95 v30.4/30.5/30.6 Prime95 version 30.5 build 2 is available. I consider this pretty stable software. Those doing P-1 and ECM work should upgrade. First time PRP testers can consider upgrading for the minor speed boost doing P-1 required prior to some first-time assignments. From whatsnew.txt: Code: 1) Faster P-1 stage 2. 2) Faster ECM stage 1 and stage 2. 3) Gwnum library overhauled. Many functions deprecated. Replaced by more powerful gwmul3. New functions that compute (a+b)c and (a-b)c with less memory accesses. Faster conversion to and from binary. 4) ECM and P-1 can find the best B2 value for the amount of memory prime95 is allowed to use. For ECM, this happens when the worktodo.txt line sets B2=100B1 which is the default assignment from the PrimeNet server. For P-1, the best B2 is chosen when the worktodo.txt line specifies the trial factoring depth. For example, "Pminus1=1,2,20000003,-1,500000,0,70" chooses the best B2 bound for B1=500000 given that M20000003 has been trial factored to 2^70. Download links: Windows 64-bit: https://mersenne.org/ftp_root/gimps/p95v305b2.win64.zip Linux 64-bit: https://mersenne.org/ftp_root/gimps/...linux64.tar.gz FreeBSD 64-bit: https://mersenne.org/ftp_root/gimps/...SD11-64.tar.gz Source: https://mersenne.org/ftp_root/gimps/...5b2.source.zip Windows 32-bit: https://mersenne.org/ftp_root/gimps/p95v305b2.win32.zip Linux 32-bit: https://mersenne.org/ftp_root/gimps/...linux32.tar.gz Windows Service 64-bit: https://mersenne.org/ftp_root/gimps/...64.service.zip Windows Service 32-bit: https://mersenne.org/ftp_root/gimps/...32.service.zip You can find info on the first 4 v30.4 builds as well as some questions and answers on new features starting here in the 20M thread Please report any bugs you may find. Last fiddled with by Prime95 on 2021-03-21 at 05:57*

2021-01-04, 02:33	#2
Prime95 P90 years forever! Aug 2002 Yeehaw, FL 21E6₁₆ Posts	1) After ECM stage 2 memory is not freed back to the OS in Linux leading to process killed due to out-of-memory. Fixed in build 6. 2) Continuing from an old P-1 save file in stage 2 crashes. Fixed in build 6. 3) Rare P-1 and ECM infinite loops during stage 2 init (well, technically until another worker exits stage 2). Fixed in build 6. 4) PRP on 1435648^131072+1 hangs. Fixed in build 6. 5) Memory corruption and crash possible when ECM chose N^2 modular inverse pooling (occurs when available stage 2 memory is very low). Fixed in build 7. 6) Possible crash bug in stage 2 init when initial stage 2 plan used too much memory. Fixed in build 9. 7) There were no small all-complex FFTs defined for Zen architecture. Thus, ECM on small Fermats gave a "cannot initialize FFT" error. Fixed in 30.5 build 1. 8) PRP roundoff errors during the last 50 iterations are possible (for a small range of exponents below the FFT limit). Fixed in 30.5 build 1. 9) Interrupting P-1 in stage 2, then changing worktodo.txt to a higher B1 and restarting could cause a crash. Fixed in 30.5 build 2. 10) Torture testing is broken!! Fixed in 30.6 build 4 Last fiddled with by Prime95 on 2021-05-01 at 20:53

2021-01-04, 12:46	#3
lycorn "GIMFS" Sep 2002 Oeiras, Portugal 2×11×73 Posts	I have not yet installed Build 5, so the following observation relates to Build 4 (and possibly 3). I don´t think it will make a difference, though. I have Prime95 running 24/7, and it has ever been running pretty smoothly on my quad core i5-7400 at default settings. I installed v30.4b2 just before Christmas and later upgraded to build 3 and then 4, as they were being made available. Everything ok, except for two times now I happened to note Prime95 had died while I was away from the computer. No messages on screen, the small green square had simply vanished and there was no trace of the process in Task Manager.. Digging Windows logs, I found that on the two occasions (first one on the 29th of December, second on the 3rd of January), the cause was an Application Error, said application being Prime95, with an Exception Code 0xc0000005. This code refers to a Address Violation, i.e., the program appears to have used non allocated memory and hence was shut down by the OS. I did a SFC and found no errors, and saw no other occurences of this error for a really long time (never on this machine, actually). Apart from this, the new version seems to be pretty stable and have already found some ECM factors, both on windows and Linux (I´m running it on several colab instances where, by the way, I didn´t (yet?) have this problem). Any ideas/thoughts/suggestions? Note: Upon installing build 3 and then 4, I got a message from the OS to confirm I was really willing to run the exe file, as its origin was not confirmed/trusted. I am not running any AV, just Windows Defender. Last fiddled with by lycorn on 2021-01-04 at 13:00

2021-01-04, 14:54	#4
UBR47K Aug 2015 2²×17 Posts	I'm noticing a small speed decrease with ECM on M1277 (even with PracSearch=1) compared to 30.3b6 on Haswell i5. Can someone confirm this? (I'm using OutputIterations=30000000) 30.3b6: Code: M1277 curve 2 stage 1 at prime 4520437637 [59.47%]. Time: 9.504 sec. M1277 curve 2 stage 1 at prime 4522699141 [59.50%]. Time: 9.598 sec. 30.4 with PracSearch=1 (default gives around 10.xxx sec) Code: M1277 curve 1 stage 1 at prime 178990073 [2.35%]. Time: 9.711 sec. M1277 curve 1 stage 1 at prime 181260257 [2.38%]. Time: 9.712 sec.

2021-01-04, 17:10	#7
PhilF "6800 descendent" Feb 2005 Colorado 302₁₆ Posts	I don't remember if the P-1/ECM memory allocation refers to per worker or not. If it does, then you can't have more than one worker doing stage 2 at a time since you have only 8GB of total memory, unless you lower the memory allocation to 1GB per worker.