mersenneforum.org

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

rogue 2010-09-25 16:45

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

Prime95 2010-09-27 19:56

[QUOTE=rogue;231648]It had to do with the M$ compiler always defining a long...[/QUOTE]

To be clear this was my bug, not M$.

rogue 2010-09-27 21:16

[QUOTE=Prime95;231663]To be clear this was my bug, not M$.[/QUOTE]

You know me. I like to blame M$ for these types of things. Seriously though, I don't know what the standard is. The definition was clear when CPUs were 32-bit, but I don't see a standard definition of a long for 64-bit architectures. I would expect an ISO standard, but haven't been able to find it yet.

rogue 2010-09-27 21:46

PFGW 3.4.1 Released
 
I have updated the link for PFGW [URL="http://sourceforge.net/projects/openpfgw/files/"]here[/URL] I am releasing 3.4.1 for Windows only since only Windows was affected by the issue. Although the 32-bit version is included in the zipfile, only the 64-bit bit version has any changes.

mdettweiler 2010-09-28 16:58

Mark, I seem to be getting a slowdown with 32-bit 3.4.0 as opposed to 3.3.6. I noticed this on some base 5 pairs that I was running through PRPnet. I'm using this PRPnet server as filler work between TPS sieve ranges; thus, I worked on it a little a few days ago, then took 3 days or so off to do a sieve range, and am now back on the PRPnet server again. I upgraded PFGW to 3.4.0 in the interim. Here is my test_results.log showing the results before and after the changeover:
[code][2010-09-22 18:42:46 EDT] Candidate: 289184*5^477336-1 Program: pfgw.exe Residue: 08B0E31C3A9EFF00 Time: 3671 seconds
[2010-09-22 19:43:34 EDT] Candidate: 127174*5^477351-1 Program: pfgw.exe Residue: DA00969979D57138 Time: 3644 seconds
[2010-09-22 20:49:24 EDT] Candidate: 207394*5^477357-1 Program: pfgw.exe Residue: 2DB93A71BB0A6D89 Time: 3948 seconds
[2010-09-22 21:57:49 EDT] Candidate: 53542*5^477367-1 Program: pfgw.exe Residue: C219C5F34A2B8D2B Time: 4099 seconds
[2010-09-22 22:59:56 EDT] Candidate: 102818*5^477378-1 Program: pfgw.exe Residue: D78C24D964BE86CA Time: 3720 seconds
[2010-09-23 00:00:25 EDT] Candidate: 64598*5^477390-1 Program: pfgw.exe Residue: 494AE4D759658CE7 Time: 3624 seconds
[2010-09-26 07:39:13 EDT] Candidate: 243944*5^478048-1 Program: pfgw.exe Residue: A48AB870927245F0 Time: 4580 seconds
[2010-09-26 08:55:23 EDT] Candidate: 194368*5^478057-1 Program: pfgw.exe Residue: 3B71DD5DA8AB0BF7 Time: 4567 seconds
[2010-09-26 10:12:28 EDT] Candidate: 259072*5^478063-1 Program: pfgw.exe Residue: 703423F79481265C Time: 4619 seconds
[2010-09-26 11:29:47 EDT] Candidate: 146756*5^478072-1 Program: pfgw.exe Residue: 019D098696437238 Time: 4636 seconds
[2010-09-26 12:18:20 EDT] Candidate: 22478*5^478082-1 Program: pfgw.exe Residue: 5A2455E84FCE318B Time: 2909 seconds
[2010-09-26 13:35:07 EDT] Candidate: 162434*5^478092-1 Program: pfgw.exe Residue: BF3D8B20B48257FE Time: 4601 seconds
[2010-09-26 14:53:18 EDT] Candidate: 268514*5^478100-1 Program: pfgw.exe Residue: 5B30C65AF64582E8 Time: 4688 seconds
[2010-09-26 16:11:34 EDT] Candidate: 119878*5^478109-1 Program: pfgw.exe Residue: 49B7CA1372F2BF82 Time: 4692 seconds
[2010-09-26 17:31:20 EDT] Candidate: 151026*5^478112-1 Program: pfgw.exe Residue: 539CEBED84B56084 Time: 4779 seconds
[2010-09-26 18:49:28 EDT] Candidate: 170386*5^478123-1 Program: pfgw.exe Residue: 51CECE7D80876FA2 Time: 4681 seconds
[2010-09-26 20:06:36 EDT] Candidate: 102818*5^478134-1 Program: pfgw.exe Residue: 039C4C573ADA683D Time: 4620 seconds
[2010-09-26 21:25:08 EDT] Candidate: 262172*5^478138-1 Program: pfgw.exe Residue: 83B5AA2A245C99FD Time: 4705 seconds
[2010-09-26 22:41:43 EDT] Candidate: 105782*5^478154-1 Program: pfgw.exe Residue: 2AEE407A72D331B7 Time: 4583 seconds[/code]
PFGW 3.3.6 got times around 3600-4000 seconds, and 3.4.0 gets around 4600 seconds.

It's possible I just hit an FFT change and this is a fluke...I'll run some quick tests to see if this is the case.

mdettweiler 2010-09-28 17:08

It doesn't look there were any FFT changes. Here's what each version used for pairs before and after the changeover in my above list:
[code]289184*5^477336-1:
3.3.6: zero-padded FFT length 128K
3.4.0: Core2 type-3 FFT length 128K

105782*5^478154-1:
3.3.6: zero-padded FFT length 128K
3.4.0: Core2 type-3 FFT length 128K[/code]
So this appears to be some kind of general slowdown with 3.4.0. This is rather surprising, since I'm running this on a Core 2 Duo (one of the architectures that would be expected to have a speedup).

I'm using the 32-bit Windows 3.4.0. If I'm understanding things correctly, 3.4.1 only made changes to the 64-bit version, so whatever's happening here probably affects 3.4.1 as well.

rogue 2010-09-28 17:38

[QUOTE=mdettweiler;231784]It doesn't look there were any FFT changes. Here's what each version used for pairs before and after the changeover in my above list:
[code]289184*5^477336-1:
3.3.6: zero-padded FFT length 128K
3.4.0: Core2 type-3 FFT length 128K

105782*5^478154-1:
3.3.6: zero-padded FFT length 128K
3.4.0: Core2 type-3 FFT length 128K[/code]
So this appears to be some kind of general slowdown with 3.4.0. This is rather surprising, since I'm running this on a Core 2 Duo (one of the architectures that would be expected to have a speedup).

I'm using the 32-bit Windows 3.4.0. If I'm understanding things correctly, 3.4.1 only made changes to the 64-bit version, so whatever's happening here probably affects 3.4.1 as well.[/QUOTE]

This is a question for George as PFGW does not select the FFT used by gwnum for the PRP Test.

You are correct on 3.4.1.

Prime95 2010-09-28 21:44

[QUOTE=mdettweiler;231784][code]
105782*5^478154-1:
3.3.6: zero-padded FFT length 128K
3.4.0: Core2 type-3 FFT length 128K[/code].[/QUOTE]

Using 32-bit Prime95 on my Core 2 Mac running Windows in VMware I get 2.75 ms for the old gwnum code and 2.25 ms/iter for the new gwnum code.

rogue 2010-09-29 02:32

I tested the second number with 3.3.6 and 3.4.0 (both 32 bit). 4713 and 4165 seconds respectively. You should probably test one of those numbers with both versions. There are other factors in gwnum that can affect timing.

mdettweiler 2010-09-29 04:59

[QUOTE=rogue;231841]I tested the second number with 3.3.6 and 3.4.0 (both 32 bit). 4713 and 4165 seconds respectively. You should probably test one of those numbers with both versions. There are other factors in gwnum that can affect timing.[/QUOTE]
Okay, here's what I got running the first number with both versions:
[code]
$ ./pfgw336.exe -q289184*5^477336-1
PFGW Version 3.3.6.20100908.Win_Stable [GWNUM 25.14]
289184*5^477336-1 is composite: RES64: [08B0E31C3A9EFF00] (3820.2773s+0.1489s)

