LLR 3.8.2: more flexible stop-on-prime option

mdettweiler · 2010-09-30, 05:25

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=<number> : after <number> sucesses with this k value,
      skip further pairs having the same k value (usually, <number> = 1).
    StopOnPrimedN=<number> : Same thing, involving the value of n.
    StopOnPrimedB=<number> : 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=<bits> : 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).

Jean Penné · 2010-09-30, 05:55

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=<number> : after <number> sucesses with this k value,
      skip further pairs having the same k value (usually, <number> = 1).
    StopOnPrimedN=<number> : Same thing, involving the value of n.
    StopOnPrimedB=<number> : 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=<bits> : 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

mdettweiler · 2010-09-30, 06:12

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.

gd_barnes · 2010-09-30, 09:10

Very cool. Nor did I know that. Thanks for letting us know.

KEP · 2010-09-30, 16:26

Very cool Jean. Thanks for adding this. Now a question or 2. Is the StopOnPrimedK=<number>, 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

henryzz · 2010-09-30, 16:34

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

).

kar_bon · 2010-09-30, 16:37

Quote:

Originally Posted by KEP

Is the StopOnPrimedK=<number>, 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

henryzz · 2010-09-30, 16:50

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.

KEP · 2010-09-30, 19:24

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!

mdettweiler · 2010-09-30, 21:41

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.

KEP · 2010-10-01, 10:59

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...

Similar Threads
Thread	Thread Starter	Forum	Replies	Last Post
Prime generating polynomials that stop?	Orgasmic Troll	Math	61	2017-04-05 19:28
when does prime seach stop?	Unregistered	Information & Answers	5	2011-08-10 01:38
How exactly does the -I option work?	Andi47	GMP-ECM	2	2009-01-17 10:11
mprime -b cli option gone?!?	koekie	Software	4	2009-01-02 07:10
Start and Stop Prime 95 on Large Groups of Windows XP Machines	MarcGetty	Software	3	2006-03-07 07:54

2010-09-30, 09:10	#4
gd_barnes May 2007 Kansas; USA 10100010100011₂ 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 2·3·7·23 Posts	Very cool Jean. Thanks for adding this. Now a question or 2. Is the StopOnPrimedK=<number>, 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