PFGW 3.1.0 has been Released

rogue · 2009-07-09, 00:49

I have posted the latest Windows and MacIntel distributions at these links:

http://openpfgw.svn.sourceforge.net/...1_20090708.zip
http://openpfgw.svn.sourceforge.net/...1_20090708.zip

This marks the first release of PFGW for MacIntel.

Enhancements to: v3.1.0 RC 1b

Updated external version to meet intenal version.
Updated to v25.11 of George Woltman's gwnum library.
Use new modular reduction routines in gwnum for k*b^n+/-c forms. This is about twice as fast as prior releases when k > 1 and almost 6 times as fast when k = 1 and b > 2. GFNs already use this same modular reductino code.
Removed special GFN PRP code as it is no longer necessary due to new modular reduction code for k*b^n+/-c forms.
Set default priority class to BELOW_NORMAL (instead of NORMAL) on Windows.
Set priority to 20 (low) on *nix and MacIntel.
Increased limits for factorials to 1,000,000.
Increased limits for primorials to 20,000,000.
Modified -r switch to act as a boolean. Using it will force PFGW to do roundoff checking for all iterations of all tests.
Enhanced error checking so that PFGW can conditionally do MAXERR testing on individual tests or specific iterations of tests. In this release PFGW will do MAXERR checking on the first and last 50 itererations of each test and every 128th iteration of each test. It can test all iterations of each test if the -r switch is used or if the number being testing is within 2% of the limit of the chosen FFT size. This will be much more in-line with how Prime95 does MAXERR testing.
GFN factoring now checks for ROUNDOFF, SUMOUT, and MAXERR conditions so that it can be aborted if a problem is detected. This means that PFGW will now tell the user that they must use the -a switch when a problem is detected.
Add call to gwset_square_carefully_count() after creating the modulus so that gwnum can use "safe" squaring on the first few iterations of PRP tests or GFN factoring. This will significantly reduce the likelihood that the -a switch will be needed.
Based upon George's recommendation (due to the improved error checking), MAXERR is now set to 0.45 instead of 0.40.
Call new gwinit2() function so that PFGW can verify that it is linked against the correct version of the gwnum library and so that it can verify that PFGW uses the same compiler switches that were used to build gwnum.

I am not aware of any issues with this release, but I only have limited resources for my testing. For example, I cannot test against P3 (or older), Centrino, or AMD CPUs.

The two biggest changes of interest to casual users is that PFGW should now be faster than LLR for bases that are not powers of 2. I suspect Jean Penne will make the appropriate changes to LLR to take advantage of the same modular code that PFGW is now using. I have not compared base 2 tests between the two programs. The other is that the -a switch is not required for GFN factoring and that PFGW will now tell you if an error occurred during GFN factoring.

Many thanks to George for his enhancements to gwnum that were done specifically for PFGW.

I do have a volunteer for building on linux, so hopefully I can make a linux distribution available in the near future.

I will be on vacation for a few days, so please be patient if you run into any issues that need to be addressed.

Enjoy,
Mark

mdettweiler · 2009-07-09, 01:51

A couple questions:

-For non-power-of-2 bases, for which PFGW now does PRP tests faster than LLR, does PFGW provide a residual of the same length as LLR/Phrot? Or does it still only give a shorter one, like older versions did?

-When will a new version of the PRPnet client be released to use PFGW by default instead of LLR for non-power-of-2 PRP tests?

rogue · 2009-07-09, 02:30

Quote:

Originally Posted by mdettweiler

A couple questions:

-For non-power-of-2 bases, for which PFGW now does PRP tests faster than LLR, does PFGW provide a residual of the same length as LLR/Phrot? Or does it still only give a shorter one, like older versions did?

-When will a new version of the PRPnet client be released to use PFGW by default instead of LLR for non-power-of-2 PRP tests?

PFGW how has 16 character residues, i.e. it adds leading zeros. If using PRPNet 2.2.x, that shouldn't matter as it will ignore leading zeroes when comparing residues.

I don't have an answer for the second question. I could make the change fairly easily, but I expect Jean to modify LLR to take advantage of George's new code. I do not know when that will happen. I haven't heard from Jean, but am willing to help him with the changes when he is ready (presuming he needs any help).

mdettweiler · 2009-07-09, 03:00

Quote:

Originally Posted by rogue

PFGW how has 16 character residues, i.e. it adds leading zeros. If using PRPNet 2.2.x, that shouldn't matter as it will ignore leading zeroes when comparing residues.

