LLR Version 4.0.2 released.

[Jean Penné]

Hi All,

I uploaded today the version 4.0.1 of the LLR program.
You can find the new Version 4.0.2 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 released here, and also the Mac OS 64bit binaries.
The Mac OS 32bit is not released here because I have not the 32bit hwloc library which is needed, and could not build it on my Mac mini...
I uploaded also the complete source in a compressed file ; it may be used to build the 64bit Windows binaries.

What is new in this version :

The Affinity managing was not really implemented on LLR...
This issue is now fixed on Linux and WIN32 versions.
The option -oAffinity=2 allows the progam to run on logical core 2.
You may now also choose a list of cores by setting -oAffinity="2,3,5" for example.
The Mac OS binary remains identical to 4.0.1 one because Affinity management seems not to be available on MAC OS platforms.

In previous Version 4.0.0, one call to free() function was missing in Gerbicz error checking code ;
this caused an important memory leak... This issue is now fixed here!

This version is linked with the last version 30.6 of George Woltman's gwnum library.
No really new feature, from 3.8.24, but some improvements related to reliability and speed.
I avoid now the use of giants functions invg() and gcdg() which are slow and seem not to be very reliable.
To do that, I am using gtompz() and mpztog() conversion functions.
Also, I replaced everywhere the gwnum squaring and multiplication functions gwsquare() and gwmul() by their new forms :
gwsquare2(), gwmul3(), gwmul3_carefully(), etc...
As usual, I need help to build the 64bit Windows binaries.
I uploaded also the GNU gmp6.1.0 compressed source I used on 32bit VC6.0
I hope it can be used to build this library on Windows 64bit and link it with LLR...
Please, inform me if you encountered any problem while using this new version.
Best Regards,
Jean

[Happy5214]

The NewPGen 0x100 mask support which was added in version 4.0.0 (which was taken to mean 2k*b^n-3) completely breaks support for srsieve, which includes that bit in the standard Riesel and Proth masks (which are 258 and 257 in srsieve-generated outputs, respectively).

[Jean Penné]

Hi all,

Thanks to the help of Mark Rodenkirsch and George Woltman, I succeeded to build the Win64 console binaries cllr64 and cllrd64.
So, these two binaries are now available on my personal site : http://jpenne.free.fr
I did not upload the new source because the build of the Win64 GUI version is not yet possible using it.

Nevertheless, I hope these binaries would be useful.

Best Regards,
Jean

[Jean Penné]

Hi All,

Finally, I succeeded to build the Win64 GUI application of LLR 4.0.2 so, you can now download it on my personal site.

Best Regards,

Jean

[pepi37]

This is my input file called input.npg

1600000000000000:M:1:10:258
962 11943

And this is output of LLR 4.0.2


Why Morrison prime test is running and from where is candidate 1924*10^11943-3?
And what is service control manager that cannot be opened?

Thanks for reply.

[Jean Penné]

Originally Posted by pepi37

This is my input file called input.npg

1600000000000000:M:1:10:258
962 11943

And this is output of LLR 4.0.2


Why Morrison prime test is running and from where is candidate 1924*10^11943-3?
And what is service control manager that cannot be opened?

Thanks for reply.

Do you really need service control manager?
I drop it in LLR because its code causes many unresolved addresses at link...
To avoid continuing the test of a Cunnigham chain after a prime is found, use the option -oUseCharCode=1
Regards,

Jean

[pepi37]

Originally Posted by Jean Penné

Do you really need service control manager?
I drop it in LLR because its code causes many unresolved addresses at link...
To avoid continuing the test of a Cunnigham chain after a prime is found, use the option -oUseCharCode=1
Regards,

Jean

I dont need it at all, I just ask what is that option :)
Thanks for answer
Best regards

[ruckuslemur]

There is a potentially unwanted feature in all versions of llr:
Given as input a sufficiently large number of the form k*2^n+-1, before running a Proth or Lucas-Lehmer-Riesel primality test, the program only checks if k<2^n without checking if k is odd and, if it isn't, rewriting the number (by halving k until it's odd, checking that k isn't 1 and adding the number of times k was halved to n).
As a result, the test is run using wrong values of k and n and the program reports Proth and Riesel primes written differently as composite.
When llrCUDA is given the same input it sometimes reports the number as composite after just the Fermat PRP test. This shouldn't be possible, so it's either mis-printing what it's doing or there's another issue.

Below are some examples, followed by a Proth test run by Proth20 (which has checks in place).

login@debian:~/Downloads$ ./llr402linux64/llr64 -d -q"5046*2^349007+1"
Starting Proth prime test of 5046*2^349007+1
Using all-complex FMA3 FFT length 24K, Pass1=512, Pass2=48, clm=2, a = 11
5046*2^349007+1 is not prime.  Base-11 Proth RES64: 91E6E3224C101AF9.  Time : 31.468 sec.

login@debian:~/Downloads$ ./llr402linux64/llr64 -d -q"2523*2^349008+1"
Starting Proth prime test of 2523*2^349008+1
Using all-complex FMA3 FFT length 24K, Pass1=512, Pass2=48, clm=2, a = 11
2523*2^349008+1 is prime! (105066 decimal digits)  Time : 30.436 sec.