$ ./pfgw.exe -q289184*5^477336-1
PFGW Version 3.4.0.32BIT.20100925.Win_Dev [GWNUM 26.2]
289184*5^477336-1 is composite: RES64: [08B0E31C3A9EFF00] (4416.4668s+0.0490s)
[/code]
Again, 3.4.0 is significantly slower. Very strange. :huh:

rogue 2010-09-29 14:29

PFGW Version 3.3.6.20100908.Win_Stable [GWNUM 25.14]
289184*5^477336-1 is composite: RES64: [08B0E31C3A9EFF00] (3526.7372s+0.0633s)

PFGW Version 3.4.1.32BIT.20100927.Win_Dev [GWNUM 26.2]
289184*5^477336-1 is composite: RES64: [08B0E31C3A9EFF00] (3428.3614s+0.3369s)

PFGW Version 3.4.1.64BIT.20100927.Win_Dev [GWNUM 26.2]
289184*5^477336-1 is composite: RES64: [08B0E31C3A9EFF00] (2683.5896s+0.0174s)

This is on a "Intel(R) Core(TM)2 Duo CPU P8700 @ 2.53GHz" according to the pfgw.ini file. What is the CpuBrand entry in your pfgw.ini file? This was on 64-bit Window 7.

My tests last night were on a MacIntel T7700 Core 2 Duo at 2.40 GHz. The MacIntel is about 4 years old and has slower memory.

mdettweiler 2010-09-29 18:39

[QUOTE=rogue;231916]PFGW Version 3.3.6.20100908.Win_Stable [GWNUM 25.14]
289184*5^477336-1 is composite: RES64: [08B0E31C3A9EFF00] (3526.7372s+0.0633s)

PFGW Version 3.4.1.32BIT.20100927.Win_Dev [GWNUM 26.2]
289184*5^477336-1 is composite: RES64: [08B0E31C3A9EFF00] (3428.3614s+0.3369s)

PFGW Version 3.4.1.64BIT.20100927.Win_Dev [GWNUM 26.2]
289184*5^477336-1 is composite: RES64: [08B0E31C3A9EFF00] (2683.5896s+0.0174s)

This is on a "Intel(R) Core(TM)2 Duo CPU P8700 @ 2.53GHz" according to the pfgw.ini file. What is the CpuBrand entry in your pfgw.ini file? This was on 64-bit Window 7.

My tests last night were on a MacIntel T7700 Core 2 Duo at 2.40 GHz. The MacIntel is about 4 years old and has slower memory.[/QUOTE]
The CPU is a Core 2 Duo E4500 (at stock speed of 2.2Ghz) and is identified by PFGW as:

"Intel(R) Core(TM)2 Duo CPU E4500 @ 2.20GHz"

The computer is running Windows XP Pro 32-bit.

mdettweiler 2010-09-29 21:06

I've also tried comparing iteration timings with Prime95 v26.2 vs. 25.11 (both Windows 32-bit) to verify whether the problem is in gwnum, or just PFGW.

In both cases, I used the Advanced>Time option, and ran 1000 iterations of M38000000.

25.11: ~60 ms/iter.
26.2: ~50 ms/iter.

So there's a significant speedup going to version 26.2. Of course, this is a much bigger FFT than that used on the base 5 numbers; so I also tried 1000 iterations of M1100000.

25.11: ~1.2 ms/iter.
26.2: ~1.5 ms/iter.

It seems that version 26.2 is actually slower on this FFT.

Note that Prime95 v26.2 used the Pentium 4 type-3 56K FFT for this number, whereas the base 5 numbers tested earlier were done with a Core2 type-3 128K FFT. However, there does seem to be a commonality in that in both cases, the v26 gwnum program tested slower on my CPU at these low FFTs.

Prime95 2010-09-29 21:47

[QUOTE=mdettweiler;231968]I've also tried comparing iteration timings with Prime95 v26.2 vs. 25.11 (both Windows 32-bit) to verify whether the problem is in gwnum, or just PFGW.[/QUOTE]

You can add "PRP=289184,5,477336,-1" to worktodo.txt to time the exact numbers in question.

It is baffling to me why these smaller FFTs are slower on your Core 2 but not for anyone else. Maybe CPU-Z or one of the other programs that do a more thorough dump of CPU characteristics might shed some light.

mdettweiler 2010-09-30 02:26

[QUOTE=Prime95;231975]You can add "PRP=289184,5,477336,-1" to worktodo.txt to time the exact numbers in question.

It is baffling to me why these smaller FFTs are slower on your Core 2 but not for anyone else. Maybe CPU-Z or one of the other programs that do a more thorough dump of CPU characteristics might shed some light.[/QUOTE]
Okay, here's the iteration timings I got for that with Prime95 v25.11 and 26.2:

25.11: ~3.55 ms/iter.
26.2: ~3.45 ms/iter.

Would you know--I get a speed boost with 26.2 after all. It would seem, then, that this is an issue in PFGW and not in gwnum.

rogue 2010-09-30 02:41

[QUOTE=mdettweiler;232001]Okay, here's the iteration timings I got for that with Prime95 v25.11 and 26.2:

25.11: ~3.55 ms/iter.
26.2: ~3.45 ms/iter.

Would you know--I get a speed boost with 26.2 after all. It would seem, then, that this is an issue in PFGW and not in gwnum.[/QUOTE]

Not necessarily. I've already shown the timings on Windows for the same build. Such a vast proportion of time is spent in gwnum that it is unlikely that PFGW could cause such a significant slow down. There is clearly something curious going on here though.

mdettweiler 2010-09-30 06:10

[QUOTE=rogue;232002]Not necessarily. I've already shown the timings on Windows for the same build. Such a vast proportion of time is spent in gwnum that it is unlikely that PFGW could cause such a significant slow down. There is clearly something curious going on here though.[/QUOTE]
Here's what I get comparing iteration times on 289184*5^477336-1 for LLR 3.8.1 and 3.8.2:

3.8.1: ~3.45 ms/iter.
3.8.2: ~3.40 ms/iter.

Just like Prime95, LLR gets a speed increase with 3.8.2 as expected.

What I really should do, though, is run the test from start to finish on each version of both Prime95 and LLR. We've already seen that in such a test PFGW 3.3.6 is inexplicably faster than 3.4.0, but it would be interesting to see if the same holds true for Prime95 and LLR. Sure, the ms/iter. figures show the newer version to be faster in both such cases, but in each case the figures fluctuated rather wildly and I had to come up with a "gut estimate average" to post here. The potential for experimental error is, needless to say, rather large.

George, quick question: is there a way to make Prime95 print the exact wall-clock runtime at the end of a test, like PFGW and LLR do? As it is now, there's not really an easy way to directly measure this with Prime95.

rogue 2010-09-30 12:39

[QUOTE=mdettweiler;232017]Here's what I get comparing iteration times on 289184*5^477336-1 for LLR 3.8.1 and 3.8.2:

3.8.1: ~3.45 ms/iter.
3.8.2: ~3.40 ms/iter.

Just like Prime95, LLR gets a speed increase with 3.8.2 as expected.

What I really should do, though, is run the test from start to finish on each version of both Prime95 and LLR. We've already seen that in such a test PFGW 3.3.6 is inexplicably faster than 3.4.0, but it would be interesting to see if the same holds true for Prime95 and LLR. Sure, the ms/iter. figures show the newer version to be faster in both such cases, but in each case the figures fluctuated rather wildly and I had to come up with a "gut estimate average" to post here. The potential for experimental error is, needless to say, rather large.

George, quick question: is there a way to make Prime95 print the exact wall-clock runtime at the end of a test, like PFGW and LLR do? As it is now, there's not really an easy way to directly measure this with Prime95.[/QUOTE]

