PFGW 4.0.4 (with gwnum v30.10) Released

[axn]

Originally Posted by rogue

I agree that it would be better if PFGW could do that itself, but the challenge is the change in FFT boundaries. PFGW has no knowledge of that.

Why should it need to know FFT boundary and stuff? All it needs to keep track of is the iteration count and CPU/wall clock time, from which a running average of iteration time can be displayed.

[henryzz]

Originally Posted by rogue

Let me restate that. I use a clock and run the PRP test for up to two minutes. I then ^C PFGW then restart to see which bit it restarts at. I can then estimate the time to do a full PRP test.

I agree that it would be better if PFGW could do that itself, but the challenge is the change in FFT boundaries. PFGW has no knowledge of that.

PFGW outputs the fft length with the -V option. Would it be possible to check what the fft length prime95 outputs is every 1000 n and just output if the string changes or something?

[rogue]

Originally Posted by henryzz

PFGW outputs the fft length with the -V option. Would it be possible to check what the fft length prime95 outputs is every 1000 n and just output if the string changes or something?

I could, but it would probably be better to get that information directly from gwnum. I will talk to George about it.

[rogue]

I have posted pfgw 3.6.7 at sourceforge. It fixes a crash that occurs when using a helper file.

[Cruelty]

Would it be possible to implement resuming of n+1 tests in pfgw? I was recently verifying a number using the following command

-a2 -tp -q(2^1882787-2^941394+1)/5

and it was a real pain with no resuming as I had to restart PC during that time

[rogue]

Originally Posted by Cruelty

Would it be possible to implement resuming of n+1 tests in pfgw? I was recently verifying a number using the following command

-a2 -tp -q(2^1882787-2^941394+1)/5

and it was a real pain with no resuming as I had to restart PC during that time

It's possible, but not easy. All PRP tests are done using a single algorithm, so it is easy to save the state and restart from that state. Multiple algorithms are used for primality tests so each of them would have to change and each change would be specific to that algorithm. It requires a lot more code and quite a bit of testing.

[AG5BPilot]

Originally Posted by Cruelty

Would it be possible to implement resuming of n+1 tests in pfgw? I was recently verifying a number using the following command

-a2 -tp -q(2^1882787-2^941394+1)/5

and it was a real pain with no resuming as I had to restart PC during that time

One way to make this more user friendly -- especially with a very long test -- is to run PFGW inside a virtual machine. You can then start and stop the VM whenever you want, but as far as PFGW is concerned, it never stopped running.

[Cruelty]

Originally Posted by AG5BPilot

One way to make this more user friendly -- especially with a very long test -- is to run PFGW inside a virtual machine. You can then start and stop the VM whenever you want, but as far as PFGW is concerned, it never stopped running.

Interesting -I'll try it next time. Thanks

[rogue]

I have posted pfgw 3.7.0 at sourceforge. You will have to access it via the "Files" menu option as I don't have it set up as the default d/l for Windows users. It has two main differences. First, it restores tree factoring code that was in pfgw before I took it over. This vastly increases factoring times when using -f. Second, it fixes a console output issue on *nix machines when an output line exceeds 2000 bytes.

The tree factoring code is "lightly" tested, but has few changes from the original code outside of getting it to build on a 64-bit machine. The Mac and Linux builds are not yet available, but should be within a day or two.

[henryzz]

Originally Posted by rogue

I have posted pfgw 3.7.0 at sourceforge. You will have to access it via the "Files" menu option as I don't have it set up as the default d/l for Windows users. It has two main differences. First, it restores tree factoring code that was in pfgw before I took it over. This vastly increases factoring times when using -f. Second, it fixes a console output issue on *nix machines when an output line exceeds 2000 bytes.

The tree factoring code is "lightly" tested, but has few changes from the original code outside of getting it to build on a 64-bit machine. The Mac and Linux builds are not yet available, but should be within a day or two.

Did I read you saying on the mailing group that it was faster on 32-bit because of asm?

[rogue]

Originally Posted by henryzz

Did I read you saying on the mailing group that it was faster on 32-bit because of asm?

Factoring might be faster, not just because it has its own asm routine (instead of GMP), but because it can test two potential factors at a time in the asm routine.