I don't have an answer for the second question. I could make the change fairly easily, but I expect Jean to modify LLR to take advantage of George's new code. I do not know when that will happen. I haven't heard from Jean, but am willing to help him with the changes when he is ready (presuming he needs any help).

Oh, I see. Okay, I guess that works fine then. At this time having a shorter residue should still work fine for CRUS, though not for NPLB since there we have our database handle comparisons between firstpass and doublecheck residues. But then, at NPLB we only do base 2 work, so thus it's somewhat of a moot point.

At any rate, yes, I agree that it would probably be better to simply wait for the updated version of LLR (assuming it comes out soon, and the changes are not delayed until version 3.7.1d which I hear has been in the works for a while and hasn't yet materialized) rather than updating PRPnet. That way the whole thing with the residues should be no big deal at all.

mdettweiler · 2009-07-15, 16:44

I've done some benchmarks to compare LLR 3.7.1c, Phrot 0.70, PFGW 3.1.0, and Prime95 25.11 on a Riesel base 3 PRP test:

Code:

17589196*3^78001-1 is composite: RES64: [229FF2F0D0593F25] (33.5454s+0.0024s)
17589196*3^78001-1 is not prime.  RES64: E29FF2F0D0593F25  OLD64: A7DFD8D2710BBD6C  Time : 93.840 sec.
17589196*3^78001-1 is composite LLR64=e29ff2f0d0593f25. (e=0.09375 (0.160502~4.7607e-016@0.000) t=77.53s)
17589196*3^78001-1 is not prime.  RES64: E29FF2F0D0593F25. Wd1: 41B08704,00000000

Note: even though Prime95 does not record times, it was about the same speed as PFGW, as expected.

I'm surprised at just how much of a speed boost there was--the programs utilizing the new gwnum 25.11 (PFGW and Prime95) all had about a 64% speed increase over LLR 3.7.1c (i.e. gwnum 24.14). Compared to Phrot, there was a 57% speed increase.

Interestingly enough, I discovered that PFGW *does* give full 16 character residues now, and not just by zero-padding a smaller one. However, quite oddly, the PFGW residue matches all of the others, except for the first character! And it's reproducible, too, so this is not just some exceedingly improbable fluke.

I'm going to try running some further tests with PFGW to see if the residue goof appears in other numbers as well.

Meanwhile, for people testing non-power-of-2 k*b^n+-c numbers right now, I would recommend using Prime95 v25.11, at least until an updated LLR comes out. Prime95 has all the same speed boosts in it as PFGW, yet it doesn't suffer from the weird residue glitch. For instructions on how to use Prime95 to do PRP tests, see this post. (The last part about Prime95's speed relative to LLR can be ignored, since it relates specifically to base 2 numbers, which the speed boosts do not affect.)

rogue · 2009-07-15, 17:39

Quote:

Originally Posted by mdettweiler

I've done some benchmarks to compare LLR 3.7.1c, Phrot 0.70, PFGW 3.1.0, and Prime95 25.11 on a Riesel base 3 PRP test:

Code:

17589196*3^78001-1 is composite: RES64: [229FF2F0D0593F25] (33.5454s+0.0024s)
17589196*3^78001-1 is not prime.  RES64: E29FF2F0D0593F25  OLD64: A7DFD8D2710BBD6C  Time : 93.840 sec.
17589196*3^78001-1 is composite LLR64=e29ff2f0d0593f25. (e=0.09375 (0.160502~4.7607e-016@0.000) t=77.53s)
17589196*3^78001-1 is not prime.  RES64: E29FF2F0D0593F25. Wd1: 41B08704,00000000

Note: even though Prime95 does not record times, it was about the same speed as PFGW, as expected.

I'm surprised at just how much of a speed boost there was--the programs utilizing the new gwnum 25.11 (PFGW and Prime95) all had about a 64% speed increase over LLR 3.7.1c (i.e. gwnum 24.14). Compared to Phrot, there was a 57% speed increase.

Interestingly enough, I discovered that PFGW *does* give full 16 character residues now, and not just by zero-padding a smaller one. However, quite oddly, the PFGW residue matches all of the others, except for the first character! And it's reproducible, too, so this is not just some exceedingly improbable fluke.

I'm going to try running some further tests with PFGW to see if the residue goof appears in other numbers as well.

