LLR Version 3.8.19 released

[Jean Penné]

Hi All,

I uploaded today the version 3.8.19 of the LLR program.
You can find it now on my personal site :

http://jpenne.free.fr/

The 32bit Windows and Linux compressed binaries are available as usual.
The Linux 64bit binaries are also released here.
I uploaded also the complete source in a compressed file ; it may be used to
build the Mac-Intel executable and also the 64bit Windows binary.

The main new feature in this version is that MULTITHREADING is now available by setting -oThreadsPerTest=<number> or -t<number> in the command line.
Thanks to Serge Batalov who showed me how simple it was to implement this!

This LLR version is linked with the Version 28.12 of George Woltman's gwnum library.
George has fixed in this gwnum version, the bug which sometimes affected prime or PRP tests done using multithreading and FMA3.

When doing PRP tests, the Fermat test is now not strong by default, because it is time consuming...

Now, if the input file name (PgenInputFile parameter) has changed while working with the same .ini file, the PgenLine parameter is forced to one.
I made this update to fix the "CLLR bug" found by LaurV.

As usual, I need help to build the 32bit Mac Intel binary, and also the 64bit Mac Intel and Windows ones.
Please, inform me if you encountered any problem while using this new version.
Best Regards,
Jean

[IBethune]

Mac binaries are available from: https://ibethune.github.io/files/llr38j_mac.zip

Cheers

- Iain

[Jean Penné]

Originally Posted by IBethune

Mac binaries are available from: https://ibethune.github.io/files/llr38j_mac.zip

Cheers

- Iain

Many thanks, Iain!

Jean

[rebirther]

http://www.bc-team.org/downloads.php?cat=7 for win64 console + GUI

Also sent the files to Jean.

[Jean Penné]

Hi,

Thanks to Iain Bethune and to Rebirther, all LLR 3.8.19 binaries are now available.
Many thanks for your help and Best Regards,

Jean

[ATH]

With LLR 3.8.19 2 of the 3 numbers that failed in 3.8.18 now give the correct residue with 1,2,3,4,5,6,7 and 8 threads. These were the 2 that used 512K FMA FFT:
64598*5^2318694-1
33333*7^1917000-1

But the last one I found at 384K FMA FFT still fails for 5 and 7 threads (on an 8core 5960X), but works for 1,2,3,4,6,8.

cllr64.exe -d -q"66666*5^1560000-1"
Base prime factor(s) taken : 5
Starting N+1 prime test of 66666*5^1560000-1
Using FMA3 FFT length 384K, Pass1=256, Pass2=1536, a = 3
66666*5^1560000-1 is not prime.  RES64: 7417FF24F2FBCEB9.  OLD64: 5C47FD6ED8F36C28  Time : 6067.581 sec.

cllr64.exe -d -t2 -q"66666*5^1560000-1"
Base prime factor(s) taken : 5
Starting N+1 prime test of 66666*5^1560000-1
Using FMA3 FFT length 384K, Pass1=256, Pass2=1536, 2 threads, a = 3
66666*5^1560000-1 is not prime.  RES64: 7417FF24F2FBCEB9.  OLD64: 5C47FD6ED8F36C28  Time : 3451.684 sec.

cllr64.exe -d -t3 -q"66666*5^1560000-1"
Base prime factor(s) taken : 5
Starting N+1 prime test of 66666*5^1560000-1
Using FMA3 FFT length 384K, Pass1=256, Pass2=1536, 3 threads, a = 3
66666*5^1560000-1 is not prime.  RES64: 7417FF24F2FBCEB9.  OLD64: 5C47FD6ED8F36C28  Time : 2476.677 sec.

cllr64.exe -d -t4 -q"66666*5^1560000-1"
Base prime factor(s) taken : 5
Starting N+1 prime test of 66666*5^1560000-1
Using FMA3 FFT length 384K, Pass1=256, Pass2=1536, 4 threads, a = 3
66666*5^1560000-1 is not prime.  RES64: 7417FF24F2FBCEB9.  OLD64: 5C47FD6ED8F36C28  Time : 1957.058 sec.