I'm curious. Is 3.4.0 slower for other n and other bases?

Prime95 2010-09-30 14:28

[QUOTE=mdettweiler;232017]
George, quick question: is there a way to make Prime95 print the exact wall-clock runtime at the end of a test, like PFGW and LLR do? As it is now, there's not really an easy way to directly measure this with Prime95.[/QUOTE]

The date/time is displayed at the start of every line output to the screen.

mdettweiler 2010-09-30 14:58

[QUOTE=rogue;232047]I'm curious. Is 3.4.0 slower for other n and other bases?[/QUOTE]
For base 2, 3.4.0 is faster:
[code]
PFGW Version 3.3.6.20100908.Win_Stable [GWNUM 25.14]
2071*2^270307-1 is composite: RES64: [816B1DBFBFC67D09] (123.9523s+0.0004s)


PFGW Version 3.4.0.32BIT.20100925.Win_Dev [GWNUM 26.2]
2071*2^270307-1 is composite: RES64: [816B1DBFBFC67D09] (108.1168s+0.0003s)
[/code]
Ditto for base 3:
[code]
PFGW Version 3.3.6.20100908.Win_Stable [GWNUM 25.14]
170979002*3^50000+1 is composite: RES64: [CBA9FAA11257431A] (15.1078s+0.0014s)

PFGW Version 3.4.0.32BIT.20100925.Win_Dev [GWNUM 26.2]
170979002*3^50000+1 is composite: RES64: [CBA9FAA11257431A] (12.1903s+0.0017s)[/code]
And for another n on base 5, 3.4.0 is again faster:
[code]
PFGW Version 3.3.6.20100908.Win_Stable [GWNUM 25.14]
18656*5^65474-1 is composite: RES64: [BB2682E39AA9CB16] (42.5636s+0.0034s)

PFGW Version 3.4.0.32BIT.20100925.Win_Dev [GWNUM 26.2]
18656*5^65474-1 is composite: RES64: [BB2682E39AA9CB16] (37.9236s+0.0038s)[/code]
The problem, it would seem, is localized to this particular range of n on base 5 (possibly this particular FFT size).

Mark, did you by chance check which FFT 3.4.0 chose for the two (larger) base 5 tests on your CPU? Mine used "Core2 type-3 FFT length 128K"; maybe yours chose a different CPU architecture? (Grasping at straws here...)
[QUOTE=Prime95;232059]The date/time is displayed at the start of every line output to the screen.[/QUOTE]
But that only prints out at the [i]end[/i] of each test; what I'd need for it to do is to print the time at the beginning as well so I could subtract and get the runtime.

I suppose what I could do is stick a miniscule test (n=100 or so) in the worktodo.txt file right before the base 5 test. That way, it prints out the time at the tiny test's completion (i.e., at the start of the base 5 test) and again at the end of the base 5 test. I'll try that later today.

rogue 2010-09-30 15:15

This is what 3.4.0 chose on Win64:

Special modular reduction using zero-padded Core2 type-3 FFT length 128K, Pass1=128, Pass2=1K on 289184*5^477336-1

mdettweiler 2010-09-30 15:27

[QUOTE=rogue;232065]This is what 3.4.0 chose on Win64:

Special modular reduction using zero-padded Core2 type-3 FFT length 128K, Pass1=128, Pass2=1K on 289184*5^477336-1[/QUOTE]
That's the same as what I got:

Special modular reduction using zero-padded Core2 type-3 FFT length 128K, Pass1=128, Pass2=1K on 289184*5^477336-1

Does the 32-bit version by chance give you something different?

rogue 2010-09-30 15:45

[QUOTE=mdettweiler;232068]That's the same as what I got:

Special modular reduction using zero-padded Core2 type-3 FFT length 128K, Pass1=128, Pass2=1K on 289184*5^477336-1

Does the 32-bit version by chance give you something different?[/QUOTE]

Nope.

rogue 2010-10-01 02:02

I have re-released the OS X build of PFGW 3.4.0. Apparently the 32-bit version has problems with the static-linked GMP and the 64-bit version wasn't working correctly. I suspect a linker bug in the one case and a compiler bug in the other as the other. For the 64-bit version I didn't use any optimizations with PFGW itself (gwnum and GMP are still optimized) and it is appears to be faster.

I'm very close to having a 64-bit linux build posted. Hopefully tomorrow.

mdettweiler 2010-10-01 04:45

Okay, I've tried testing 289184*5^477336-1 with both LLR 3.8.1 and 3.8.2 to see if the mysterious slowdown exists in LLR as well.
[code]
$ ./cllr381.exe -d -q289184*5^477336-1
Base prime factor(s) taken : 5
Starting N+1 prime test of 289184*5^477336-1
Using zero-padded FFT length 128K, a = 3

289184*5^477336-1 is not prime. RES64: 08B0E31C3A9EFF00. OLD64: 077A0603FB8C61BF Time : 3958.254 sec.

$ ./cllr.exe -d -q289184*5^477336-1
Base prime factor(s) taken : 5
Starting N+1 prime test of 289184*5^477336-1
Using zero-padded Core2 type-3 FFT length 128K, Pass1=128, Pass2=1K, a = 3

289184*5^477336-1 is not prime. RES64: 08B0E31C3A9EFF00. OLD64: 077A0603FB8C61BF Time : 3858.415 sec.
[/code]
Oddly enough, LLR did turn out to be faster by a significant amount. (That'll teach me to use 20 seconds' worth of ms/iter. figures as data points. :rolleyes:)

Next, I'll repeat the test with Prime95 25.11 and 26.2 to see whether it has a slowdown or not.

rogue 2010-10-01 12:42

A 64-bit Linux build is finally available thanks to Steven Harvey. You can d/l the latest releases from [URL="http://sourceforge.net/projects/openpfgw/"]here[/URL].

paulunderwood 2010-10-11 23:58

I get an error with Debian running pfgw64 testing 100000000000*2731#+1 :smile:

[CODE]-----------------------------------------------------------------------
Error occuring in PFGW at Tue Oct 12 00:56:51 2010
Expr = 100000000000*2731#+1
Detected in gw_test_illegal_sumout() in prp_using_gwnum
Iteration: 1/3911 ERROR: ILLEGAL SUMOUT
PFGW will automatically rerun the test with -a1
-----------------------------------------------------------------------
Error occuring in PFGW at Tue Oct 12 00:56:51 2010
Expr = 100000000000*2731#+1
Detected in gw_test_illegal_sumout() in prp_using_gwnum
Iteration: 1/3911 ERROR: ILLEGAL SUMOUT
PFGW will automatically rerun the test with -a2
-----------------------------------------------------------------------
Error occuring in PFGW at Tue Oct 12 00:56:51 2010
Expr = 100000000000*2731#+1
Detected in gw_test_illegal_sumout() in prp_using_gwnum
Iteration: 1/3911 ERROR: ILLEGAL SUMOUT
PFGW will automatically rerun the test with -a3
-----------------------------------------------------------------------
Error occuring in PFGW at Tue Oct 12 00:56:51 2010
Expr = 100000000000*2731#+1
Detected in gw_test_illegal_sumout() in prp_using_gwnum
Iteration: 1/3911 ERROR: ILLEGAL SUMOUT
PFGW will automatically rerun the test with -a4
-----------------------------------------------------------------------
Error occuring in PFGW at Tue Oct 12 00:56:51 2010
Expr = 100000000000*2731#+1
Detected in gw_test_illegal_sumout() in prp_using_gwnum
Iteration: 1/3911 ERROR: ILLEGAL SUMOUT
PFGW will automatically rerun the test with -a5
-----------------------------------------------------------------------
Error occuring in PFGW at Tue Oct 12 00:56:51 2010
Expr = 100000000000*2731#+1
Detected in gw_test_illegal_sumout() in prp_using_gwnum
Iteration: 1/3911 ERROR: ILLEGAL SUMOUT
PFGW will automatically rerun the test with -a6[/CODE]