Meanwhile, for people testing non-power-of-2 k*b^n+-c numbers right now, I would recommend using Prime95 v25.11, at least until an updated LLR comes out. Prime95 has all the same speed boosts in it as PFGW, yet it doesn't suffer from the weird residue glitch. For instructions on how to use Prime95 to do PRP tests, see this post. (The last part about Prime95's speed relative to LLR can be ignored, since it relates specifically to base 2 numbers, which the speed boosts do not affect.)

Don't worry too much about the residue "glitch" at this time. PFGW residues are 62-bit, not 64-bit, thus the difference. Since I am the "owner" of PFGW now, I will look into it and see what I can do to support 64-bit residues. Chances of a bad test where the lower 62 bits of the residue match those of a good test are extremely small because PFGW does all sorts of error checking to ensure that the test has not failed along the way.

BTW, PRPNet ignores the first non-zero character because it knows about this limitation with PFGW.

My recommendation is still to use PFGW since it supports ABC and NewPGen input files.

rogue · 2009-07-15, 22:39

Quote:

Originally Posted by rogue

Don't worry too much about the residue "glitch" at this time. PFGW residues are 62-bit, not 64-bit, thus the difference. Since I am the "owner" of PFGW now, I will look into it and see what I can do to support 64-bit residues. Chances of a bad test where the lower 62 bits of the residue match those of a good test are extremely small because PFGW does all sorts of error checking to ensure that the test has not failed along the way.

The next release will have 64-bit residues. I made a change today and it appears to be working correctly.

henryzz · 2009-07-18, 12:40

Would it be possible for PFGW to use Prime95's P-1 code?
If it could then output factors in srsieve's factors.txt format that would be brill.

ET_ · 2009-07-18, 13:38

Quote:

Originally Posted by rogue

The next release will have 64-bit residues. I made a change today and it appears to be working correctly.

Waiting for the new release to update Fermatsearch download page. Thanks Mark!

Luigi

rogue · 2009-07-18, 15:25

Quote:

Originally Posted by henryzz

Would it be possible for PFGW to use Prime95's P-1 code?
If it could then output factors in srsieve's factors.txt format that would be brill.

Possibly, but why not us Prime95 or GMP-ECM? IIRC GMP-ECM can link with gwnum to assist in factoring.

henryzz · 2009-07-18, 16:46

Quote:

Originally Posted by rogue

Possibly, but why not us Prime95 or GMP-ECM? IIRC GMP-ECM can link with gwnum to assist in factoring.

both prime95 and gmp-ecm dont support any of the usual formats for primality testing
also from memory compiling gmp-ecm with gwnum is a massive exercise
both programs also output in convoluted ways which would require a script to extract the factors

why waste time having a complicated script when it could be done even easier by pfgw?

2009-07-09, 00:49	#1
rogue "Mark" Apr 2003 Between here and the 1B32₁₆ Posts	PFGW 3.1.0 has been Released I have posted the latest Windows and MacIntel distributions at these links: http://openpfgw.svn.sourceforge.net/...1_20090708.zip http://openpfgw.svn.sourceforge.net/...1_20090708.zip This marks the first release of PFGW for MacIntel. Enhancements to: v3.1.0 RC 1b Updated external version to meet intenal version. Updated to v25.11 of George Woltman's gwnum library. Use new modular reduction routines in gwnum for kb^n+/-c forms. This is about twice as fast as prior releases when k > 1 and almost 6 times as fast when k = 1 and b > 2. GFNs already use this same modular reductino code. Removed special GFN PRP code as it is no longer necessary due to new modular reduction code for kb^n+/-c forms. Set default priority class to BELOW_NORMAL (instead of NORMAL) on Windows. Set priority to 20 (low) on *nix and MacIntel. Increased limits for factorials to 1,000,000. Increased limits for primorials to 20,000,000. Modified -r switch to act as a boolean. Using it will force PFGW to do roundoff checking for all iterations of all tests. Enhanced error checking so that PFGW can conditionally do MAXERR testing on individual tests or specific iterations of tests. In this release PFGW will do MAXERR checking on the first and last 50 itererations of each test and every 128th iteration of each test. It can test all iterations of each test if the -r switch is used or if the number being testing is within 2% of the limit of the chosen FFT size. This will be much more in-line with how Prime95 does MAXERR testing. GFN factoring now checks for ROUNDOFF, SUMOUT, and MAXERR conditions so that it can be aborted if a problem is detected. This means that PFGW will now tell the user that they must use the -a switch when a problem is detected. Add call to gwset_square_carefully_count() after creating the modulus so that gwnum can use "safe" squaring on the first few iterations of PRP tests or GFN factoring. This will significantly reduce the likelihood that the -a switch will be needed. Based upon George's recommendation (due to the improved error checking), MAXERR is now set to 0.45 instead of 0.40. Call new gwinit2() function so that PFGW can verify that it is linked against the correct version of the gwnum library and so that it can verify that PFGW uses the same compiler switches that were used to build gwnum. I am not aware of any issues with this release, but I only have limited resources for my testing. For example, I cannot test against P3 (or older), Centrino, or AMD CPUs. The two biggest changes of interest to casual users is that PFGW should now be faster than LLR for bases that are not powers of 2. I suspect Jean Penne will make the appropriate changes to LLR to take advantage of the same modular code that PFGW is now using. I have not compared base 2 tests between the two programs. The other is that the -a switch is not required for GFN factoring and that PFGW will now tell you if an error occurred during GFN factoring. Many thanks to George for his enhancements to gwnum that were done specifically for PFGW. I do have a volunteer for building on linux, so hopefully I can make a linux distribution available in the near future. I will be on vacation for a few days, so please be patient if you run into any issues that need to be addressed. Enjoy, Mark

