The P-1 factoring CUDA program

[nucleon]

Last week hasn't been that great.

[LaurV]

Anyone has a v52 binary for win 64? possibly with rt 5.5 or so?

I took about 30 assignments in 666M which I am TF-ing to ~80 bits and in the same time (on a different card, in parallel) I do P-1 for survivors. Stage 1 goes well (FFT size 38416k), but it crashes when entering stage 2. I had that problem long ago (see pages 38-42 of this thread) which was fixed at the time by playing with the number of threads. I didn't update cudapm1 since then, I know there were some fixes. It works well for 333M, but these expos at 666M may be a bit too high...

[LaurV]

Can someone teach me
1. Where is the last available win64 binary for cudaPM1 program?
2. How can I convince it to run only stage 1 of the algorithm.
3. In case of 2, how can I resume extend B1? (i.e. resuming already finished stage 1, with a larger B1, when I have the last checkpoint file saved at the end of stage 1 run with the older/smaller B1)
Thanks in advance.

[ixfd64]

Two questions:

1. There was talk of adding worktodo.txt parsing to the program. Anyone know whether it has been implemented?
2. I asked this several months ago but didn't get an answer: the code hasn't been updated since late 2013. Has development ceased, or is someone still working on it behind the scenes?

[kriesel]

Originally Posted by ixfd64

Two questions:

1. There was talk of adding worktodo.txt parsing to the program. Anyone know whether it has been implemented?
2. I asked this several months ago but didn't get an answer: the code hasn't been updated since late 2013. Has development ceased, or is someone still working on it behind the scenes?

The worktodo was implemented. It certainly seems to be working on my test installation created days ago.
Some of the names here are the same as on cudalucas etc. Last I heard, flashjh (Jerry) has been working on updating CUDALucas on Windows to reflect code developed in 2013 and address some other bugs and wishlist items.
I'm seeing frequent halts to the cudapm1 program, running it on a GTX480. That's a CC2.0 card, subject to the driver timeout issue for Nvidia driver level >~300, regardless of whether it's running CUDALucas, CUDApm1, or anything else. The cudapm1 error message is:
C:/Users/filbert/Documents/Visual Studio 2010/Projects/CUDAPm1/CUDAPm1.cu(3581) : cudaDeviceSynchronize() Runtime API error 30: unknown error.

I'm also seeing runs of round-off error under 0.08, followed by termination with this message from cudapm1:
err = 0.5 >= 0.40, quitting.
Restarting it it continues fine for about an hour, and has another round-off error & quits.

[storm5510]

Originally Posted by kriesel

...The cudapm1 error message is:
C:/Users/filbert/Documents/Visual Studio 2010/Projects/CUDAPm1/CUDAPm1.cu(3581) : cudaDeviceSynchronize() Runtime API error 30: unknown error...

Keep plugging away at it. I believe several around here would like to see you succeed with this. I would.

[kladner]

Originally Posted by ixfd64

Two questions:

1. There was talk of adding worktodo.txt parsing to the program. Anyone know whether it has been implemented?
2. I asked this several months ago but didn't get an answer: the code hasn't been updated since late 2013. Has development ceased, or is someone still working on it behind the scenes?

IIRC, the author of CUDAPM1 is user owftheevil, whom I have not seen on the forum in a while. I don't know if anyone else did more work from the source code. Dubslow or FlashJH (Jerry) are some who might know more.

[kriesel]

Hi,

I've taken a stab at some minor cosmetic fixes for CUDAPm1 and its ini file. Could someone (perhaps batalov, flashjh, jgchilders, owftheevil, frmky?) please recompile for Windows (at least for 64-bit & CUDA 5.5;other variations can wait), get an updated .exe to me to test, and post the updated ini file to sourceforge? (It's been a long time since I mucked with any C of any flavor, so I'd like to test it myself first, and don't have a build environment.)

From reading the forum recently, I see Friday Nov. 22 2013 owftheevil indicated making some of his last source code changes to date. The date of the executable at https://sourceforge.net/projects/cud.../CUDAPm1-0.20/ is a few days earlier than that (Nov 18 2013, http://www.mersenneforum.org/showthr...=17835&page=39 post #427), while the date of the .cu file at https://sourceforge.net/p/cudapm1/code/HEAD/tree/trunk/ is a few days later (Monday Nov 25 2013), so I'm unsure whether the last fix by owftheevil is in the exe there. (Was r52 fully synced and does it contain the change described in #427 and any changes relating to #444, message date Nov 25 2013?)

Similarly the question "is it current with the latest code" arises with James Heinrich's mirror http://download.mersenne.ca/CUDAPm1/ where the exe date is also Monday Nov 18 2013.

So I suspect the available Windows executables currently correspond to r50, not r52.

Thanks,

Ken

[kriesel]

Originally Posted by storm5510

Keep plugging away at it. I believe several around here would like to see you succeed with this. I would.

Sadly there does not seem much hope of resolving that recurrent Error 30. It's an NVIDIA driver issue impacting compute capability 2.0 or lower GPUs in combination with driver releases above around 300. if I recall correctly. There was an effort to persuade NVIDIA to fix it but supporting older cards for a niche set of users wasn't enough of a priority.

[kriesel]

Originally Posted by kriesel

... I'm also seeing runs of round-off error under 0.08, followed by termination with this message from cudapm1:
err = 0.5 >= 0.40, quitting.
Restarting it it continues fine for about an hour, and has another round-off error & quits.

It appears that was a case of an older GPU declining in reliability. It got to the point it would get stuck on a particular pass of stage two in CUDAPm1, regardless of how many restart attempts were made. It became more frequent over time. The problem pass would vary from exponent to exponent. The checkpoint files were fine and another GPU, same model, could carry them to completion without error. Thorough memory testing of the declining GPU showed that while testing 10 25MB blocks would test error-free, several of blocks 23-40 would error, even when it was significantly underclocked. I recommend essentially full range memory testing. This GPU is likely to be replaced.

[flashjh]

I can compile, I'll see if I can get it today.