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!
[B] 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.
[/B] 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).
[/code]
The lines in bold will be of particular interest to CRUS searchers. :smile: (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).

LLR 3.8.2 features == LLR 3.8.1 ones!
 

[QUOTE=mdettweiler;232013]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!
[B] 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.
[/B] 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).
[/code]
The lines in bold will be of particular interest to CRUS searchers. :smile: (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).[/QUOTE]


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

[QUOTE=Jean Penné;232016]It was already available in Version 3.8.1!
I did'nt add nor change any feature in this new version...
Jean[/QUOTE]
Hmm, I didn't know that...I guess I never did bother to read the readme for 3.8.1. :rolleyes:

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

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

[QUOTE=KEP;232085]Finally, is LLR version 3.8.2 with the latest GWnum build, such that there can be a usefull 10% speedincrease on each tests?[/QUOTE]
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:smile:).

[QUOTE=KEP;232085]Is the StopOnPrimedK=<number>, remembering wich k's has previously been primed, in case LLR has to be stopped?
[/quote]

Yes, LLR recognize a found value in the llr.ini like:
[code]
StopOnPrimedK=1
ks38=1
[/code]

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?
[/QUOTE]

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
[/code]

[QUOTE=kar_bon;232088]Yes, LLR recognize a found value in the llr.ini like:
[code]
StopOnPrimedK=1
ks38=1
[/code]Here only one prime has to be found for every k-value and for k=38 there exist a prime already.

[/QUOTE]
That is better than pfgw.

[QUOTE=kar_bon;232088]Yes, LLR recognize a found value in the llr.ini like:
[code]
StopOnPrimedK=1
ks38=1
[/code]

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
[/code][/QUOTE]

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 :smile:

Kenneth!

[QUOTE=KEP;232103]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 :smile:

Kenneth![/QUOTE]
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.

[QUOTE=mdettweiler;232121]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.[/QUOTE]

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

[QUOTE=KEP;232200]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.[/QUOTE]

15-20%? On each test? PFGW 3.4 vs LLR 3.8.2?

Since you split up your work across multiple CPUs, PRPNet could save you a lot of time. In PRPNet 4.0, you will able to tell it to force clients to use LLR for non-base 2 work (if LLR is available).

Actually I forgot to mention that the next release of PRPNet will be 4.0, not 3.4 as I had stated elsewhere. The changes are significant to both client and server. 3.3 clients can communicate with 4.0 servers and 4.0 clients can communicate with 3.3 servers.

[QUOTE=rogue;232210]15-20%? On each test? PFGW 3.4 vs LLR 3.8.2?

Since you split up your work across multiple CPUs, PRPNet could save you a lot of time. In PRPNet 4.0, you will able to tell it to force clients to use LLR for non-base 2 work (if LLR is available).

Actually I forgot to mention that the next release of PRPNet will be 4.0, not 3.4 as I had stated elsewhere. The changes are significant to both client and server. 3.3 clients can communicate with 4.0 servers and 4.0 clients can communicate with 3.3 servers.[/QUOTE]

The speeddifference would be for version 3.3.6 and prior, compared to LLR 3.8.2, I actually never got the PRPnet setup to work, and since I'm only using 4 cores to test S58 and 2 cores to test S60, there will most likely not be saved much time, if any at all, since I now have made all 4 input files for LLR to run on the Quad and both input files for LLR to run on the Dual core. If/when a Top5000 prime is found, I'll remember to mention PFGW in the provercode, since most of the n<=65K for S58 and for 12 k's on S58 n<=125K work was done using PFGW. So it is only fair, even if LLR is going to do the remaining work.

Hope I got it all mentioned, else ask again :smile:

Take care

Kenneth!

[QUOTE=KEP;232213]The speeddifference would be for version 3.3.6 and prior, compared to LLR 3.8.2, I actually never got the PRPnet setup to work, and since I'm only using 4 cores to test S58 and 2 cores to test S60.[/QUOTE]