2009-07-15, 16:44	#5
mdettweiler A Sunny Moo Aug 2007 USA (GMT-5) 6249₁₀ Posts	I've done some benchmarks to compare LLR 3.7.1c, Phrot 0.70, PFGW 3.1.0, and Prime95 25.11 on a Riesel base 3 PRP test: Code: 175891963^78001-1 is composite: RES64: [229FF2F0D0593F25] (33.5454s+0.0024s) 175891963^78001-1 is not prime. RES64: E29FF2F0D0593F25 OLD64: A7DFD8D2710BBD6C Time : 93.840 sec. 175891963^78001-1 is composite LLR64=e29ff2f0d0593f25. (e=0.09375 (0.160502~4.7607e-016@0.000) t=77.53s) 175891963^78001-1 is not prime. RES64: E29FF2F0D0593F25. Wd1: 41B08704,00000000 Note: even though Prime95 does not record times, it was about the same speed as PFGW, as expected. I'm surprised at just how much of a speed boost there was--the programs utilizing the new gwnum 25.11 (PFGW and Prime95) all had about a 64% speed increase over LLR 3.7.1c (i.e. gwnum 24.14). Compared to Phrot, there was a 57% speed increase. Interestingly enough, I discovered that PFGW does give full 16 character residues now, and not just by zero-padding a smaller one. However, quite oddly, the PFGW residue matches all of the others, except for the first character! And it's reproducible, too, so this is not just some exceedingly improbable fluke. I'm going to try running some further tests with PFGW to see if the residue goof appears in other numbers as well. Meanwhile, for people testing non-power-of-2 k*b^n+-c numbers right now, I would recommend using Prime95 v25.11, at least until an updated LLR comes out. Prime95 has all the same speed boosts in it as PFGW, yet it doesn't suffer from the weird residue glitch. For instructions on how to use Prime95 to do PRP tests, see this post. (The last part about Prime95's speed relative to LLR can be ignored, since it relates specifically to base 2 numbers, which the speed boosts do not affect.)

Similar Threads
Thread	Thread Starter	Forum	Replies	Last Post
PFGW 4.0.4 (with gwnum v30.10) Released	rogue	Software	545	2023-01-20 14:12
PFGW 3.2.0 has been Released	rogue	Software	94	2010-09-14 21:39
PFGW 3.2.3 has been Released	rogue	Software	10	2009-10-28 07:07
PFGW 3.2.2 has been Released	rogue	Software	20	2009-08-23 12:14
PFGW 3.2.1 has been released	rogue	Software	5	2009-08-10 01:43

2009-07-09, 01:51	#2
mdettweiler A Sunny Moo Aug 2007 USA (GMT-5) 3×2,083 Posts	A couple questions: -For non-power-of-2 bases, for which PFGW now does PRP tests faster than LLR, does PFGW provide a residual of the same length as LLR/Phrot? Or does it still only give a shorter one, like older versions did? -When will a new version of the PRPnet client be released to use PFGW by default instead of LLR for non-power-of-2 PRP tests?

2009-07-18, 12:40	#8
henryzz Just call me Henry "David" Sep 2007 Liverpool (GMT/BST) 37×163 Posts	Would it be possible for PFGW to use Prime95's P-1 code? If it could then output factors in srsieve's factors.txt format that would be brill.