pfgw32 is okay on the same 64 bit Debian box

rogue 2010-10-12 02:23

[QUOTE=paulunderwood;233184]I get an error with Debian running pfgw64 testing 100000000000*2731#+1 :smile:

pfgw32 is okay on the same 64 bit Debian box[/QUOTE]

George is aware of the problem (linux 64-bit only) and has a fix. I'll be building a new release with gwnum v26.3 in the next week.

henryzz 2010-10-16 17:12

I started running some base 3 work and got this:[CODE]PFGW Version 3.4.1.64BIT.20100927.Win_Dev [GWNUM 26.2]

Factoring numbers to 100% of normal.

Script File
trial factoring to 49598
820000000*3^1-1 factors prime!: 2459999999
Primality testing 820000002-1 [N-1/N+1, Brillhart-Lehmer-Selfridge]
small number, factored
820000002-1 is factored (0.0005s+0.0085s)
trial factoring to 49598
820000004*3^1-1 has factors: 7
trial factoring to 65536
820000004*3^2-1 has factors: 5
trial factoring to 65536
Switching to Exponentiating using GMP
820000004*3^3-1 is 3-PRP! (0.0001s+0.0053s)
Primality testing 820000004*3^3-1 [N+1, Brillhart-Lehmer-Selfridge]
trial factoring to 65536
Running N+1 test using discriminant 5, base 1+sqrt(5)
Error 1002 initializing FFT code:[/CODE]
The 32 bit binary works fine.

rogue 2010-10-18 00:10

[QUOTE=henryzz;233554]I started running some base 3 work and got this:[CODE]PFGW Version 3.4.1.64BIT.20100927.Win_Dev [GWNUM 26.2]

Factoring numbers to 100% of normal.

Script File
trial factoring to 49598
820000000*3^1-1 factors prime!: 2459999999
Primality testing 820000002-1 [N-1/N+1, Brillhart-Lehmer-Selfridge]
small number, factored
820000002-1 is factored (0.0005s+0.0085s)
trial factoring to 49598
820000004*3^1-1 has factors: 7
trial factoring to 65536
820000004*3^2-1 has factors: 5
trial factoring to 65536
Switching to Exponentiating using GMP
820000004*3^3-1 is 3-PRP! (0.0001s+0.0053s)
Primality testing 820000004*3^3-1 [N+1, Brillhart-Lehmer-Selfridge]
trial factoring to 65536
Running N+1 test using discriminant 5, base 1+sqrt(5)
Error 1002 initializing FFT code:[/CODE]
The 32 bit binary works fine.[/QUOTE]

I'll see if that is fixed wit gwnum v26.3.

rogue 2010-10-18 13:15

[QUOTE=rogue;233654]I'll see if that is fixed wit gwnum v26.3.[/QUOTE]

Works with the latest gwnum.

mdettweiler 2010-10-19 05:15

I just upgraded my quad to PFGW 3.4.0 (32-bit) and am pleased to say that I got a very nice 25% (!) speed boost over 3.3.6! Tests that took about 1630 seconds on 3.3.6 are now taking 1230 seconds. This is on base 6, near n=350K; I also get a speedup of similar magnitude with LLR 3.8.2 (vs. 3.8.0) on base 2 numbers around n=920K. It would seem that this CPU (Intel Q6600) benefits particularly well from the improvements in gwnum v26.

BTW @Mark and George: my apologies for not getting back to you sooner regarding my testing Prime95 on my dualcore to see if the mysterious base 5 slowdown occurs in there as well. As detailed in tests that I've already posted earlier in this thread, the slowdown going from gwnum v25>26 occurred in PFGW but not LLR; I'll try Prime95 as soon as I get the chance.

rogue 2010-10-21 02:39

PFGW 3.4.2 Released
 
You can d/l the latest release for Windows, MacIntel, and Linux from here: [url]http://sourceforge.net/projects/openpfgw/[/url]

The changes include:
[list][*]Updated to gwnum v26.4 to fix various issues, including one on 64-bit Linux and one with 64-bit builds on zero-padded two pass rational FFTs.[*]Addressed many compiler warnings when building with gcc.[*]Added carriage return after "GFN testing completed" message in pfgw.log.[*]Remove ability to change CPU setting via pfgw.ini. gwnum should be smarter than any user when specifying the CPU settings. This also addresses a crash that occurs on MacIntel during primality proofs as the SSE2 flag was turned off which told gwnum to execute non-SSE2 code, which isn't built into gwnum on MacIntel (Apple only supports Core 2 and later CPUs on MacIntel).[/list]

paulunderwood 2010-10-21 11:18

:tu:

Would it be possible to have "static" versions to overcome some problems? Please see: [url]http://tech.groups.yahoo.com/group/primeform/message/10725[/url]

mdettweiler 2010-10-21 21:37

At last, the results are in for the comparison of Prime95 v25.11 vs. v26.3 for 289184*5^477336-1 on my Core 2 Duo. We have:

v25.11 started at [Thu Oct 21 14:29:35 2010], finished at [Thu Oct 21 15:30:55 2010] --> total 1:01:20 = 3680 sec.

v26.3 started at [Thu Oct 21 15:53:16 2010], finished at [Thu Oct 21 16:38:05 2010] --> total 0:44:49 = 2689 sec.

So it would seem that PFGW 3.4.0 (32-bit, as all of these were) is the only one of the triumvirate that exhibits a slowdown going to gwnum v26. Note, however, that the individual gwnum minor versions of the programs used for these tests do not all line up; I tested PFGW 3.3.6 vs. 3.4.0 (gwnum 26.2), LLR 3.8.1 vs. 3.8.2 (gwnum 26.2), and Prime95 25.11 vs. 26.3 (gwnum 26.3). For that reason, I will follow this up shortly with a rerun of 289184*5^477336-1 using PFGW 3.4.2. Stay tuned...

mdettweiler 2010-10-21 21:50

Holy cow! It would seem that 3.4.2 actually chooses an entirely different FFT size for 289184*5^477336-1 than 3.4.1 (which I understand is the same as 3.4.0 on 32-bit--I deleted my copy of 3.4.0, stupid me, and could only get my hands on 3.4.1). Behold:
[code]
$ ./pfgw341.exe -F -q289184*5^477336-1
PFGW Version 3.4.1.32BIT.20100927.Win_Dev [GWNUM 26.2]
Special modular reduction using zero-padded Core2 type-3 FFT length 128K, Pass1=128, Pass2=1K on 289184*5^477336-1
Special modular reduction using zero-padded Pentium4 type-1 FFT length 144K, Pass1=96, Pass2=1536 on 289184*5^477336-1
Special modular reduction using zero-padded Pentium4 type-3 FFT length 160K, Pass1=640, Pass2=256 on 289184*5^477336-1
Special modular reduction using zero-padded Pentium4 type-3 FFT length 192K, Pass1=256, Pass2=768 on 289184*5^477336-1
Special modular reduction using zero-padded Pentium4 type-3 FFT length 224K, Pass1=896, Pass2=256 on 289184*5^477336-1
Special modular reduction using zero-padded Pentium4 type-3 FFT length 240K, Pass1=320, Pass2=768 on 289184*5^477336-1

$ ./pfgw.exe -F -q289184*5^477336-1
PFGW Version 3.4.2.32BIT.20101019.Win_Dev [GWNUM 26.4]
Special modular reduction using Core2 type-3 FFT length 112K, Pass1=448, Pass2=256 on 289184*5^477336-1
[/code]
Not only is the size used different (112K vs. 128K), 3.4.2 omits the "zero-padded" nomenclature entirely. Whether this is just an output difference or a difference in the underlying logic I do not know.

This would seem to invalidate 3.4.2 for use in trying to nail down this mystery. However, at this point it would seem rather unnecessary, as whatever happened, it has apparently been fixed in 3.4.2. :huh: Thus, I'll just stick with 3.4.2 for all my testing as it seems to now be consistent with the speedups I get from comparable LLR and Prime95 versions.

