A possible bug in LLR/PFGW while using GWNUM (no bug in P95)

[Batalov]

Here is the savefie at bit 2975450, attached (together with the sample command-lines to try to run).
There are only 11 bits to go.
If you will use non-AVX CPU, you will get prime.
If you will use AVX 320K FFT, you will get prime.
If you will use AVX 240K (256K, 288K) FFT, you will get composite.

This should be a very compact debug case. Can be even debugged under gdb in memory, without file dumps.

[Batalov]

I knew that this message will be popular (/sarcasm), but 427,000+ views?

[chris2be8]

427000 * 727.4Kb is over 310 Gbytes!

To download that many copies in the 85 minutes between the last two posts would need at least 3.65 Gbytes/second (61 Mbytes/s) of bandwidth. Does mersenneforum have that fast an internet connection?

If not the number of views must be bogus.

As an experiment I just clicked on the link, then hit cancel on the dialog box asking what I wanted to do with it. But the count of views went up when I refreshed the page. So a script repeatedly doing that could have caused the count.

Chris

[Batalov]

While, we have not tracked down the AVX bug yet, I now realized (tangentially) that I can implement and run yet another Berrizbeitia-Iskra test.

I already had a privilege of using the B-I test in my search for the Eisenstein-Mersenne prime norm #26.

[paulunderwood]

./pfgw64 -t -a3 -V -i -q"1024*3^1877301+1"
PFGW Version 3.7.7.64BIT.20130722.x86_Dev [GWNUM 27.11]


CPU Information (From Woltman v26 library code)
Intel(R) Core(TM) i7-4770K CPU @ 3.50GHz
CPU speed: 3257.55 MHz, 4 cores
CPU features: RDTSC, CMOV, Prefetch, MMX, SSE, SSE2, SSE4.1, SSE4.2
L1 cache size: 32 KB
L2 cache size: 256 KB, L3 cache size: 8 MB
L1 cache line size: 64 bytes
L2 cache line size: 64 bytes
TLBS: 64
                                    
Primality testing 1024*3^1877301+1 [N-1, Brillhart-Lehmer-Selfridge]                                    
Running N-1 test using base 5                                                  
Special modular reduction using all-complex AVX FFT length 320K, Pass1=256, Pass2=1280 on 1024*3^1877301+1                                    
1024*3^1877301+1 is prime! (6959.1446s+0.0486s)

Note the use of "-a3"

[Batalov]

Yep, consistent with LLR: -a3 (i.e. in this case, AVX FFT length 320K) is good.

I have not used my weekend for further debug.
Maybe the next (ver-r-r-r-y long) weekend: Novartis has corporate schedule with the holidays for the whole week, until Jan/2. Every year.

[Batalov]

I "doctored" another anomality (it is actually a prime).

10^388080-10^342029-1 is not prime, although Fermat PSP! P = 7, Lucas RES64: 0000000000000007  Time : 9361.634 sec.

With P = 5 (with defaults), the test passes. P = 7 was set with LucasBaseP=7 and NRestarts=1 in llr.ini (and PRPdone=1, which it was of course done). (The "L" file, was of course erased prior to this re-run.)

I ran it in parallel with the P=5 run.

I don't know if this case is related.

[IBethune]

Obviously it's holiday season etc. but just wondering if any more progress was made on this issue? In particular I couldn't understand from the thread what particular candidate types / FFT lengths / CPU ISA are affected. Since it seems to be a software problem, double-checking will probably not have helped (except in the case where the double-checker used a different transform type), so we would need to know exactly where the bug occurs to run a triple-check.

Likewise, if there is anything I could do that would help the debugging effort, I'd be happy to contribute.

Cheers

- Iain

[Batalov]

No progress since the debug case (yep... holidays!).

I lean even more towards gwtogiant / gmod suspicion. I have some ideas + some from George, but haven't run them.

[AG5BPilot]

I'm not sure if this is related or not, but I had found an interesting LLR result where two AVX computers agreed on the result, but an AMD (non-AVX) computer disagreed.

AVX:

Iter: 6759040/6879943, ERROR: ROUND OFF (0.4375) > 0.4
Continuing from last save file.
Disregard last error. Result is reproducible and thus not a hardware problem.
For added safety, redoing iteration using a slower, more reliable method.
Continuing from last save file.
202705*2^6879926+1 is not prime. Proth RES64: 52E338294E4A78FD Time : 23073.022 sec.

non-AVX:

202705*2^6879926+1 is not prime. Proth RES64: CEF77BFB02AB1491 Time : 98814.320 sec.

I'm rerunning the tests to see if it's repeatable. The AMD machine, which didn't agree with the other two, does not have a history of errors.

[AG5BPilot]

Originally Posted by AG5BPilot

I'm not sure if this is related or not, but I had found an interesting LLR result where two AVX computers agreed on the result, but an AMD (non-AVX) computer disagreed.

It's not related. The two AVX tests that restarted were, in fact, correct. The other result from the AMD CPU was faulty.