PFGW 4.0.4 (with gwnum v30.10) Released

[rogue]

Originally Posted by bchaffin

I found another repunit which fails repeatedly when run with special modular reduction. This is using pfgw4.0.1, which uses square_carefully for the last 50 iterations. (See post https://www.mersenneforum.org/showpo...&postcount=415 for a previous case.)

In this case the offender is (10^4568899-1)/9:

Detected in MAXERR>0.45 (round off check) in prp_using_gwnum
Iteration: 15177501/15177550 ERROR: ROUND OFF 0.5>0.45
PFGW will automatically rerun the test with -a1
...
Detected in MAXERR>0.45 (round off check) in prp_using_gwnum
Iteration: 15177501/15177550 ERROR: ROUND OFF 0.5>0.45
PFGW will automatically rerun the test with -a6
(10^4568899-1)/9 ERROR DURING PROCESSING! (96541.0526s+0.0304s)

This could be a gwnum issue. Maybe George can comment on it. If anything I could set the number of "last" iterations to something more dynamic so that as the number of bits increases the number of "careful" steps increases.

[Prime95]

We need to run this on prime95 with roundoff error checking enabled and see what happens. It should be done on the same machine or we need to know which FFT size and AVX options were used to make sure we're testing the same FFT code.

[bchaffin]

Foolishly I posted this shortly before going off grid for three days. The initial verbose output from pfgw:

command: pfgw64 -N -V -r '-q(10^4568899-1)/9'

PFGW Version 4.0.1.64BIT.20191203.x86_Dev [GWNUM 29.8]

Special modular reduction using AVX-512 FFT length 864K, Pass1=192, Pass2=4608, clm=4 on 10^4568899-1

I can provide more detail, or try running with prime95, on Sunday.

[Prime95]

My laptop has AVX-512. I'll run it.

[ATH]

Using FMA3 there is no errors but the residue does not match Prime95 with base 3 PRP test. Probably because Prime95 run with type 5 PRP test, will try a type 1 if that is possible on a "PRP CF".

pfgw64.exe -b3 -V -T8 -r "-q(10^4568899-1)/9"
PFGW Version 4.0.1.64BIT.20191203.Win_Dev [GWNUM 29.8]

Special modular reduction using FMA3 FFT length 864K, Pass1=384, Pass2=2304, clm=2, 8 threads on 10^4568899-1
(10^4568899-1)/9 is composite: RES64: [B1E4341884C6CE71] (10693.4219s+0.0414s)

Sending result to server: UID: athath/5960X, (10^4568899-1)/9 is not prime.  Type-5 RES64: DF04FEB4D88434E7. Wh4: 723F3064,00000000

{"status":"C", "k":1, "b":10, "n":4568899, "c":-1, "known-factors":["9"], "worktype":"PRP-3", "res64":"DF04FEB4D88434E7", "residue-type":5, "res2048":"7DD69506546BE2E04F9452841898CDE4F9DEA32DE149D05AAB0736D9441690195D4C1034D1E844B85E45D00662663629F3574980D41E3E74725AF7BD2EE4C66D7D5050325E0AD07CEA66C3BCDCD11ADBEE68BBA969E4FAC0497CE7C5572F090276348F56DBD4703B36751C7C12C5FC0565536754273F9280EEC4A2DCBCB4AD218EE458BA9BE3F2D19BA644B9A724805BDA8B8C7C0B4699BC857106E82909D194723D70E9B5D6790F358D608D29AA7D3E1550CCCABC64A89B0948CEDBA4C8EEEA8523D8A83FF1B2852F897ECC776C5D804586C634D5592CA5BBB4F3AF40AE07F4E35AC4B2690B26F7B5DDB72EDB612BE9E8354865A4EACECDDF04FEB4D88434E7", "fft-length":884736, "error-code":"00000000", "security-code":"723F3064", "program":{"name":"Prime95", "version":"29.8", "build":6, "port":4}, "timestamp":"2020-07-16 09:47:24", "user":"athath", "computer":"5960X"}

[Prime95]

Originally Posted by ATH

Using FMA3 there is no errors but the residue does not match Prime95 with base 3 PRP test. Probably because Prime95 run with type 5 PRP test,

I get the same result using an AVX-512 FFT. Max roundoff error was only 0.24.

[Prime95]

I restarted to generate a type-1 PRP. I did the first 30000 iterations with gwsquare_carefully -- no problems.

At this point I have no good idea why PFGW is having issues. It seems to be on the first of the final 50 gwsquare_carefullly calls. Perhaps the random number gwsquare_carefully uses was corrupted. If PFGW supports save files, I'd create a save file close to the end of the run for quicker debugging.

[rogue]

Originally Posted by Prime95

I restarted to generate a type-1 PRP. I did the first 30000 iterations with gwsquare_carefully -- no problems.

At this point I have no good idea why PFGW is having issues. It seems to be on the first of the final 50 gwsquare_carefullly calls. Perhaps the random number gwsquare_carefully uses was corrupted. If PFGW supports save files, I'd create a save file close to the end of the run for quicker debugging.

pfgw creates a .pfr file every so many iterations (don't know the exact number). I don't know the format of that file, but I do know it can be used to restart tests that were stopped before they could finish. I could provide a special build to bchaffin that doesn't delete that file after the error is detected. That file could then be used for debugging.

[ATH]

Prime95 finished a type 1 test with a new residue, but it still does not match the one from pfgw:

FMA3:
PFGW 4.01 864K FMA3 base3: B1E4341884C6CE71
PFGW 4.01 1M FMA3 base3: D39E16A305CCB581 -a3 switch
PFGW 4.01 1152K FMA3 base3: F02EB77CAEF0F21D -a5 switch
AVX-512:
PFGW 4.01 1M AVX-512 base3: B951202C7DADB329 -a5 switch

Prime95/mprime
Prime95 864K FMA3 base3 type1: 1858D4AA742E6849
mprime 864K AVX-512 base3 type1: 1858D4AA742E6849

PRP type 5 test
Prime95 864K FMA3 base3 type5: DF04FEB4D88434E7



Both my Prime95 runs are using ErrorCheck=1 and SumInputsErrorCheck=1 and max roundoff in the type1 test was 0.250.

Sending result to server: UID: athath/5960X, (10^4568899-1)/9 is not prime.  RES64: 1858D4AA742E6849. Wh4: 723F3064,00000000

{"status":"C", "k":1, "b":10, "n":4568899, "c":-1, "known-factors":["9"], "worktype":"PRP-3", "res64":"1858D4AA742E6849", "residue-type":1, "res2048":"B8AE8FB6E692687AC71FD9E9330497D0282A611174B13754B1CDE44370A35BC1C5A67B8DB4F665063A2830AD4DA1B4E39E4E4235816568FFAFFDC5C11DBA943B87D90CC6F30AECA04902034012E2BE6C62D639F5399D192339B687B92360987DA6BCE5DC8FFA007AC67CEFE797286A2438BDF6794BDE28DE0112A0B3B6955FC78B4250EA57C1F0B568D6B8DB70A59C86D320463E09D32959366ABE642BA5A19046E49D69AB3EFF0CC7078730E243E4F3CD49AE793EE467280A781731CBFA7380AA97218B672834FB8EB3A04FDECEE88FF1A7F2B4D4AB57FE59D6E79C25E6781AB940A99B742F3C6B806A0D9DB6C03A4FA904E2D7357F0F4E1858D4AA742E6849", "fft-length":884736, "error-code":"00000000", "security-code":"723F3064", "program":{"name":"Prime95", "version":"29.8", "build":6, "port":4}, "timestamp":"2020-07-18 02:24:40", "user":"athath", "computer":"5960X"}

[ATH]

Both with and without -r roundoff error detection PFGW AVX-512 fails on iteration 15177501:

Special modular reduction using AVX-512 FFT length 864K, Pass1=192, Pass2=4608, clm=4, 4 threads on 10^4568899-1
Detected in MAXERR>0.45 (round off check) in prp_using_gwnum
Iteration: 15177501/15177550 ERROR: ROUND OFF 0.5>0.45
PFGW will automatically rerun the test with -a1
Special modular reduction using AVX-512 FFT length 896K, Pass1=2K, Pass2=448, clm=1, 4 threads on 10^4568899-1
Detected in MAXERR>0.45 (round off check) in prp_using_gwnum
Iteration: 15177501/15177550 ERROR: ROUND OFF 0.5>0.45
PFGW will automatically rerun the test with -a2
Special modular reduction using AVX-512 FFT length 960K, Pass1=1536, Pass2=640, clm=1, 4 threads on 10^4568899-1

mprime AVX-512 864K base3 type1 test matches the Prime95 FMA3 type1 residue: 1858D4AA742E6849

[ATH]

No error from PFGW with AVX-512 if the -a5 switch is used for 1M fft, but again the residue does not match Prime95. I collect the residues in post #482.

./pfgw64 -b3 -V -T4 -a5 '-q(10^4568899-1)/9'
PFGW Version 4.0.1.64BIT.20191203.x86_Dev [GWNUM 29.8]

Special modular reduction using AVX-512 FFT length 1M, Pass1=128, Pass2=8K, clm=4, 4 threads on 10^4568899-1
(10^4568899-1)/9 is composite: RES64: [B951202C7DADB329] (17187.1961s+0.0401s)