CUDALucas (a.k.a. MaclucasFFTW/CUDA 2.3/CUFFTW)

[Dubslow]

Originally Posted by zs6nw

If you do get a round-off error "deep" in, is all your previous work wasted?

Somewhere from maybe to probably. Prime95 automatically skips back to the most recent checkpoint, which defaults to every half hour; that older work may still be good, and is worth finishing. (Around half of so called "Suspect" tests turn out to be correct, mostly because of such error handling).

I'm not sure how CUDALucas handles the errors, but I do know that if you use the -s option, it writes all checkpoint files separately, meaning you can choose one and manually revert to an older save file. In such case it is worth finishing the test, but it may or may not be good.

[Dubslow]

In the vein of chalsall's submission spider, and in the lookout to test my Python-foo, I decided to write a CUDALucas result submission spider; more than one exponent has had a mismatch, but we couldn't run Prime95 ourselves because the exponent was submitted before checking for a match. That's what this script is designed to do automatically; it checks the exponent status page, and under the right conditions, submits the exponent result, or else prints a warning.

It is used in the same way as chalsall's spider (and draws much of its design from there): Modify the variables at the top as necessary, and run the spider in the directory containing "result.txt", or provide the correct directory as an argument (e.g. for crontabs).

Errors automatically terminate the program, and include such things as a bad internet connection or a bad response from PrimeNet. If an error occurs, the current "result.txt" is moved to "failed_(NOW).txt", where result.txt contains everything it did before the script started, i.e. no information is lost (excepting an OS error, but then you've got other problems).

Warnings are issued if the script can't parse a line, or can't decide what to do with an exponent; an appropriate message is logged, the offending line is also logged, and the script moves on to the next line.

If an exponent result is correctly parsed, it's passed into the "decide" function, which decides what's appropriate; it has the following logic:

if( 2*"Verified LL" is in the expo status page) {
then submit anyways, just in case
} else if( there is a string of 14 lowercase hex digits [or all decimals] {
        if(all decimals) { print warning; ask user to check exponent manually }
        else { we know there's a CuLu test; exponent will not be submitted
                if(your residue matches another) { print "match"; do not submit }
                else { print no current matches, use Prime95! do not submit }
        }
else { no previous CuLu, and not DCed
        if( there is a matching residue ) {submit!}
        else { print warning: no match; do not submit }
}

If you're reading this far, then presumably you're at least slightly interested; the code is viewable (in browser, no download necessary) at www.dubslow.tk/gimps/CuLuSpider.txt, or you can download it directly from www.dubslow.tk/gimps/CuLuSpider.py .

Unfortunately, due to a paucity of exponents, I have not tested every case; I do know that the "Verified LL" portion works as advertised (thanks msft for posting that 2.00 result you had ), and that it works in the basic case of a match with no prior CuLu result, however the other scenarios remain untested (but *should* work).

If you would like to try running this, you need Python 3, which can be downloaded here: http://python.org/download/releases/3.2.2/#download
In Windows, the installer will associate .py extensions with the interpreter; in *nix, the hashbang should be good enough, assuming you have the interpreter in your PATH.

As always, PLEASE report any bugs or unhandled-exceptions, etc. For the first two or three results, I'd recommend checking the exponent status page, and then watching the script run. And, because I'm not sure that the rest works, please also report any successes, especially for cases I haven't been able to test yet.

(Yes, yes, this is overkill, but now my Python-foo is that much better )

[Brain]

Originally Posted by msft

$ ./CUDALucas -threads 512 332220523
DEVICE:0------------------------
name                GeForce GTX 550 Ti
totalGlobalMem      1072889856
...
start M332220523 fft length = 18874368
err = 0.35937, increasing n from 18874368

start M332220523 fft length = 18874368
err = 0.35937, increasing n from 18874368

start M332220523 fft length = 20971520
Iteration 10000 M( 332220523 )C, 0x1a313d709bfa6663, n = 20971520, CUDALucas v1.66 err = 0.03358 (22:30 real, 134.9292 ms/iter, ETA 12451:20:29)
Iteration 20000 M( 332220523 )C, 0x73dc7a5c8b839081, n = 20971520, CUDALucas v1.66 err = 0.03358 (22:26 real, 134.5456 ms/iter, ETA 12415:34:17)

You're my man. Increasing threads from default 256 to 512 has helped. Thanks.

[apsen]

Originally Posted by flashjh

If it matches yours, let me know so we can submit the results together. It it doesn't match, let me know what you'd like to do.

Yes, that matches the one I got.

[zs6nw]

Originally Posted by Dubslow

By the way, top is showing that CUDALucas is consistently using around 15+% of a core. Is there any reason for this, or a way to stop it?

It seems to be the -k option. Without -k option, my machine is at 1-2% of a core, with -k option it rises to 10-20%.

Also would appreciate a confirmation whether 45ms/iteration is normal for a GT 430:

Iteration 1000000 M( 49845883 )C, 0x656fca42e4bb67e3, n = 2985984, CUDALucas v2.00 err = 0.03711 (1:14:57 real, 44.9724 ms/iter, ETA 609:37:34)

[Dubslow]

Originally Posted by zs6nw

It seems to be the -k option. Without -k option, my machine is at 1-2% of a core, with -k option it rises to 10-20%.

That's depressing, I was having fun with 'p'. I guess I'll turn it off.

Originally Posted by zs6nw

Also would appreciate a confirmation whether 45ms/iteration is normal for a GT 430:

Iteration 1000000 M( 49845883 )C, 0x656fca42e4bb67e3, n = 2985984, CUDALucas v2.00 err = 0.03711 (1:14:57 real, 44.9724 ms/iter, ETA 609:37:34)

That seems about right; that's a low end card, and you're working on the main LL wave, whose tests are 3-4x as much work as the double checks that others here are doing. For 26M, my GTX 460 gets ~6ms/iter, so it'd get ~15ms/iter would be my guesstimate for a 49M. Divide by three for the 430 vs. 460 and then it seems about right. Have you fiddled with other FFT lengths? (Maybe mess with -threads?)

[bcp19]

Originally Posted by zs6nw

It seems to be the -k option. Without -k option, my machine is at 1-2% of a core, with -k option it rises to 10-20%.

Also would appreciate a confirmation whether 45ms/iteration is normal for a GT 430:

Iteration 1000000 M( 49845883 )C, 0x656fca42e4bb67e3, n = 2985984, CUDALucas v2.00 err = 0.03711 (1:14:57 real, 44.9724 ms/iter, ETA 609:37:34)

It is close, James' site estimates 580.1 hours for a 50M exp, so you're within 5%.

[flashjh]

Originally Posted by apsen

Yes, that matches the one I got.

Do you want me to submit my LL and you can submit the DC?

[apsen]

Originally Posted by flashjh

Do you want me to submit my LL and you can submit the DC?

Go ahead.

[flashjh]

Originally Posted by apsen

Go ahead.

All done, thanks.

[Dubslow]

Originally Posted by zs6nw

It seems to be the -k option. Without -k option, my machine is at 1-2% of a core, with -k option it rises to 10-20%.

Hmm, I've turned off -k but I'm still seeing 15-20% CPU usage.

LD_LIBRARY_PATH=~/CUDALucas/lib ~/CUDALucas/CUDALucas -c 10000 -f 1474560 -polite 0 worktodo.txt