mersenneforum.org

mersenneforum.org (https://www.mersenneforum.org/index.php)
-   Software (https://www.mersenneforum.org/forumdisplay.php?f=10)
-   -   PFGW 3.8.3 (with gwnum v28.7) Released (https://www.mersenneforum.org/showthread.php?t=13969)

rogue 2010-09-25 16:45

PFGW 3.8.3 (with gwnum v28.7) Released
 
I have released PFGW 3.4.0. You can d/l it from [URL="http://sourceforge.net/projects/openpfgw/files/"]here[/URL].

Here are the highlights of this release:
[list][*]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).[/list]
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=rogue;231402][*]Upgraded to gwnum v26.2.[/QUOTE]

Check out the known bugs in 26.2 to see if this PFGW version is for you: [url]http://www.mersenneforum.org/showpost.php?p=229781&postcount=2[/url]

rogue 2010-09-25 23:28

[QUOTE=Prime95;231455]Check out the known bugs in 26.2 to see if this PFGW version is for you: [url]http://www.mersenneforum.org/showpost.php?p=229781&postcount=2[/url][/QUOTE]

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=vmod;231474]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.[/QUOTE]

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=rogue;231512]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.[/QUOTE]

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.

[B]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).[/B]

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.


All times are UTC. The time now is 03:08.

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