The P-1 factoring CUDA program

[GhettoChild]

So I'm using a 4GB eVGA GTX 770 Classified (Kepler). I was originally unable to run any version of CUDAPm1 higher than CUDA 5.5, on this Win7 HP 64-bit, PC currently set to default clock speeds. I kept getting "the program can't start because api-ms-win-crt-runtime--1-1-0.dll is missing"; same message if I tried to launce GeForce Experience. I tried installing Service Pack 1 but that didn't help, waste of time & space. Then I installed Microsoft KB2999226. That seems to have solved that, I can now run higher than CUDA 5.5 versions.

So according to this GPU's specs, I should be able to run CUDA 10. For the most part CUDA 8 seems to run ok but I can't understand why CUDA 10 in both CUDAPm1 v021 & 0.22 just fail right from the start. Attached are my lengthy screen output logs.

[kriesel]

fft size = 30870K, ave time = 61.7556 msec, max-ave = 0.08239
C:/Users/Aaron/Documents/Visual Studio 2017/Projects/CUDAPm1/CUDAPm1/bench.cu(202) : cudaSafeCall() Runtime API error 30: unknown error.

Try splitting up your -fftbench. (Save the results of the first run under a different filename, before making the second, or the second will overwrite/delete the first)
-fftbench 1 16384
-fftbench 16384 32768
I've never had to go that low, but gpu models vary. API error 30 seems to be associated with the Windows TDR (timeout detection and recovery). You may want to try increasing the timeout period in the registry settings. Not using the system interactively during benchmarking is recommended.

I:\GIMPS GPU Computing\CUDAPm1>cudapm1_win64_20181114_CUDA_10_v021.exe -threadbench 1 32768  2>&1 
CUDAPm1 v0.21
can't parse options

CUDALucas syntax for threadbench does not work in CUDAPm1.
CUDAPm1 -cufftbench 4608 4608 2
for threadbench at 4608k, 2 passes.
I usually wrap that in a batch file and for loop, with only the fft lengths listed in the fft file, with parameter substitution.

The zero values for benchmark timings are a problem.
The 0x0000000000000001 res64 values are a problem.

I see you're running CUDAPm1 v0.21. I have no experience with that version. But much will be similar to v0.20, which you could try. Or v0.22.

For some background info see https://www.mersenneforum.org/showthread.php?t=23389
If CUDA8 runs well, on your setup, use it.

[GhettoChild]

I've used an assortment of versions and the uploads are both v021 and v0.22. v0.20 CUDA5.5 never gave these problems to do the identical scripted tests. I run the same script of work as a "Self Test" batch file on each version the first time before I start new work. CUDA8 v0.22 seems to work as it passes most of the tests; I'm only having an issue at Stage 2 M120002191 FFT 6912K it just crashes without status. Then no version of CUDA10 passes any tests; I either get zeros ending with a 1 for residues or an error code. CUDA10 v0.22 did complete the cufftbench once without issues from 1-32768: "totalavg: 488.4344 totallen: 8133237 totaltime: 16651.6445". I couldn't get a pass again after that one. The drive these are running on do have less than 4GB free space but it's an extra drive not the main OS drive.

With your suggestion about splitting the cufftbench, this is all a batch file that I run. I don't know of a way to make the batch file pause between commands for input to continue; as well splitting the work into two batch files equally defeats the purpose of lengthy-unattended scripting.

Doesn't higher CUDA suites mean higher performance? Isn't CUDA10 faster than CUDA8? That's why I'm trying to get it to work. Also despite CUDA8 seems to work, it crashed at Stage 2 M120002191 FFT 6912K but v0.20 CUDA5.5 completed that exponent and larger without issue.

[kriesel]

Originally Posted by GhettoChild

I'm only having an issue at Stage 2 M120002191 FFT 6912K it just crashes without status.

Sometimes a relaunch from that point (or 2 or 3) will coax it to finish. It depends on getting different roundoff behavior from one attempt to the next. I've hit rough spots that simply would not run on certain cards. Even a different card of the same gpu model could run what one card couldn't. The gpu BIOS versions differed. Higher and lower exponents worked ok, but around 85M would not run to completion on a certain Quadro 2000. There was another case around 171M as I recall. Stage 2 silent halt was described by the author as occurring due to excessive roundoff error. Sometimes a retry produces less roundoff error.

With your suggestion about splitting the cufftbench, this is all a batch file that I run. I don't know of a way to make the batch file pause between commands for input to continue; as well splitting the work into two batch files equally defeats the purpose of lengthy-unattended scripting.

MODIFY the batch file, to split the cufftbench task into pieces. Instead of "cudapm1 -cufftbench 1 32768 2 >>logfile" in the batch file,

cudapm1 -cufftbench 1 16384 2 >>logfile
rename "(whatever) fft.txt" "(whatver) fft save.txt"
if errorlevel 1 goto exit
: preceding detects rename failure and bails, preventing loss of first cufftbench pass
cudapm1 -cufftbench 16384 32768 2 >>logfile
echo whatever prompt you want, for interactive action via a separate process, such as: merge fft files via a text editor, then press a key here
pause

