20200710, 15:21  #12  
May 2004
FRANCE
1001000011_{2} Posts 
Quote:


20200710, 17:30  #13 
6809 > 6502
"""""""""""""""""""
Aug 2003
101×103 Posts
7·37^{2} Posts 
There is no need to quote the entire post that you are responding to.

20200711, 05:50  #14 
May 2004
FRANCE
3·193 Posts 

20200711, 09:15  #15  
"Alexander"
Nov 2008
The Alamo City
1137_{8} Posts 
Quote:


20200717, 23:57  #16 
Jun 2003
62B_{16} Posts 
Could someone post a 64 bit windows console binary. Thanks.

20200828, 19:41  #17 
Dec 2011
After milion nines:)
2^{4}×89 Posts 

20200829, 08:18  #18  
Just call me Henry
"David"
Sep 2007
Cambridge (GMT/BST)
2·5·587 Posts 
Quote:


20201012, 15:09  #19 
"Alexander"
Nov 2008
The Alamo City
607 Posts 
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 threepart version number.

20201012, 15:32  #20 
Sep 2006
The Netherlands
2^{6}·11 Posts 
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^70003691 is not prime. RES64: 886E914BC82C8141. Time : 39825.834 sec. 69*2^70008671 is not prime. RES64: 1F3BCAF66C5B7933. Time : 38285.808 sec. 69*2^70013031 is not prime. RES64: 94D4AD4E9742E379. Time : 38139.096 sec. 69*2^70017371 is not prime. RES64: BE059B0E4A0D9D8E. Time : 38098.335 sec. Meanwhile running at the other 4 cores an old version 3.8.21 69*2^70202071 is not prime. LLR Res64: 597F737890E1B7D6 Time : 30347.892 sec. 69*2^70205811 is not prime. LLR Res64: 6D7158CD69CE50C9 Time : 29160.003 sec. 69*2^70210931 is not prime. LLR Res64: 669D4D0DF15BA53F Time : 29021.396 sec. 69*2^70216651 is not prime. LLR Res64: 08F2596FBD4399E7 Time : 28909.286 sec. 69*2^70220491 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 
20201012, 17:35  #21 
Sep 2002
Database er0rr
111001011100_{2} Posts 
I concur: testing a million digit number on an i7:
v3.8.24: 0.749 ms/it v3.8.21: 0.688 ms/it Last fiddled with by paulunderwood on 20201012 at 17:36 
20201018, 14:09  #22 
Sep 2002
Database er0rr
2^{2}×919 Posts 
Speed up for N=2^nc
Fermat's Little theorem states b^(N1) == 1 mod N for prime N (and gcd(b,N)==1).
For N=2^nc this means for b=3 that 3^(2^nc1) == 1 (mod 2^nc). This can be rewritten as 3^(2^n) == 3^(c+1) (mod 2^nc). 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 35% overhead. Can a similar argument hold for k*2^nc? Yes! (3^k)^(2^n) == 3^(c+1) (mod k*2^nc). Last fiddled with by paulunderwood on 20201018 at 15:16 
Thread Tools  
Similar Threads  
Thread  Thread Starter  Forum  Replies  Last Post 
LLR Version 3.8.22 released  Jean Penné  Software  51  20190410 06:04 
LLR Version 3.8.19 released  Jean Penné  Software  11  20170223 08:52 
LLR Version 3.8.16 released  Jean Penné  Software  38  20151210 07:31 
LLR Version 3.8.15 released  Jean Penné  Software  28  20150804 04:51 
llr 3.8.2 released as devversion  opyrt  Prime Sierpinski Project  11  20101118 18:24 