PFGW 4.0.4 (with gwnum v30.10) Released

rogue · 2010-09-25, 16:45

I have released PFGW 3.4.0. You can d/l it from here.

Here are the highlights of this release:

Upgraded to gwnum v26.2
Upgraded to use GMP 5.0
First 64-bit release of PFGW. Both 32-bit and 64-bit distributed together. Note that using -f with 64-bit could be slower than 32-bit as PFGW doesn't have unrolled 64-bit ASM code for factoring. At worst case, it will be about half the speed, but since the executable is 64-bit and using GMP 5.0, the factoring speed should be close to the 32-bit version.
Released with Visual Studio 2010 to bypass VS2008 linker problems. The new solution and project files for VS2010 have been signficantly cleaned up so that objects for the different builds aren't placed in the same directories.
Renamed executables to pfgw32/pfgw64 and Win32PFGW/Win64PFGW.
Fixed an crash which can occur when processing ABC2 files. It can occur when processing of an ABC2 file is stopped mid-stream, then the ABC2 file is modified, then PFGW is restarted. PFGW should restart from the beginning of the file, but was actually crashing when this would happen.
Note that *nix builds require a number of changes to makefiles to build for a 64-bit environment. This will be fixed in a future release (and hopefully the next release).

The 64-bit should be about 10% faster than the 32-bit build because the gwnum code can take advantage of additional registers.

I could only do so much testing of the 64-bit build of PFGW. I have tested (to some extent) the 64-bit Mac and Windows builds and am continuing to test them. A 64-bit build for Linux has not been included as it has not been built yet. This is related my last note above. I need to make it easier for the average person to build PFGW. It is just too difficult to do on *nix, now more so than ever since it needs to build both with a single makefile.

Prime95 · 2010-09-25, 22:42

Quote:

Originally Posted by rogue

[*]Upgraded to gwnum v26.2.

Check out the known bugs in 26.2 to see if this PFGW version is for you: http://www.mersenneforum.org/showpos...81&postcount=2

rogue · 2010-09-25, 23:28

Quote:

Originally Posted by Prime95

Check out the known bugs in 26.2 to see if this PFGW version is for you: http://www.mersenneforum.org/showpos...81&postcount=2

Ah yes, I forgot the mention that link.

vmod · 2010-09-26, 02:59

I've noticed the Windows 64bit app crashing on N-1 tests (on Windows7 x64, Core2 Q9450).

Tried various numbers (e.g. 201574*35^25276+1, 12*919^45358+1), it crashes each time at the end of the N-1 test.

PRP and N+1 tests are working fine.

rogue · 2010-09-26, 12:32

Quote:

Originally Posted by vmod

I've noticed the Windows 64bit app crashing on N-1 tests (on Windows7 x64, Core2 Q9450).

Tried various numbers (e.g. 201574*35^25276+1, 12*919^45358+1), it crashes each time at the end of the N-1 test.

PRP and N+1 tests are working fine.

The crash occurs in the GMP library for Windows (MPIR). I don't know the specific problem, but I will investigate. I can say that the problem is Windows specific. I have not been able to reproduce on MacIntel, even with a generic GMP library. More updates to follow.

rogue · 2010-09-26, 17:05

Quote:

Originally Posted by rogue

The crash occurs in the GMP library for Windows (MPIR). I don't know the specific problem, but I will investigate. I can say that the problem is Windows specific. I have not been able to reproduce on MacIntel, even with a generic GMP library. More updates to follow.

Note that this will only affect primality tests and can affect factoring. This does not affect all primality tests, only certain tests. I haven't had time to discover what is wrong with MPIR.

CRGreathouse · 2010-09-26, 23:37

The linux version seems to have only a 32-bit version. Why is that?

Mathew · 2010-09-26, 23:48

CRGreathouse,

Last bullet on rogue's first post.

Note that *nix builds require a number of changes to makefiles to build for a 64-bit environment. This will be fixed in a future release (and hopefully the next release).

CRGreathouse · 2010-09-26, 23:53

Thanks, I missed that.

rogue · 2010-09-27, 16:38

I believe that I have narrowed down the issue in PFGW 3.4.0. Right now it appears to be in a routine that converts between gwdata and mpz_t format. The gwnum routine does not appear to be converting all of the limbs correctly. The conversion leads to leading limbs that are zero, which triggers a division by zero error in MPIR.