login@debian:~/Downloads$ ./llr402linux64/llr64 -d -q"5046*2^349006-1"
Starting Fermat PRP test of 5046*2^349006-1
Using FMA3 FFT length 24K, Pass1=384, Pass2=64, clm=2, a = 3
5046*2^349006-1 is a Fermat Probable prime! (105065 decimal digits)  Time : 29.183 sec.
Starting Lucas Lehmer Riesel prime test of 5046*2^349006-1
Using FMA3 FFT length 24K, Pass1=384, Pass2=64, clm=2
5046*2^349006-1 is not prime.  LLR Res64: 780F16FCFA632B43  Time : 26.023 sec.

login@debian:~/Downloads$ ./llr402linux64/llr64 -d -q"2523*2^349007-1"
Starting Fermat PRP test of 2523*2^349007-1
Using FMA3 FFT length 24K, Pass1=384, Pass2=64, clm=2, a = 3
2523*2^349007-1 is a Fermat Probable prime! (105065 decimal digits)  Time : 29.064 sec.
Starting Lucas Lehmer Riesel prime test of 2523*2^349007-1
Using FMA3 FFT length 24K, Pass1=384, Pass2=64, clm=2
2523*2^349007-1 is prime! (105065 decimal digits)  Time : 25.877 sec.

login@debian:~/Downloads$ ./llrcuda386src/llrCUDA -d -q"5046*2^349007+1"
Starting Proth prime test of 5046*2^349007+1
Using complex irrational base DWT, FFT length = 49152, a = 11
5046*2^349007+1 is not prime.  Base-11 Proth RES64: 0000000000000001.  Time : 141.737 sec.

login@debian:~/Downloads$ ./llrcuda386src/llrCUDA -d -q"2523*2^349008+1"
Starting Proth prime test of 2523*2^349008+1
Using complex irrational base DWT, FFT length = 49152, a = 11
2523*2^349008+1 is prime! (105066 decimal digits)  Time : 140.751 sec.

login@debian:~/Downloads$ ./llrcuda386src/llrCUDA -d -q"5046*2^349006-1"
Starting Fermat PRP test of 5046*2^349006-1
Using real irrational base DWT, FFT length = 40960, a = 3
5046*2^349006-1 is not prime.  RES64: 74CEEAD9C89D6450.  Time : 124.897 sec.

login@debian:~/Downloads$ ./llrcuda386src/llrCUDA -d -q"2523*2^349007-1"
Starting Fermat PRP test of 2523*2^349007-1
Using real irrational base DWT, FFT length = 40960, a = 3
2523*2^349007-1 is a Fermat Probable prime! (105065 decimal digits)  Time : 124.103 sec.
Starting Lucas Lehmer Riesel prime test of 2523*2^349007-1
Using real irrational base DWT, FFT length = 40960
V1 = 3 ; Computing U0...done.
2523*2^349007-1 is prime! (105065 decimal digits)  Time : 121.779 sec.

login@debian:~/Downloads$ ./proth20/bin/proth20 -q"5046*2^349007+1"
proth20 0.9.1 linux64 gcc-8.3.0
Copyright (c) 2020, Yves Gallot
proth20 is free source code, under the MIT license.
Testing 2523 * 2^349008 + 1, 105066 digits, size = 2^16 x 21 bits, plan: 256_4 sq_256 p2i_4_64
2523 * 2^349008 + 1 is prime, a = 11, time = 00:00:46

[Happy5214]

Originally Posted by ruckuslemur

There is a potentially unwanted feature in all versions of llr:
Given as input a sufficiently large number of the form k*2^n+-1, before running a Proth or Lucas-Lehmer-Riesel primality test, the program only checks if k<2^n without checking if k is odd and, if it isn't, rewriting the number (by halving k until it's odd, checking that k isn't 1 and adding the number of times k was halved to n).
As a result, the test is run using wrong values of k and n and the program reports Proth and Riesel primes written differently as composite.
When llrCUDA is given the same input it sometimes reports the number as composite after just the Fermat PRP test. This shouldn't be possible, so it's either mis-printing what it's doing or there's another issue.

[...]

My guess is that it's not incrementing the iteration count for the test, so the test ends an iteration (or two, or whatever) short of where it needs to.

[ruckuslemur]

Originally Posted by Happy5214

My guess is that it's not incrementing the iteration count for the test, so the test ends an iteration (or two, or whatever) short of where it needs to.

Which iteration count do you mean? I tried hardcoding a "final_count += 1;" in GerbiczTest() at line 7458 of Llr.c (non-CUDA) and the Proth test still reported 5046*2^349007+1 as composite, though with a different RES64. Incrementing final_count by more than 1 caused the program to crash, but tests with odd k ran fine with final_count incremented by 1 so that variable likely isn't the iteration count for the test.

[Jean Penné]

Originally Posted by ruckuslemur