(threadbench portion etc of batch file)


:exit
(end of batch file)
https://www.computerhope.com/pausehlp.htm

Doesn't higher CUDA suites mean higher performance? Isn't CUDA10 faster than CUDA8? That's why I'm trying to get it to work. Also despite CUDA8 seems to work, it crashed at Stage 2 M120002191 FFT 6912K but v0.20 CUDA5.5 completed that exponent and larger without issue.

No. If it won't run, CUDA10's performance is zero. I've not heard that I recall of any significant performance advantage to CUDA10 on older cards. CUDA 10 is necessary for compatibility for some new cards that have a higher compute capability level than is supported in CUDA 8 or CUDA 9.x. A card that requires CUDA10 can't run on CUDA8. Continuing downward, CUDA8 or above is required for the GTX10xx family. I've often seen CUDA levels higher than required for a card give LESS performance than older CUDA levels also supported on the same hardware. For example, CUDA 5 or 6 generally are faster than CUDA 8 in CUDALucas on GTX480, which is a compute capability 2.0 card. Even NVIDIA makes no claims of performance improvements for the fft library at CUDA10.x, which is what counts for CUDAPm1 and CUDALucas performance, at https://developer.nvidia.com/cuda-toolkit/whatsnew All that stuff they list as improved there? Not used in CUDALucas or CUDAPm1.
See also https://www.mersenneforum.org/showpo...47&postcount=8 and its attachment.

[kriesel]

I've also noticed in some cases (small ram gpus) higher CUDA level means slightly lower maximum benchmarkable fft length. Perhaps a couple percent lower.

[GhettoChild]

I was able to complete v0.22 CUDA8 up to M200001187 iteration 32 had error 0.4074 so that's acceptable a test for me for now. Increasing the unused memory parameter from defualt 100 to 300 allowed it to reach this far. CUDA10 fft bench completed and resulted slower than CUDA8 like you stated; however all other test exponents and selftests resulted in residues of zeros ending in a 1.

[kriesel]

In a nutshell, a GTX1080 Ti gpu, with 11GB, goes underutilized in at least two ways with one CUDAPm1 v0.20 instance. During stage 2, memory usage is ~4.5GB. During stage 1 gcd and stage 2 gcd, gpu memory is still occupied but the gcd is done on a cpu core and the gpu cores sit idle. For p~48M, on my test system, that's ~10% of the time that the gpu cores are idle.

Initial testing indicates that running two instances with a slight stagger gives about 9.5% higher aggregate throughput. Presumably this is due to one instance making full use of the gpu cores while the other is waiting on the cpu core to perform a gcd. After each instance have completed a couple of exponents through both stages, the stagger appears stable. I've initiated logging in GPU-Z to check whether any gpu idle or low utilization percentage occurs. So far, in almost an hour of logging, there's only about 20 seconds of gpu core idle indication.

Peak gpu memory usage is ~8593MB when stage 2 of two instances coincide, indicating 3 instances probably would not fit without memory contention. Since cudapm1 queries available gpu ram at the beginning and determines bounds for later use based on that, and NRP values, it might run into insufficient-memory problems with 3 or more instances. I think the case for any potential incremental throughput from a third instance is weak.

(All testing done in Windows 7, dual-E5520-Xeon system. Effect would be proportionally smaller with a proportionally faster cpu core.)

[petrw1]

Originally Posted by kriesel

In a nutshell, a GTX1080 Ti gpu,

Did I miss it or did you post the actual time it would take to complete a P-1.
For example a current P-1 in the 85M ranges to recommended bounds?

Thanks

[kriesel]

Originally Posted by petrw1

Did I miss it or did you post the actual time it would take to complete a P-1.
For example a current P-1 in the 85M ranges to recommended bounds?

Thanks

On the gtx1080 Ti, p~48M (DC wavefront), sums of stage 1 and stage 2 timings in console output:
one instance ~38:46 baseline
two instances ~70:08, throughput ~1/35:04, ~10.56% faster than single instance after I adjusted the stagger between the two instances (by stopping one for two minutes, then resuming it) to eliminate a brief 20-30 second recurring period of gpu cores idle.

For single-instance run times, nrp, bounds selected by the program etc, versus gpu model and exponent, see the attachments at https://www.mersenneforum.org/showpo...73&postcount=9 and the couple of posts preceding.

On the gtx1080 Ti, 90M a single instance is about 2.5 hours; the run time scaling is about p^2.05.

Note, I don't think running multiple instances will work well at p>~61M on the 11GB GTX1080Ti because of stage 2 memory requirements. A 16GB gpu should be ok to p~89M.

[masser]

Originally Posted by kriesel

... goes underutilized in at least two ways with one CUDAPm1 v0.20 instance...

Perhaps I missed something, but why v0.20, instead of v0.22?

[ixfd64]

I believe the 0.22 fork has some regressions.