I've sent an e-mail to George. If it is in gwnum, then I don't know why it hasn't appeared on MacIntel, since that is also using gwnum v26.2.

rogue · 2010-09-27, 17:58

George sent me a fix, which solved the problem. It had to do with the M$ compiler always defining a long to be 32-bits in size, even for 64-bit applications.

2010-09-25, 16:45	#1
rogue "Mark" Apr 2003 Between here and the 1B3D₁₆ Posts	PFGW 4.0.4 (with gwnum v30.10) Released I have released PFGW 3.4.0. You can d/l it from here. Here are the highlights of this release: Upgraded to gwnum v26.2 Upgraded to use GMP 5.0 First 64-bit release of PFGW. Both 32-bit and 64-bit distributed together. Note that using -f with 64-bit could be slower than 32-bit as PFGW doesn't have unrolled 64-bit ASM code for factoring. At worst case, it will be about half the speed, but since the executable is 64-bit and using GMP 5.0, the factoring speed should be close to the 32-bit version. Released with Visual Studio 2010 to bypass VS2008 linker problems. The new solution and project files for VS2010 have been signficantly cleaned up so that objects for the different builds aren't placed in the same directories. Renamed executables to pfgw32/pfgw64 and Win32PFGW/Win64PFGW. Fixed an crash which can occur when processing ABC2 files. It can occur when processing of an ABC2 file is stopped mid-stream, then the ABC2 file is modified, then PFGW is restarted. PFGW should restart from the beginning of the file, but was actually crashing when this would happen. Note that nix builds require a number of changes to makefiles to build for a 64-bit environment. This will be fixed in a future release (and hopefully the next release). The 64-bit should be about 10% faster than the 32-bit build because the gwnum code can take advantage of additional registers. I could only do so much testing of the 64-bit build of PFGW. I have tested (to some extent) the 64-bit Mac and Windows builds and am continuing to test them. A 64-bit build for Linux has not been included as it has not been built yet. This is related my last note above. I need to make it easier for the average person to build PFGW. It is just too difficult to do on nix, now more so than ever since it needs to build both with a single makefile.

Similar Threads
Thread	Thread Starter	Forum	Replies	Last Post
A possible bug in LLR/PFGW while using GWNUM (no bug in P95)	Batalov	Software	77	2015-04-14 09:01
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.1 has been released	rogue	Software	5	2009-08-10 01:43
PFGW 3.1.0 has been Released	rogue	Software	25	2009-07-21 18:13

2010-09-26, 02:59	#4
vmod Mar 2010 Hampshire, UK 3·17 Posts	I've noticed the Windows 64bit app crashing on N-1 tests (on Windows7 x64, Core2 Q9450). Tried various numbers (e.g. 20157435^25276+1, 12919^45358+1), it crashes each time at the end of the N-1 test. PRP and N+1 tests are working fine.

2010-09-26, 23:37	#7
CRGreathouse Aug 2006 1763₁₆ Posts	The linux version seems to have only a 32-bit version. Why is that?

2010-09-26, 23:48	#8
Mathew Nov 2009 2×5²×7 Posts	CRGreathouse, Last bullet on rogue's first post. *Note that nix builds require a number of changes to makefiles to build for a 64-bit environment. This will be fixed in a future release (and hopefully the next release).**

2010-09-26, 23:53	#9
CRGreathouse Aug 2006 5,987 Posts	Thanks, I missed that.

2010-09-27, 16:38	#10
rogue "Mark" Apr 2003 Between here and the 19·367 Posts	I believe that I have narrowed down the issue in PFGW 3.4.0. Right now it appears to be in a routine that converts between gwdata and mpz_t format. The gwnum routine does not appear to be converting all of the limbs correctly. The conversion leads to leading limbs that are zero, which triggers a division by zero error in MPIR. I've sent an e-mail to George. If it is in gwnum, then I don't know why it hasn't appeared on MacIntel, since that is also using gwnum v26.2.

2010-09-27, 17:58	#11
rogue "Mark" Apr 2003 Between here and the 15475₈ Posts	George sent me a fix, which solved the problem. It had to do with the M$ compiler always defining a long to be 32-bits in size, even for 64-bit applications.