There is a potentially unwanted feature in all versions of llr:
Given as input a sufficiently large number of the form k*2^n+-1, before running a Proth or Lucas-Lehmer-Riesel primality test, the program only checks if k<2^n without checking if k is odd and, if it isn't, rewriting the number (by halving k until it's odd, checking that k isn't 1 and adding the number of times k was halved to n).
As a result, the test is run using wrong values of k and n and the program reports Proth and Riesel primes written differently as composite.
When llrCUDA is given the same input it sometimes reports the number as composite after just the Fermat PRP test. This shouldn't be possible, so it's either mis-printing what it's doing or there's another issue.

Below are some examples, followed by a Proth test run by Proth20 (which has checks in place).

login@debian:~/Downloads$ ./llr402linux64/llr64 -d -q"5046*2^349007+1"
Starting Proth prime test of 5046*2^349007+1
Using all-complex FMA3 FFT length 24K, Pass1=512, Pass2=48, clm=2, a = 11
5046*2^349007+1 is not prime.  Base-11 Proth RES64: 91E6E3224C101AF9.  Time : 31.468 sec.

login@debian:~/Downloads$ ./llr402linux64/llr64 -d -q"2523*2^349008+1"
Starting Proth prime test of 2523*2^349008+1
Using all-complex FMA3 FFT length 24K, Pass1=512, Pass2=48, clm=2, a = 11
2523*2^349008+1 is prime! (105066 decimal digits)  Time : 30.436 sec.

login@debian:~/Downloads$ ./llr402linux64/llr64 -d -q"5046*2^349006-1"
Starting Fermat PRP test of 5046*2^349006-1
Using FMA3 FFT length 24K, Pass1=384, Pass2=64, clm=2, a = 3
5046*2^349006-1 is a Fermat Probable prime! (105065 decimal digits)  Time : 29.183 sec.
Starting Lucas Lehmer Riesel prime test of 5046*2^349006-1
Using FMA3 FFT length 24K, Pass1=384, Pass2=64, clm=2
5046*2^349006-1 is not prime.  LLR Res64: 780F16FCFA632B43  Time : 26.023 sec.

login@debian:~/Downloads$ ./llr402linux64/llr64 -d -q"2523*2^349007-1"
Starting Fermat PRP test of 2523*2^349007-1
Using FMA3 FFT length 24K, Pass1=384, Pass2=64, clm=2, a = 3
2523*2^349007-1 is a Fermat Probable prime! (105065 decimal digits)  Time : 29.064 sec.
Starting Lucas Lehmer Riesel prime test of 2523*2^349007-1
Using FMA3 FFT length 24K, Pass1=384, Pass2=64, clm=2
2523*2^349007-1 is prime! (105065 decimal digits)  Time : 25.877 sec.

login@debian:~/Downloads$ ./llrcuda386src/llrCUDA -d -q"5046*2^349007+1"
Starting Proth prime test of 5046*2^349007+1
Using complex irrational base DWT, FFT length = 49152, a = 11
5046*2^349007+1 is not prime.  Base-11 Proth RES64: 0000000000000001.  Time : 141.737 sec.

login@debian:~/Downloads$ ./llrcuda386src/llrCUDA -d -q"2523*2^349008+1"
Starting Proth prime test of 2523*2^349008+1
Using complex irrational base DWT, FFT length = 49152, a = 11
2523*2^349008+1 is prime! (105066 decimal digits)  Time : 140.751 sec.

login@debian:~/Downloads$ ./llrcuda386src/llrCUDA -d -q"5046*2^349006-1"
Starting Fermat PRP test of 5046*2^349006-1
Using real irrational base DWT, FFT length = 40960, a = 3
5046*2^349006-1 is not prime.  RES64: 74CEEAD9C89D6450.  Time : 124.897 sec.

login@debian:~/Downloads$ ./llrcuda386src/llrCUDA -d -q"2523*2^349007-1"
Starting Fermat PRP test of 2523*2^349007-1
Using real irrational base DWT, FFT length = 40960, a = 3
2523*2^349007-1 is a Fermat Probable prime! (105065 decimal digits)  Time : 124.103 sec.
Starting Lucas Lehmer Riesel prime test of 2523*2^349007-1
Using real irrational base DWT, FFT length = 40960
V1 = 3 ; Computing U0...done.
2523*2^349007-1 is prime! (105065 decimal digits)  Time : 121.779 sec.

login@debian:~/Downloads$ ./proth20/bin/proth20 -q"5046*2^349007+1"
proth20 0.9.1 linux64 gcc-8.3.0
Copyright (c) 2020, Yves Gallot
proth20 is free source code, under the MIT license.
Testing 2523 * 2^349008 + 1, 105066 digits, size = 2^16 x 21 bits, plan: 256_4 sq_256 p2i_4_64
2523 * 2^349008 + 1 is prime, a = 11, time = 00:00:46

Many thanks for your remarks!
There are really bugs in IsLLRP() and IsProthP() codes (wrong values of base and exponent passed to gwSetup() function when k is even).
These bugs will be fixed in the next release of LLR and of llrCUDA.
Best Regards,
Jean