Thanks for taking the time to look into this (and for whatever you guys did to fix it)! :smile:

rogue 2010-10-22 00:07

I didn't do anything, but George might have. I find it interesting that the old version specified Pentium4 and the new one specified Core 2.

mdettweiler 2010-10-22 01:08

[QUOTE=rogue;234128]I didn't do anything, but George might have. I find it interesting that the old version specified Pentium4 and the new one specified Core 2.[/QUOTE]
Well, it gave 6 different potential FFT choices (1 Core 2, 5 P4) when I ran it with -F, but when I run the actual test with -V it uses the Core2 FFT.

BTW: why exactly would it give 6 FFT choices like that? Shouldn't it boil down to exactly one choice just like it would for the real test? (Or might this, whatever the cause, be the reason for the strange slowdown?)

rogue 2010-10-22 01:17

[QUOTE=mdettweiler;234130]Well, it gave 6 different potential FFT choices (1 Core 2, 5 P4) when I ran it with -F, but when I run the actual test with -V it uses the Core2 FFT.

BTW: why exactly would it give 6 FFT choices like that? Shouldn't it boil down to exactly one choice just like it would for the real test? (Or might this, whatever the cause, be the reason for the strange slowdown?)[/QUOTE]

That it listed 6 was a bug that I fixed in 3.4.1. Only the first one would be used under normal conditions.

rogue 2010-10-25 21:01

PFGW 3.4.3 Released
 
You can d/l the latest release for Windows, MacIntel, and Linux from here: [url]http://sourceforge.net/projects/openpfgw/[/url]

The updates are for 64-bit PFGW users. A bug was found and fixed in the factoring code. For linux, the binary is now statically linked.

Prime95 2010-10-25 22:31

[QUOTE=mdettweiler;234119]Holy cow! It would seem that 3.4.2 actually chooses an entirely different FFT size for 289184*5^477336-1 than 3.4.1
...
Not only is the size used different (112K vs. 128K), 3.4.2 omits the "zero-padded" nomenclature entirely. Whether this is just an output difference or a difference in the underlying logic I do not know.[/QUOTE]