You can only save yourself time if splitting by k instead of n.

Anyways, PRPNet is really easy to set up, so if you have problems, let me know and I'll walk you through getting it going. Trust me that it is easier to monitor the PRPNet server via the web (and to have e-mails notify you of primes) than to monitor multiple copies of LLR/PFGW, especially if they are on multiple machines. The great thing is that if you fear running dry, you can dump more candidates into the server without touching any of the clients. Any hassling you do to start/stop LLR/PFGW while changing input files would go away.

[QUOTE=rogue;232218]You can only save yourself time if splitting by k instead of n.

Anyways, PRPNet is really easy to set up, so if you have problems, let me know and I'll walk you through getting it going. Trust me that it is easier to monitor the PRPNet server via the web (and to have e-mails notify you of primes) than to monitor multiple copies of LLR/PFGW, especially if they are on multiple machines. The great thing is that if you fear running dry, you can dump more candidates into the server without touching any of the clients. Any hassling you do to start/stop LLR/PFGW while changing input files would go away.[/QUOTE]
@KEP: Also, as you may recall I have an open offer to host a private PRPnet server on the noprimeleftbehind.net equipment for anyone who's interested. If your machines are internet-connected, this may be somewhat simpler than setting up your own PRPnet server.

[QUOTE=mdettweiler;232226]@KEP: Also, as you may recall I have an open offer to host a private PRPnet server on the noprimeleftbehind.net equipment for anyone who's interested. If your machines are internet-connected, this may be somewhat simpler than setting up your own PRPnet server.[/QUOTE]

It is simpler, but only problem is that my Quad core is not internetconnected, and as soon as the Dual core completes the S60 work, I'll most likely retire the Dual core, since it is getting more and more outdated, so your offer regarding a PRPnet server, can not be taken up by me, even though its a nice offer from you. In case you all wonder why, my Quad is not internetconnected, it is a matter of finances. If I decide to put my Quad behind an internet connection, I have to pay a sort of tv fee to the public national tv station, plus I has to pay for cable and internet in addition to that. That would total around 200 USD each month or the same as it would cost to have at least 1 extra quad running.

@ Rogue: In case you havent understood what I meant, there is sometimes a timesaving when a prime is found, because LLR can with the use of GCD's tell if the prime is a strong PRP (however N is divided by a) therefor PRP can only be determined, but in most cases, LLR in less than a second determines weather or not a PRP is in fact prime. In the cases where a divide N-/+1, LLR typically do a second test. It is my experience (and that may have changed) that PFGW in most cases has to do a PRP test, and then at least 1 Full N-1 or N+1 test. When tests are growing bigger and bigger, more and more time will have to be used per test, and since LLR typically in short time tells weather or not the PRP in fact is prime, only a little more time than 1 full test has to be needed, to verify the k*b^n+c test as prime. Hence at least 1 test is saved. That was what I meant by timesaving. :smile:

But thanks for your offer to help me, however for now I think that I'll stick to the solution that I has for now, in stead of hazzeling with setting up a PRPnet system. Btw. LLR remembers the primed k's even if it has to be stopped during testing, is it not possible to add the same feature to PFGW? It would really save a lot of changing of input files, and then loose a lot of time on doing manual editing of the workfiles.

Kenneth

[QUOTE=KEP;232231]It is simpler, but only problem is that my Quad core is not internetconnected, and as soon as the Dual core completes the S60 work, I'll most likely retire the Dual core, since it is getting more and more outdated, so your offer regarding a PRPnet server, can not be taken up by me, even though its a nice offer from you. In case you all wonder why, my Quad is not internetconnected, it is a matter of finances. If I decide to put my Quad behind an internet connection, I have to pay a sort of tv fee to the public national tv station, plus I has to pay for cable and internet in addition to that. That would total around 200 USD each month or the same as it would cost to have at least 1 extra quad running.[/QUOTE]

You don't need internet for PRPNet. You can use a cross-over cable to connect two computers. For a single computer with multiple cores, the server is just another process that takes very little CPU. The clients connect by specifying "localhost" as the server name in their respective ini files.

