mersenneforum.org LLR 3.8.2: more flexible stop-on-prime option
 User Name Remember Me? Password
 Register FAQ Search Today's Posts Mark Forums Read

 2010-09-30, 05:25 #1 mdettweiler A Sunny Moo     Aug 2007 USA (GMT-5) 141518 Posts LLR 3.8.2: more flexible stop-on-prime option In addition to the speed boost for most CPUs that is also present in PFGW 3.4.0, I noticed an interesting new addition when perusing LLR 3.8.2's readme: Code: 5) Main user options (not set by default) : Verbose=1 : Get more details in the results file (default : 1 line/result). StopOnSuccess=1 : Stop the job when a prime or PRP is found. BeepOnSuccess=1 : Make noise at a positive result, if both Stop and Beep are set, make noise until stopped by the user! StopOnPrimedK= : after sucesses with this k value, skip further pairs having the same k value (usually, = 1). StopOnPrimedN= : Same thing, involving the value of n. StopOnPrimedB= : Same thing, involving the base value. Verify=1 : Suppress prefactoring or previous PRP test. NoPrefactoring=1 : Suppress prefactoring (Gaussian Mersenne or Wagstaff). ErrorCheck=1 : Check errors on each iteration (it's time consuming!). Testdiff=1 : Check sum inputs != sum outputs (only for real FFT's, c<0). FacTo= : Used to launch a prefactoring only job (Wagstaff or Gaussian-Mersenne norms candidates only). The lines in bold will be of particular interest to CRUS searchers. (Well, at least the StopOnPrimedK option...the others would be for other types of conjectures that haven't really been explored yet.) This isn't anything new, since PFGW has had a similar option for a while, but now both programs are capable of stopping searching just one k when it's been primed (as opposed to bringing the whole run to a halt as older LLR versions' StopOnPrime option did).
2010-09-30, 05:55   #2
Jean Penné

May 2004
FRANCE

23·3·23 Posts
LLR 3.8.2 features == LLR 3.8.1 ones!