For those that like gory details, gwnum 26.4 can now propagate carries to the next 6 FFT data words whereas 26.3 can only propagate to the next 4 FFT data words. Usually this makes no difference in FFT selection. But for larger k values, 26.4 may use the slightly faster irrational base discrete weighted FFT (Richard Crandall's IBDWT) vs. a zero-padded FFT of the same size. In even rarer cases, 26.4 may use an IBDWT with a smaller FFT length.

Batalov 2010-11-01 04:25

[QUOTE=rogue;234367]You can d/l the latest release for Windows, MacIntel, and Linux from here: [URL]http://sourceforge.net/projects/openpfgw/[/URL]

The updates are for 64-bit PFGW users. A bug was found and fixed in the factoring code. For linux, the binary is now statically linked.[/QUOTE]
I have a small bug. Run pfgw64 (linux), kill it somewhere; then replace the input file (with something else), restart and it reports:

[FONT=Arial Narrow]***WARNING! file sr_10.pfgw line 2378 does not match what is expected.[/FONT]
[FONT=Arial Narrow]Expecting: 10001001*10^11441+1[/FONT]
[FONT=Arial Narrow]File contained: 1001001*10^25534+1[/FONT]
[FONT=Arial Narrow]Starting over at the beginning of the file[/FONT]
[FONT=Arial Narrow][/FONT]
[FONT=Arial Narrow]10001001*10^25535+1 is composite: RES64: [AD505C1D89295440] (24.7044s+0.0002s)[/FONT]
[FONT=Arial Narrow]...[/FONT]

Starting over at the beginning of the file, of course, is the usual and in this case desired effect. But it doesn't, it only says that it will, and instead goes from the middle of the file (i.e. the line is not zeroed). This seems to be new (something unitialized in 64-bit version?), -- it worked fine before.

rogue 2010-11-01 14:56

[QUOTE=Batalov;235156]I have a small bug. Run pfgw64 (linux), kill it somewhere; then replace the input file (with something else), restart and it reports:

[FONT=Arial Narrow]***WARNING! file sr_10.pfgw line 2378 does not match what is expected.[/FONT]
[FONT=Arial Narrow]Expecting: 10001001*10^11441+1[/FONT]
[FONT=Arial Narrow]File contained: 1001001*10^25534+1[/FONT]
[FONT=Arial Narrow]Starting over at the beginning of the file[/FONT]
[FONT=Arial Narrow][/FONT]
[FONT=Arial Narrow]10001001*10^25535+1 is composite: RES64: [AD505C1D89295440] (24.7044s+0.0002s)[/FONT]
[FONT=Arial Narrow]...[/FONT]

Starting over at the beginning of the file, of course, is the usual and in this case desired effect. But it doesn't, it only says that it will, and instead goes from the middle of the file (i.e. the line is not zeroed). This seems to be new (something unitialized in 64-bit version?), -- it worked fine before.[/QUOTE]

This was something I broke when trying to address a crash with ABC2 files. I'll have to look into another fix for that problem.

rogue 2010-11-04 21:39

PFGW 3.4.4 Released
 
You can d/l the latest release for Windows, MacIntel, and Linux from here: [url]http://sourceforge.net/projects/openpfgw/[/url]

This fixes a factoring problem on Win64 and fixes the ABC resume problem. I believe that there is still an ABC2 crashing problem, but I can't recall how to produce it. I had to revert that change to correct the ABC resume problem.

Batalov 2010-11-26 08:38

Konyagin-Pomerance extension
 
In PFGW, the N-1 Brillhart-Lehmer-Selfridge implements eponymous 1975 algorithm, but would it be hard to extend it with the third-magnitude stage Konyagin-Pomerance extension (as in pages 176-178 of Crandall/Pomerance PN-ACP, Theorem 4.1.6)? Part (1) seems no different from the square test of the second-magnitude stage, and the same code would be called six times with minor variations, but part (2) needs a bit of implementation. There's a GP prototype [URL="http://tech.groups.yahoo.com/group/primeform/files/KP/KonPom.gp"]available[/URL], needs a polroots() for a cubic poly and contfrac() rewritten.

Was this ever requested before? Could I possibly help? (with a disclaimer that familiarizing with the code could take much more time than "just doing it" for an experienced developer, i.e. Mark :rolleyes:)

rogue 2010-11-26 14:10

[QUOTE=Batalov;238699]Was this ever requested before? Could I possibly help? (with a disclaimer that familiarizing with the code could take much more time than "just doing it" for an experienced developer, i.e. Mark :rolleyes:)[/QUOTE]

No. Yes.

You are welcome to try. You can d/l the source (via svn) for free, but I would need to authorize you to make any updates.

Unfortunately any changes to the primality proving side as easier said than done. If you start digging into the code, you will understand what I mean. PFGW often takes a rather circuitous route to get between points A and B and it does it using a design pattern that I am not familiar with.

Batalov 2010-11-26 20:11

I'll try to grok it. It could "take the term of my natural life" though. :-)

rogue 2010-11-27 00:12

There has been a request on one of the Yahoo groups (the openpfgw group, IIRC) to introduce some simple P-1/P+1/Rho factoring into PFGW. If you are interested in contributing to PFGW, that would be a more useful place to apply any programming time.

Outside of that I have two strong desires for PFGW's future. The first is to re-design the code to use more common design patterns. That would ultimately make it easier to make enhancements to PFGW, enhancements that include newer/faster primality tests. The second is to rewrite the U/I using something like gtk. This would help me to eliminate the requirements to use Visual Studio to build the software and it would allow me to provide a U/I to non-Windows users.

A weak desire is to make it easier to replace gwnum with another FFT. The only reason for that is to port PFGW to other CPUs (such as CUDA). The problem is that I would need to write a number of APIs for those FFT libraries because PFGW would need them. Writing those APIs is not trivial.

Shaopu Lin 2011-01-19 16:35

There is a bug in pfgw 3.4.4
 
1 Attachment(s)
When pfgw 3.4.4. read a NewPGen format sieveing file on OpenSUSE 11.3, it crashed.
[code]math@linux-39b2:~/桌面/other/test> pfgw -t 10000.txt
PFGW Version 3.4.4.64BIT.20101104.x86_Dev [GWNUM 26.4]

NewPGen file: k*2^10000+1

***WARNING! file 10000.txt may have already been fully processed.

Primality testing 127*2^10000+1 [N-1, Brillhart-Lehmer-Selfridge]

Signal SIGILL caught
math@linux-39b2:~/桌面/other/test> [/code]

rogue 2011-01-19 17:44

[QUOTE=Shaopu Lin;247440]When pfgw 3.4.4. read a NewPGen format sieveing file on OpenSUSE 11.3, it crashed.
[code]math@linux-39b2:~/桌面/other/test> pfgw -t 10000.txt
PFGW Version 3.4.4.64BIT.20101104.x86_Dev [GWNUM 26.4]

NewPGen file: k*2^10000+1

***WARNING! file 10000.txt may have already been fully processed.

Primality testing 127*2^10000+1 [N-1, Brillhart-Lehmer-Selfridge]

Signal SIGILL caught
math@linux-39b2:~/桌面/other/test> [/code][/QUOTE]

It works on Windows. I'll try it on a *nix system tonight.

Harvey563 2011-01-20 03:29

my results
 
on an Atom running ubuntu 10.4, I get

steven@steven-eee:~/op342/test$ ./pfgw 10000-1.txt -l10000-1out.txt
PFGW Version 3.4.4.32BIT.20101104.x86_Dev [GWNUM 26.4]

Output logging to file 10000-1out.txt
NewPGen file: k*2^10000+1
127*2^10000+1 is composite: RES64: [F831E49FDA74FDB3] (1.3944s+0.0003s)
141*2^10000+1 is composite: RES64: [E5CDBE3B23D2E417] (1.2715s+0.0009s)
217*2^10000+1 is composite: RES64: [0187EDB548EA035D] (1.2599s+0.0007s)
265*2^10000+1 is composite: RES64: [E0784ADBE50718C7] (1.2446s+0.0004s)
343*2^10000+1 is composite: RES64: [B53BF83C47E20882] (1.2591s+0.0006s)
375*2^10000+1 is composite: RES64: [84F83BC014FEE987] (1.2593s+0.0004s)
393*2^10000+1 is composite: RES64: [534BC93F2FB9239B] (1.2550s+0.0004s)
477*2^10000+1 is composite: RES64: [6A1A303314623288] (1.2476s+0.0007s)
541*2^10000+1 is composite: RES64: [85336ADE71F31EDA] (1.3223s+0.0006s)
^C
Ctrl-C detected, shutting down the program.
steven@steven-eee:~/op342/test$ ./pfgw 10000-1.txt -l10000-1out.txt -V
PFGW Version 3.4.4.32BIT.20101104.x86_Dev [GWNUM 26.4]

Output logging to file 10000-1out.txt
NewPGen file: k*2^10000+1
Special modular reduction using all-complex FFT length 768 on 127*2^10000+1
127*2^10000+1 is composite: RES64: [F831E49FDA74FDB3] (1.3388s+0.0003s)
Special modular reduction using all-complex FFT length 768 on 141*2^10000+1
141*2^10000+1 is composite: RES64: [E5CDBE3B23D2E417] (1.3815s+0.0004s)
Special modular reduction using all-complex FFT length 768 on 217*2^10000+1
217*2^10000+1 is composite: RES64: [0187EDB548EA035D] (1.2886s+0.0005s)
Special modular reduction using all-complex FFT length 768 on 265*2^10000+1
265*2^10000+1 is composite: RES64: [E0784ADBE50718C7] (1.2683s+0.0007s)
Special modular reduction using all-complex FFT length 768 on 343*2^10000+1
343*2^10000+1 is composite: RES64: [B53BF83C47E20882] (1.2694s+0.0006s)
Special modular reduction using all-complex FFT length 768 on 375*2^10000+1
375*2^10000+1 is composite: RES64: [84F83BC014FEE987] (1.2608s+0.0007s)
Special modular reduction using all-complex FFT length 768 on 393*2^10000+1
393*2^10000+1 is composite: RES64: [534BC93F2FB9239B] (1.2940s+0.0004s)
Special modular reduction using all-complex FFT length 768 on 477*2^10000+1
477*2^10000+1 is composite: RES64: [6A1A303314623288] (1.3039s+0.0004s)
Special modular reduction using all-complex FFT length 768 on 541*2^10000+1
541*2^10000+1 is composite: RES64: [85336ADE71F31EDA] (1.2566s+0.0007s)
Special modular reduction using all-complex FFT length 768 on 583*2^10000+1
583*2^10000+1 is composite: RES64: [2852A86B4389567E] (1.2928s+0.0004s)
Special modular reduction using all-complex FFT length 768 on 607*2^10000+1
607*2^10000+1 is composite: RES64: [A95AE0579513952F] (1.3135s+0.0004s)
Special modular reduction using all-complex FFT length 768 on 613*2^10000+1
613*2^10000+1 is composite: RES64: [69102F36CB862BD1] (1.2713s+0.0004s)
Special modular reduction using all-complex FFT length 768 on 715*2^10000+1
^CP: 715*2^10000+1 1/10009
Ctrl-C detected, shutting down the program.
steven@steven-eee:~/op342/test$ ^C
steven@steven-eee:~/op342/test$ ./pfgw -t 10000-1.txt -l10000-1out.txt -V
PFGW Version 3.4.4.32BIT.20101104.x86_Dev [GWNUM 26.4]

Output logging to file 10000-1out.txt
NewPGen file: k*2^10000+1
Resuming input file 10000-1.txt at line 14

Primality testing 715*2^10000+1 [N-1, Brillhart-Lehmer-Selfridge]
Running N-1 test using base 3
Special modular reduction using all-complex FFT length 768 on 715*2^10000+1
715*2^10000+1 is composite (1.4255s+0.0003s)
Primality testing 721*2^10000+1 [N-1, Brillhart-Lehmer-Selfridge]
Running N-1 test using base 3
Special modular reduction using all-complex FFT length 768 on 721*2^10000+1
721*2^10000+1 is composite (1.3449s+0.0004s)
Primality testing 733*2^10000+1 [N-1, Brillhart-Lehmer-Selfridge]
Running N-1 test using base 3
Special modular reduction using all-complex FFT length 768 on 733*2^10000+1
733*2^10000+1 is composite (1.3633s+0.0007s)
Primality testing 753*2^10000+1 [N-1, Brillhart-Lehmer-Selfridge]
Running N-1 test using base 11
Special modular reduction using all-complex FFT length 768 on 753*2^10000+1
^C1: 753*2^10000+1 2500/10011 mro=0.0009765625
Ctrl-C detected, shutting down the program.
steven@steven-eee:~/op342/test$


So I opine, it's not a bug.

Harvey563 2011-01-20 03:45

64bit
 
After I posted the previous, I realized that the "bug" was in the 64 bit version.

Here's my 64 bit result.

steven@steven-eee:~$ telnet XXXXXXXXX
Trying 24.121.XXX.44...
Connected to harvey563.xxx.xxx.
Escape character is '^]'.
Ubuntu 10.04.1 LTS

steven-desktop login: steven
Password:
Last login: Mon Dec 27 12:13:43 MST 2010 from XXXXXXXXX
Linux steven-desktop 2.6.32-27-generic #49-Ubuntu SMP Thu Dec 2 00:51:09 UTC 2010 x86_64 GNU/Linux
Ubuntu 10.04.1 LTS

steven@steven-desktop:~/op342/test$ ./spfgw -t -q"127*2^100000+1"
PFGW Version 3.4.4.64BIT.20101104.x86_Dev [GWNUM 26.4]

Primality testing 127*2^100000+1 [N-1, Brillhart-Lehmer-Selfridge]
Running N-1 test using base 3
127*2^100000+1 is composite (14.0850s+0.0001s)

steven@steven-desktop:~/op342/test$ ./spfgw -t -q"127*2^100000+1" -V
PFGW Version 3.4.4.64BIT.20101104.x86_Dev [GWNUM 26.4]

Primality testing 127*2^100000+1 [N-1, Brillhart-Lehmer-Selfridge]
Running N-1 test using base 3
Special modular reduction using all-complex FFT length 6K on 127*2^100000+1
127*2^100000+1 is composite (13.6814s+0.0001s)

QED

rogue 2011-02-15 23:20

PFGW 3.4.5 has been released
 
I have finished up changes for PFGW 3.4.5. Here is a list of changes:

1) Updated to gwnum v26.5
2) Fixed memory leaks in 64-bit builds
3) Fixed other known memory leaks
4) Fixed assertion failure in Win64 builds
5) Fix ^C on *nix so that it writes a checkpoint before shutting down.
6) Disallow use of "pfgw.log" and "pfgw.ini" as input files.