cllr64.exe -d -t5 -q"66666*5^1560000-1"
Base prime factor(s) taken : 5
Starting N+1 prime test of 66666*5^1560000-1
Using FMA3 FFT length 384K, Pass1=256, Pass2=1536, 5 threads, a = 3
66666*5^1560000-1 is not prime.  RES64: E1866A6384261F5E.  OLD64: A4933F2A8C725E17  Time : 1614.234 sec.

cllr64.exe -d -t6 -q"66666*5^1560000-1"
Base prime factor(s) taken : 5
Starting N+1 prime test of 66666*5^1560000-1
Using FMA3 FFT length 384K, Pass1=256, Pass2=1536, 6 threads, a = 3
66666*5^1560000-1 is not prime.  RES64: 7417FF24F2FBCEB9.  OLD64: 5C47FD6ED8F36C28  Time : 1336.336 sec.

cllr64.exe -d -t7 -q"66666*5^1560000-1"
Base prime factor(s) taken : 5
Starting N+1 prime test of 66666*5^1560000-1
Using FMA3 FFT length 384K, Pass1=256, Pass2=1536, 7 threads, a = 3
66666*5^1560000-1 is not prime.  RES64: 5715B163A3E04BBB.  OLD64: 0541142AEBA0E32E  Time : 1240.131 sec.

cllr64.exe -d -t8 -q"66666*5^1560000-1"
Base prime factor(s) taken : 5
Starting N+1 prime test of 66666*5^1560000-1
Using FMA3 FFT length 384K, Pass1=256, Pass2=1536, 8 threads, a = 3
66666*5^1560000-1 is not prime.  RES64: 7417FF24F2FBCEB9.  OLD64: 5C47FD6ED8F36C28  Time : 1048.900 sec.

[Prime95]

Originally Posted by ATH

But the last one I found at 384K FMA FFT still fails for 5 and 7 threads (on an 8core 5960X), but works for 1,2,3,4,6,8.

Sigh. It may well be related to the previous bug. If my guess is correct, there is another bit of startup code that also needs a fix.

[Prime95]

Originally Posted by Prime95

Sigh. It may well be related to the previous bug. .

The problem is what I thought it might be. I've uploaded new gwnum source for Jean.

Thanks for finding the problem.

[Jean Penné]

Hi,

Many thanks to George! He fixed in gwnum 28.13, the FMA3 problem remaining while running a PRP test with 5 or 7 threads.
So, I updated on LLR 3.8.19 the source, and the Win32 and Linux binaries. I need help to update the Win64 and Mac Intel binaries with the same version of gwnum.

Regards,
Jean

[AG5BPilot]

Originally Posted by Jean Penné

Hi,

Many thanks to George! He fixed in gwnum 28.13, the FMA3 problem remaining while running a PRP test with 5 or 7 threads.
So, I updated on LLR 3.8.19 the source, and the Win32 and Linux binaries. I need help to update the Win64 and Mac Intel binaries with the same version of gwnum.

Regards,
Jean

Would it be possible to release the fix as a 3.8.20 version of LLR? If the fixed version is released as 3.8.19, then there will be two versions of 3.8.19 out in the wild, one of which produces the correct results and one that produces erroneous results. That makes it very hard for us to tell if we're getting the correct results from participants.

Thank you!

[Jean Penné]

Originally Posted by AG5BPilot

Would it be possible to release the fix as a 3.8.20 version of LLR? If the fixed version is released as 3.8.19, then there will be two versions of 3.8.19 out in the wild, one of which produces the correct results and one that produces erroneous results. That makes it very hard for us to tell if we're getting the correct results from participants.

Thank you!

Sorry, I did not think this necessary after only two days!
So, I shall build a 3.8.20 LLR Version...
When the upload will be complete for the source and all the binaries, I will then make the two previous "multithreaded " versions unavailable, because they are buggy.

Regards,
Jean