LLR version 3.8.24 released.

[Jean Penné]

Originally Posted by Happy5214

The new version compiled, but it didn't link:

gcc  -o llr64 lprime.o lmenu.o ../gwnum/gwnum.ld ../gwnum/gwnum.a ./libgmp.a ./libhwloc.a  ../gwnum/gwnum.ld -lm  -lpthread -lstdc++
...
/usr/bin/ld: ./libgmp.a(bdiv_q.o): relocation R_X86_64_32S against symbol `__gmp_binvert_limb_table' can not be used when making a PIE object; recompile with -fPIE
/usr/bin/ld: final link failed: nonrepresentable section on output
collect2: error: ld returned 1 exit status
make: *** [Makefile:26: llr64] Error 1

I think you have better to do "make allclean" and then, "make" in order to recompile the gwnum C files on your sytem, but I am not sure it will be sufficient...

[Uncwilly]

There is no need to quote the entire post that you are responding to.

[Jean Penné]

Originally Posted by Uncwilly

There is no need to quote the entire post that you are responding to.

Ok, but I was a bit in a hurry, being now abroad for two weeks in Britany...

Regards,
Jean

[Happy5214]

Originally Posted by Jean Penné

I think you have better to do "make allclean" and then, "make" in order to recompile the gwnum C files on your sytem, but I am not sure it will be sufficient...

That worked, though I had to re-copy libhwloc.a from the zip because make allclean deleted it. I also used -lgmp instead of the provided GMP since I already have it installed.

[Citrix]

Could someone post a 64 bit windows console binary. Thanks.

[pepi37]

Originally Posted by Citrix

Could someone post a 64 bit windows console binary. Thanks.

http://jpenne.free.fr/index2.html

[henryzz]

Originally Posted by pepi37

http://jpenne.free.fr/index2.html

Still only 32-bit for windows.

[Happy5214]

Out of curiosity, what would be a major enough change to bump the version number to 3.9.0, or even 4.0.0? There have been a lot of releases in the 3.8.x series, and not all of them are necessarily backwards compatible (e.g. the change in this version to Fermat PRP residues by default for Riesel prime candidates), which is not usually a good thing for only changing the last part of a three-part version number.

[diep]

Seems scale better the 3.8.24b2 but it's a lot slower on my machine here.

I tried under linux 64 bits at dual socket Xeon L5420 machine at 4 threads the new version 3.8.24b2

diep@thegathering:/home/69$ cat test2/lresults.txt
69*2^7000369-1 is not prime. RES64: 886E914BC82C8141. Time : 39825.834 sec.
69*2^7000867-1 is not prime. RES64: 1F3BCAF66C5B7933. Time : 38285.808 sec.
69*2^7001303-1 is not prime. RES64: 94D4AD4E9742E379. Time : 38139.096 sec.
69*2^7001737-1 is not prime. RES64: BE059B0E4A0D9D8E. Time : 38098.335 sec.

Meanwhile running at the other 4 cores an old version 3.8.21
69*2^7020207-1 is not prime. LLR Res64: 597F737890E1B7D6 Time : 30347.892 sec.
69*2^7020581-1 is not prime. LLR Res64: 6D7158CD69CE50C9 Time : 29160.003 sec.
69*2^7021093-1 is not prime. LLR Res64: 669D4D0DF15BA53F Time : 29021.396 sec.
69*2^7021665-1 is not prime. LLR Res64: 08F2596FBD4399E7 Time : 28909.286 sec.
69*2^7022049-1 is not prime. LLR Res64: 04AD3E151D54E10B Time : 29338.964 sec.

The LLR.ini it wrote:diep@thegathering:/home/69/test2$ cat llr.ini
WorkDone=0
Work=0
PgenInputFile=../splitted/7m8m_first5k_at
PgenOutputFile=../res1
PgenLine=5
HeaderLine=0
Pid=0
ThreadsPerTest=4
OldCpuSpeed=2500
NewCpuSpeedCount=0
NewCpuSpeed=0
PRPGerbiczCompareIntervalAdj= 1
OldInputFile=../splitted/7m8m_first5k_at

[paulunderwood]

I concur: testing a million digit number on an i7:

v3.8.24: 0.749 ms/it
v3.8.21: 0.688 ms/it

[paulunderwood]

Fermat's Little theorem states b^(N-1) == 1 mod N for prime N (and gcd(b,N)==1).

For N=2^n-c this means for b=3 that 3^(2^n-c-1) == 1 (mod 2^n-c). This can be rewritten as 3^(2^n) == 3^(c+1) (mod 2^n-c). The left hand side is just squarings; The right hand side takes ~log(c) iterations. At the moment LLR does ~n multiplications of 3 times an n bit number which adds up to a 3-5% overhead.

Can a similar argument hold for k*2^n-c? Yes! (3^k)^(2^n) == 3^(c+1) (mod k*2^n-c).