I'm not certain that all of the versions (Windows, MacIntel, and Linux) uploaded correctly, so if you run into a problem, please let me know. You can get the latest version from [URL="http://sourceforge.net/projects/openpfgw/"]here[/URL].

--Mark

Syd 2011-02-16 10:23

There seems to be a problem in the linux-64bit version when using the -e switch.

#./pfgw64 -t -s0 -e100000 -q"(10^18533-7)/3"
PFGW Version 3.4.5.64BIT.20110215.x86_Dev [GWNUM 26.5]

Primality testing (10^18533-7)/3 [N-1, Brillhart-Lehmer-Selfridge]

Signal SIGILL caught

The 32bit-version works fine, same if I leave out -e100000.

rogue 2011-02-16 13:57

[QUOTE=Syd;252665]There seems to be a problem in the linux-64bit version when using the -e switch.

#./pfgw64 -t -s0 -e100000 -q"(10^18533-7)/3"
PFGW Version 3.4.5.64BIT.20110215.x86_Dev [GWNUM 26.5]

Primality testing (10^18533-7)/3 [N-1, Brillhart-Lehmer-Selfridge]

Signal SIGILL caught

The 32bit-version works fine, same if I leave out -e100000.[/QUOTE]

This is specific to Linux. I suspect that Steven built GMP specific to a CPU, such as a Core 2 rather than for a generic x86 architecture.

rogue 2011-03-08 13:36

PFGW 3.4.6 Released
 
I have finished up changes for PFGW 3.4.6. Here is a list of changes:

[code]
1) Use gwnum for POWMOD script function when numbers are larger than 650 bits.
2) Added -C switch to give better control over output for the console version.
-C takes a single argument:
quiet - the least amount of output, only gives status updates
normal - output status updates and newlines after PRPs and primes (default)
GFFactors - output factors when using -g switch
verbose - output result of all tests and output factors found
The default behavior of the console version is -Cnormal, which is same as the
default behavior of WinPFGW. Use -Cverbose to get the previous behavior of the
console version.
3) Due to addition of -C switch, pfgw will now output test results for all lines
from simple input files with two exceptions. It will not override -Cverbose
and it will not output factors.
[/code]

You can get the latest version from [URL="http://sourceforge.net/projects/openpfgw/"]here[/URL].

--Mark

rogue 2011-03-11 01:07

[QUOTE=Syd;252665]There seems to be a problem in the linux-64bit version when using the -e switch.

#./pfgw64 -t -s0 -e100000 -q"(10^18533-7)/3"
PFGW Version 3.4.5.64BIT.20110215.x86_Dev [GWNUM 26.5]

Primality testing (10^18533-7)/3 [N-1, Brillhart-Lehmer-Selfridge]

Signal SIGILL caught

The 32bit-version works fine, same if I leave out -e100000.[/QUOTE]

I have successfully rebuilt the Linux 64-bit PFGW with a "generic x86" version of GMP. This problem (and a related one discovered by Puzzle-Peter) appears to be gone. I hope to release the Linux version soon.

rogue 2011-03-13 03:12

With Steven Harvey's help, the new build of PFGW 3.4.5 for Linux is available from sourceforge. This fixes the SIGILL issues that I am aware of.

rogue 2011-06-19 21:05

PFGW 3.4.8 released
 
I have released PFGW 3.4.8. Here is a list of changes from 3.4.6:

[code]
1) Upgraded to gwnum v26.6.
2) Fixed bug when using SET in script files. It was tokening incorrectly.
3) Try generic modular reduction if setup for special modular reduction fails.
[/code]

You can get the latest version from [URL="http://sourceforge.net/projects/openpfgw/"]here[/URL].

--Mark

Xentar 2011-06-20 19:56

[QUOTE=rogue;264186][code]
1) Upgraded to gwnum v26.6.
[/code][/QUOTE]
Anyone knows, how much faster this version is? Thanks.

rogue 2011-06-20 20:28

[QUOTE=Xentar;264245]Anyone knows, how much faster this version is? Thanks.[/QUOTE]

I believe that it supports additional FFT sizes for some architectures, plus a few bug fixes.

Prime95 2011-06-21 00:34

[QUOTE=Xentar;264245]Anyone knows, how much faster this version is?[/QUOTE]

No faster. Some bug fixes -- especially for little used architectures.

rogue 2011-07-01 00:59

PFGW 3.4.9 Released
 
The only fix is to address a bug when using POWMOD in scripts.

You can get the latest version from [URL="http://sourceforge.net/projects/openpfgw/"]here[/URL].

--Mark

Xentar 2011-07-22 18:35

Small bug in Win64PFGW.exe, version 3.4.9:
When I try to use an input file pfgw.log, the application just closes without any error message.
When I use the command line software, I get the correct error message that this file name is not allowed.

rogue 2011-09-22 22:15

PFGW 3.5.0 is released
 
Here is a list of changes:
[list][*]Added a NEXTPRIME() function for scripts. It will return the next prime after the given argument. This is guaranteed to return all primes below 2^64.[*]Replaced primegen siever with my own. The primegen code misses some primes (notable primes that end with the digits "99999"). It was also limited to 32 bits. The new sieve can go up to 64 bits, but starts with a limit of 4e9. It will auto-increment the upper limit by 100 until it reaches 2^64. Outside of the small cost the occurs when the limit is auto-bumped, there is no longer a penalty for trial factoring above 2^31.[*]Upped the limit for trivial factoring to 40 bits, i.e. input values 40 bits in size or less will be trivially factored. This will reduce the number of "composite" PRPs, numbers with are output as PRP by pfgw, but which actually have small factors. This typically affects small base 3 numbers.[*]Note that some of these changes will have an impact on 32-bit machines, but the impact should be fairly small.[*]With these changes, the pfglue an prmsieve are obsolete.[*]Fixed a crash that was introduced into the GUI version in 3.4.10.[/list]You can d/l from [url]https://sourceforge.net/projects/openpfgw/[/url].

rogue 2011-09-23 11:33

Apparently I broke the factorial function in 3.5.0. I'll try to fix it ASAP.

rogue 2011-09-23 13:19

PFGW 3.5.1 is released
 
I fixed a few bugs from 3.5.0 (ones that I introduced):
[list][*]Fixed a bug in trivial factoring as primeserver would return 3 when calling the new ByIndex() function with a 1.[*]Fixed a bug with using ABC files and primorials as primeserver didn't re-initialize after processing the first line.[*]Fixed a bug with the p() and nextprime() functions when used in scripts.[/list]
I strongly recommend that you get 3.5.1 (which is still a beta BTW) in case you are trying to use 3.5.0.