[QUOTE=KEP;232231]@ Rogue: In case you havent understood what I meant, there is sometimes a timesaving when a prime is found, because LLR can with the use of GCD's tell if the prime is a strong PRP (however N is divided by a) therefor PRP can only be determined, but in most cases, LLR in less than a second determines weather or not a PRP is in fact prime. In the cases where a divide N-/+1, LLR typically do a second test. It is my experience (and that may have changed) that PFGW in most cases has to do a PRP test, and then at least 1 Full N-1 or N+1 test. When tests are growing bigger and bigger, more and more time will have to be used per test, and since LLR typically in short time tells weather or not the PRP in fact is prime, only a little more time than 1 full test has to be needed, to verify the k*b^n+c test as prime. Hence at least 1 test is saved. That was what I meant by timesaving. :smile:[/QUOTE]

I understood what you meant, which is why PRPNet 4.0 can tell the client (via the server) to use LLR instead of PFGW. If LLR returns "PRIME" on a PRP test, then no additional test will be done by the client.

[QUOTE=KEP;232231]Btw. LLR remembers the primed k's even if it has to be stopped during testing, is it not possible to add the same feature to PFGW? It would really save a lot of changing of input files, and then loose a lot of time on doing manual editing of the workfiles.[/QUOTE]

I have considered such a change, but haven't thought very much about how to do it. I could either do it like LLR or I could have PFGW read the pfgw.log file for PRPs and then eliminate values that way. I think I like the LLR method better.

[QUOTE=rogue;232233]You don't need internet for PRPNet. You can use a cross-over cable to connect two computers. For a single computer with multiple cores, the server is just another process that takes very little CPU. The clients connect by specifying "localhost" as the server name in their respective ini files.[/QUOTE]

OK, that answer at least solved one of my problems, but I still might need some help on the building of the database. However I'm not going to be able to look further into it untill maybe sunday, but I think that I'll give it a retry and then ask you or Max, for a solution whenever a problem occurs. Thanks for your reply.

Take care

Kenneth

[QUOTE=KEP;232239]OK, that answer at least solved one of my problems, but I still might need some help on the building of the database. However I'm not going to be able to look further into it untill maybe sunday, but I think that I'll give it a retry and then ask you or Max, for a solution whenever a problem occurs. Thanks for your reply.[/QUOTE]

server/readme.txt tells you how to set it up, which is this:
[list][*]If necessary d/l MySQL from [url]http://www.mysql.com[/url] and install it.[*]Create a new database using the mysqladmin tool.[*]Connect to your new database.[*]Create the PRPNet tables using the create_tables.sql script found in the source directory.[*]Load the database with an ABC file via the prpadmin tool.[/list]
On the client side you will need the MySQL ODBC driver, which is easy to install.

[QUOTE=rogue;232242]On the client side you will need the MySQL ODBC driver, which is easy to install.[/QUOTE]
To clarify further: this is for the PRPnet [i]server[/i] to connect to MySQL as a client. You do not need the ODBC driver on machines running only the PRPnet client.

[QUOTE=mdettweiler;232262]To clarify further: this is for the PRPnet [i]server[/i] to connect to MySQL as a client. You do not need the ODBC driver on machines running only the PRPnet client.[/QUOTE]

Oops. Yes, you are correct. I've installed PRPNet on Windows and Mac OS X without problems. PrimeGrid runs PRPNet on Linux without problems.

Thanks for the info Rogue and Max, I'll download the nescessary files in just a short while, and then I'll give it another try. Even though it is not something I am very experienced with, this might actually offer me an opportunity to learn and get experienced about something that is new to me :smile:. If I meet any problems, I'll send you a PM. But with the latest posting in mind, and the clarification of the hostpointing, I'm convinced that I should be able to get somehow a bit further than last i tried to make my Quad work as both a server aswell as a client using PRPnet.

Take care

Kenneth