Quote:
 Originally Posted by mdettweiler In addition to the speed boost for most CPUs that is also present in PFGW 3.4.0, I noticed an interesting new addition when perusing LLR 3.8.2's readme: Code: 5) Main user options (not set by default) : Verbose=1 : Get more details in the results file (default : 1 line/result). StopOnSuccess=1 : Stop the job when a prime or PRP is found. BeepOnSuccess=1 : Make noise at a positive result, if both Stop and Beep are set, make noise until stopped by the user! StopOnPrimedK= : after sucesses with this k value, skip further pairs having the same k value (usually, = 1). StopOnPrimedN= : Same thing, involving the value of n. StopOnPrimedB= : Same thing, involving the base value. Verify=1 : Suppress prefactoring or previous PRP test. NoPrefactoring=1 : Suppress prefactoring (Gaussian Mersenne or Wagstaff). ErrorCheck=1 : Check errors on each iteration (it's time consuming!). Testdiff=1 : Check sum inputs != sum outputs (only for real FFT's, c<0). FacTo= : Used to launch a prefactoring only job (Wagstaff or Gaussian-Mersenne norms candidates only). The lines in bold will be of particular interest to CRUS searchers. (Well, at least the StopOnPrimedK option...the others would be for other types of conjectures that haven't really been explored yet.) This isn't anything new, since PFGW has had a similar option for a while, but now both programs are capable of stopping searching just one k when it's been primed (as opposed to bringing the whole run to a halt as older LLR versions' StopOnPrime option did).

It was already available in Version 3.8.1!
I did'nt add nor change any feature in this new version...
Jean

2010-09-30, 06:12   #3
mdettweiler
A Sunny Moo

Aug 2007
USA (GMT-5)

141518 Posts

Quote:
 Originally Posted by Jean Penné It was already available in Version 3.8.1! I did'nt add nor change any feature in this new version... Jean
Hmm, I didn't know that...I guess I never did bother to read the readme for 3.8.1.

 2010-09-30, 09:10 #4 gd_barnes     May 2007 Kansas; USA 32×72×23 Posts Very cool. Nor did I know that. Thanks for letting us know.
 2010-09-30, 16:26 #5 KEP Quasi Admin Thing     May 2005 11100011112 Posts Very cool Jean. Thanks for adding this. Now a question or 2. Is the StopOnPrimedK=, remembering wich k's has previously been primed, in case LLR has to be stopped? Finally, is LLR version 3.8.2 with the latest GWnum build, such that there can be a usefull 10% speedincrease on each tests? Regards KEP
2010-09-30, 16:34   #6
henryzz
Just call me Henry

"David"
Sep 2007
Cambridge (GMT)

10110001010102 Posts

Quote:
 Originally Posted by KEP Finally, is LLR version 3.8.2 with the latest GWnum build, such that there can be a usefull 10% speedincrease on each tests?
That is the only difference to 3.8.1. Compile the 3.8.1 source with the latest GWnum and you should have a 3.8.2 binary(there might be a version number change somewhere).

2010-09-30, 16:37   #7
kar_bon

Mar 2006
Germany

28·11 Posts

Quote:
 Originally Posted by KEP Is the StopOnPrimedK=, remembering wich k's has previously been primed, in case LLR has to be stopped?
Yes, LLR recognize a found value in the llr.ini like:
Code:
StopOnPrimedK=1
ks38=1
Here only one prime has to be found for every k-value and for k=38 there exist a prime already.

Quote:
 Finally, is LLR version 3.8.2 with the latest GWnum build, such that there can be a usefull 10% speedincrease on each tests?
LLR V3.8.2 uses gwnum V26.2, so all speedups are in there with sometimes about 20% more speed!

See the source in gwnum.h
Code:
#define GWNUM_VERSION		"26.2"
#define GWNUM_MAJOR_VERSION	26
#define GWNUM_MINOR_VERSION	2

Last fiddled with by kar_bon on 2010-09-30 at 16:39

2010-09-30, 16:50   #8
henryzz
Just call me Henry

"David"
Sep 2007
Cambridge (GMT)

2×2,837 Posts

Quote:
 Originally Posted by kar_bon Yes, LLR recognize a found value in the llr.ini like: Code: StopOnPrimedK=1 ks38=1 Here only one prime has to be found for every k-value and for k=38 there exist a prime already.
That is better than pfgw.

2010-09-30, 19:24   #9
KEP
Quasi Admin Thing

May 2005

911 Posts

Quote:
 Originally Posted by kar_bon Yes, LLR recognize a found value in the llr.ini like: Code: StopOnPrimedK=1 ks38=1 Here only one prime has to be found for every k-value and for k=38 there exist a prime already. LLR V3.8.2 uses gwnum V26.2, so all speedups are in there with sometimes about 20% more speed! See the source in gwnum.h Code: #define GWNUM_VERSION "26.2" #define GWNUM_MAJOR_VERSION 26 #define GWNUM_MINOR_VERSION 2
Great, in a couple of hours I'll then update my quad to do only LLR. I'll wait a couple of days to update my Dual core since it is a bit more work, since I split up the work file over several libraries. Thanks for your replys, and to Jean I must admit that now LLR is going to be my favourite testing tool for quite some time, since it is not only more flexible compared to PFGW at current, but it sometimes also saves some testing time, when a Prime is found

Kenneth!

2010-09-30, 21:41   #10
mdettweiler
A Sunny Moo

Aug 2007
USA (GMT-5)

624910 Posts

Quote:
 Originally Posted by KEP Great, in a couple of hours I'll then update my quad to do only LLR. I'll wait a couple of days to update my Dual core since it is a bit more work, since I split up the work file over several libraries. Thanks for your replys, and to Jean I must admit that now LLR is going to be my favourite testing tool for quite some time, since it is not only more flexible compared to PFGW at current, but it sometimes also saves some testing time, when a Prime is found Kenneth!
Note that the latest PFGW 3.4.1 also uses gwnum 26.2, so they're even on speed. In fact, the latest PFGW also has a 64-bit version available which is even faster than the 32-bit version.

2010-10-01, 10:59   #11
KEP
Quasi Admin Thing

May 2005

911 Posts

Quote:
 Originally Posted by mdettweiler Note that the latest PFGW 3.4.1 also uses gwnum 26.2, so they're even on speed. In fact, the latest PFGW also has a 64-bit version available which is even faster than the 32-bit version.
Well I didn't know that. But since I've no 64-bit machines, there really is no difference. However what seems to be a timesaving feature in LLR, is that a PRP is automatically verified as prime, if the GCD's end up stating that the PRP is in fact co-prime to something (something makes out for the part of the proof that I can not remember currently). Anyway, since LLR automatically verifies a PRP as prime in a few seconds, then no verification is later needed, hence in most cases 1 test or more is saved. On S58, it appears that the speed advantage is about 15-20+ % on my Q6600. So unless another alternativ that makes PFGW or other programs more effective and userfriendly than LLR, I'll most likely use LLR for next months until S58 completes to n=125K.

Take care!

Kenneth

Ps. Btw "Tumo" mentioned something in an e-mail to me, regarding numbers having GCD errors, wich could rule them out very fast from testings. But Jean said to me that it would take almost the same amount of iterations to find the GCD's for a N-1 or N+1 test as it would take to do a normal testing. So is Tumo right or is Jean right? My feeling is that Jean is right, but if Tumo is right, does anyone know how to implement a method to find GCD errors, since it sound a lot faster than sieving, if possible...

 Thread Tools

 Similar Threads Thread Thread Starter Forum Replies Last Post Orgasmic Troll Math 61 2017-04-05 19:28 Unregistered Information & Answers 5 2011-08-10 01:38 Andi47 GMP-ECM 2 2009-01-17 10:11 koekie Software 4 2009-01-02 07:10 MarcGetty Software 3 2006-03-07 07:54

All times are UTC. The time now is 09:18.

Thu Jul 2 09:18:03 UTC 2020 up 99 days, 6:51, 0 users, load averages: 2.10, 1.75, 1.65

Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2020, Jelsoft Enterprises Ltd.

This forum has received and complied with 0 (zero) government requests for information.

Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.2 or any later version published by the Free Software Foundation.
A copy of the license is included in the FAQ.