Right now only the Windows build is available. I hope to get the Mac and Linux ones up later today.

Mini-Geek 2011-09-25 18:21

[QUOTE=rogue;272510]I fixed a few bugs from 3.5.0 (ones that I introduced):
[list][*]Fixed a bug in trivial factoring as primeserver would return 3 when calling the new ByIndex() function with a 1.[*]Fixed a bug with using ABC files and primorials as primeserver didn't re-initialize after processing the first line.[*]Fixed a bug with the p() and nextprime() functions when used in scripts.[/list]
I strongly recommend that you get 3.5.1 (which is still a beta BTW) in case you are trying to use 3.5.0.

Right now only the Windows build is available. I hope to get the Mac and Linux ones up later today.[/QUOTE]

I get a crash in 3.5.1, apparently when I use the p(n) function (from the command line, GUI, or from an ABC2 file). E.g. this makes it crash: "pfgw32 -q349*p(1)^5-1".

rogue 2011-09-25 20:02

[QUOTE=Mini-Geek;272704]I get a crash in 3.5.1, apparently when I use the p(n) function (from the command line, GUI, or from an ABC2 file). E.g. this makes it crash: "pfgw32 -q349*p(1)^5-1".[/QUOTE]

This is already fixed. 3.5.2 will be posted tomorrow.

rogue 2011-09-27 12:42

[QUOTE=rogue;272711]This is already fixed. 3.5.2 will be posted tomorrow.[/QUOTE]

I have posted 3.5.2 patching the known issues.

rogue 2011-09-27 15:27

A small bug was discovered in the nextprime function. I have re-released 3.5.2 to fix it. No other changes were made.

Batalov 2011-09-30 02:21

Oh, @#$!

I've used 3.5.0 with scr.txt to start a couple bases (R291, S381). They were royally screwed. A huge bunch of small composites (e.g. 2*291^1-1) "pass" both PRP and the N+1 test and get into pl_prime.txt.

Was this fixed in 3.5.2? I am switching back to 3.4.9, better safe than sorry. (of course, many of the k values that passed "as primes at n=1 with 3.5.0" get other small primes, but a significant portion don't; the whole script has to be rerun.)

rogue 2011-10-08 13:36

I've posted 3.5.5. Testing has shown that known problems are resolved. Batalov, can you do a little test to see if it works correctly for those two bases?

Batalov 2011-10-08 19:54

Will do.

Batalov 2011-10-08 21:00

Looks good now.

[SIZE=1]I tested on R291, S381 (so PRP and both N+1 and N-1 on small inputs were in use) - on linux64 and on Windows (both GUI and plain). The outputs were correct.[/SIZE]

rogue 2011-10-08 22:58

[QUOTE=Batalov;273825]Looks good now.

[SIZE=1]I tested on R291, S381 (so PRP and both N+1 and N-1 on small inputs were in use) - on linux64 and on Windows (both GUI and plain). The outputs were correct.[/SIZE][/QUOTE]

Thanks.

Antonio 2011-10-09 07:38

Rogue,
There appears to be a bug in the command line option -f,
choose any value other than 100 and the software defaults to trial factoring to 4000000000 (tried 125, 110,95).
Using PFGW 3.5.5 win32 GUI
Command line: -f100 -tp in.txt
(wanted to use -f125)
Noticed when testing 19081#*2^19081-1

rogue 2011-10-09 13:17

[QUOTE=Antonio;273857]Rogue,
There appears to be a bug in the command line option -f,
choose any value other than 100 and the software defaults to trial factoring to 4000000000 (tried 125, 110,95).
Using PFGW 3.5.5 win32 GUI
Command line: -f100 -tp in.txt
(wanted to use -f125)
Noticed when testing 19081#*2^19081-1[/QUOTE]

Thanks for the bug report. I'll look into it.

Antonio 2011-10-22 10:39

Just a quick note, since Rogue is obviously too busy to let us know, PFGW has been updated to version 3.5.6.

From the release notes: -

Released as version 3.5.6 October 17, 2011

Enhancements to: v3.5.6 Release
- Added prevprime() function.
- Fixed ABC2 file with "primes from" as from value would be ignored.
- Fixed issue when providing an argument with -f

Antonio 2011-10-27 22:58

Another bug, this time in the -od option. Notice that the decimal expansion is even!
[code]
./pfgw64 -od -q666*2^10000000+1

PFGW Version 3.5.6.64BIT.20111017.Mac_Dev [GWNUM 26.6]

666*2^10000000+1: 6027178326036293000730004176693999099261675750419989782156673780307526936651469097894095915353330168605112259848598442680650797401953752910894574474348456452678969840684866227356284848260760393354965487780341356435837487629780943899249110103424142336340406409392308923265160463624514438111845439275611169923357588751835066011134448530104080536242198551017390974604488308770647404853695151764071767277299567525378922561331187367782198692923844934882746265520086935772691716724155059371570280260200095576179919305538804645776190796716606063296319013924651850357522917392379810172162901399942193234586677179203156447460116368166114370874279085185037294816638226612623912628112593935404738487364381393601542951358807702172973942879588808661406290608190779801551681455542618744425175473892681030973527786969705856920052264480772203495853676909659460936874780381264121159911714354426526884619707886099932388595455411862777682417275252311573047896200342159513274726238429095249335548094041255054516296896027479361977843990171246972806967414888362902538319710850431327787379891984392090989489732574067819920363799122521434858436013809938408908065474856254564496120899018863822667824802022009571129281951510719618867662258694711347516738068581238820931747196812380853566005268419708130517223954232296374909179388276575979467787016957164873459006264686161560417142943222795024687685855508993123483016976567064852994521349371199112466792744507695599260967265329101400016700376669918228974459326604577217222735623765454296411946953810515124854266641871713992401957375061884079632378031277879394202231331330010225514941497220155073091796354225278706975035239983604165698542656590044086359415376923211092636645042696701956521783662557072563093437024305531152042776837008290779118111051583489552645032950891615050326233361615039848286228806160495147701938174555772282670322547358223984050997057002098333369009922625702748728842858098058231045531142458999052369864720033042582478560379034481882429929725199630195676513881981478446933794575006672
[/code]

rogue 2011-10-27 23:00

[QUOTE=Antonio;276044]Another bug, this time in the -od option. Notice that the decimal expansion is even![/QUOTE]

That isn't the entirety of the decimal expansion. I'll investigate.

LaurV 2011-10-28 06:10

Something wrong with copy/paste :smile:
Two at the power of 10 millions should have 3 millions digits. Or am I out of the subject?

Antonio 2011-10-28 06:29

[QUOTE=LaurV;276082]Something wrong with copy/paste :smile:
Two at the power of 10 millions should have 3 millions digits. Or am I out of the subject?[/QUOTE]

Well spotted that person, my semi-mistake! :blush:
If I output to a file the answer looks possible and the correct length, it's the output to the console (shown correctly in the post) that is completely screwy.

rogue 2011-10-28 13:36

I think it is due to an inherent limit in output written to stderr on OS X. The buffering of the output is done by the OS, not pfgw. pfgw on Windows outputs the entire string.

Antonio 2011-10-28 15:12

[QUOTE=rogue;276111]I think it is due to an inherent limit in output written to stderr on OS X. The buffering of the output is done by the OS, not pfgw. pfgw on Windows outputs the entire string.[/QUOTE]

That sounds possible as the output appears to truncate after printing the correct initial part of the string.
Not a problem now I know it happens and I can't do a quick look without sending the result to a file.

Cruelty 2011-11-01 11:13

Hi,
Is there a way to set affinity for each instance of pfgw64 / win64pfgw running under windows (other than using task manager)?

rogue 2011-11-01 12:29

[QUOTE=Cruelty;276574]Hi,
Is there a way to set affinity for each instance of pfgw64 / win64pfgw running under windows (other than using task manager)?[/QUOTE]

Not at this time.


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

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