CUDALucas (a.k.a. MaclucasFFTW/CUDA 2.3/CUFFTW) - Page 85

Batalov · 2012-03-09, 22:47

Just these two (26059867 and the "M48"). I am not interested enough to make it a regular activity, I was only interested to see if this program works. My plan is to run gpuLucas on the same two numbers, but later, because the end result is somewhat underwhelmingly predictable.

msft · 2012-03-10, 00:59

Quote:

Originally Posted by apsen

Got mismatch for 29027371 with 1.63.

Ver 1.64 have -s and -t option,Please try.

Code:

$ ./CUDALucas
Usage: ./CUDALucas [-d device_number] [-c checkpoint_iteration] [-f fft_length] [-s] [-t] -r|exponent|input_filename
                       -f set fft length
                       -s save all checkpoint files
                       -t check round off error all iterations,when err > 0.49 exit

kladner · 2012-03-10, 02:58

Quote:

Originally Posted by Batalov

Just these two (26059867 and the "M48"). I am not interested enough to make it a regular activity, I was only interested to see if this program works. My plan is to run gpuLucas on the same two numbers, but later, because the end result is somewhat underwhelmingly predictable.

I look forward to those results, when they happen.

LaurV · 2012-03-10, 03:11

I re-ran a series of DC exponents which gave me bad residues in the past (sorry for poaching, they were already re-assigned). I have another 2 matches (totally 4) using v1.64 with -s and -t. Seems to be stable and "well behaved". I am trying 3 expos in the first-time-LL (45M+) front, I will not report the results before DC-ing them with P95 to make sure. CudaLucas v1.64, ~10 hours to go for the first two.

By the way, I found a small cosmetic bug: when -c/-s/-t switches are paired together with -r, CL will crash. There should be a small description, or different pairing of the square brackets in the command line help, or better an improved implementation of the command line parser...

LaurV · 2012-03-10, 08:01

replying to myself... thats a bit odd.. :D

I was quite optimistic... I just reached home after work (my working Saturday today) and found:

Code:

>cl1644120w64 -d 0 -c 250000 -s -t 45130601
...<snip>...
Iteration 33750000 M( 45130601 )C, ....
err = 0.499978,round off err exiting.

it seems to be reproducible, and I would try to insulate it, by calling CL with -c 1k (it was called with -c 250k -s -t).

Two observations came out from this:

First, you can see the utility of -t, as I said before, better safe then sorry. The safety highly compensates for slowness, imagine I would have to repeat whole 33M iterations again... Now the only last 250k (max) would need to be repeated, which is in fact A GAIN OF SPEED, despite the 2% penalty. I love -t! :D I would like to have it setable (like 0.45, 0.37, whatever I like, parameter of the -t switch?).

And the second observation: would it be possible to spit out the iteration number and eventually save a checkpoint file with previous residue when this round off error happens? This would save me from re-running the last 250k (or 500k, or 1M) iterations to insulate the error. I can not use lower values for -c, because the harddisk space will be eaten up very fast by the save files, so 250k is a perfect value for a residue-comparison process, but in case of roundoff error, it would take longer to insulate it or repeat the test.

Dubslow · 2012-03-10, 08:13

Regarding what is safe round off error -- when testing which FFT size to use, Prime95 requires that the average round off be less than .24 (roughly), NOT less than .49. Here's what George had to say:
http://www.mersenneforum.org/showpos...&postcount=102

That would presumably prevent errors like LaurV just encountered.

LaurV · 2012-03-10, 08:19

George reffers to the AVERAGE roundoff error (for 100 or 1k iterations, or so). Which indeed would need to be much lower to catch the spikes going over 0.5. If you check it at every iteration (what -t is doing) then comparing it with 0.5 would be enough. But we skeptic being, to set it lower we would like... (paraphrasing master Yoda..)

msft · 2012-03-10, 08:43

Quote:

Originally Posted by LaurV

By the way, I found a small cosmetic bug: when -c/-s/-t switches are paired together with -r, CL will crash. There should be a small description, or different pairing of the square brackets in the command line help, or better an improved implementation of the command line parser...

Please more information.With linux is OK.

msft · 2012-03-10, 09:30

The roundoff error have two causes, fft length or HW error.
HW error need down clock.

Brain · 2012-03-10, 09:38

Still no mismatch here:

Code:

Processing result: M( 29013107 )C, 0xd9e76769f7b81b52, n = 1572864, CUDALucas v1.64
LL test successfully completes double-check of M29013107

msft · 2012-03-10, 10:02

Quote:

Originally Posted by apsen

Did you get a mismatch? Or is it still running?

Code:

M( 29198173 )C, 0x6fd7e4d6557f5b77, n = 1572864, CUDALucas v1.58

correct.

2012-03-10, 08:01	#929
LaurV Romulan Interpreter Jun 2011 Thailand 3×3,221 Posts	replying to myself... thats a bit odd.. :D I was quite optimistic... I just reached home after work (my working Saturday today) and found: Code: >cl1644120w64 -d 0 -c 250000 -s -t 45130601 ...<snip>... Iteration 33750000 M( 45130601 )C, .... err = 0.499978,round off err exiting. it seems to be reproducible, and I would try to insulate it, by calling CL with -c 1k (it was called with -c 250k -s -t). Two observations came out from this: First, you can see the utility of -t, as I said before, better safe then sorry. The safety highly compensates for slowness, imagine I would have to repeat whole 33M iterations again... Now the only last 250k (max) would need to be repeated, which is in fact A GAIN OF SPEED, despite the 2% penalty. I love -t! :D I would like to have it setable (like 0.45, 0.37, whatever I like, parameter of the -t switch?). And the second observation: would it be possible to spit out the iteration number and eventually save a checkpoint file with previous residue when this round off error happens? This would save me from re-running the last 250k (or 500k, or 1M) iterations to insulate the error. I can not use lower values for -c, because the harddisk space will be eaten up very fast by the save files, so 250k is a perfect value for a residue-comparison process, but in case of roundoff error, it would take longer to insulate it or repeat the test. Last fiddled with by LaurV on 2012-03-10 at 08:10 Reason: added the command line, for clarity

2012-03-10, 08:19	#931
LaurV Romulan Interpreter Jun 2011 Thailand 3·3,221 Posts	George reffers to the AVERAGE roundoff error (for 100 or 1k iterations, or so). Which indeed would need to be much lower to catch the spikes going over 0.5. If you check it at every iteration (what -t is doing) then comparing it with 0.5 would be enough. But we skeptic being, to set it lower we would like... (paraphrasing master Yoda..) Last fiddled with by LaurV on 2012-03-10 at 08:25

2012-03-10, 09:38	#934
Brain Dec 2009 Peine, Germany 331 Posts	Perfect, again Still no mismatch here: Code: Processing result: M( 29013107 )C, 0xd9e76769f7b81b52, n = 1572864, CUDALucas v1.64 LL test successfully completes double-check of M29013107

Similar Threads
Thread	Thread Starter	Forum	Replies	Last Post
Don't DC/LL them with CudaLucas	LaurV	Data	131	2017-05-02 18:41
CUDALucas / cuFFT Performance on CUDA 7 / 7.5 / 8	Brain	GPU Computing	13	2016-02-19 15:53
CUDALucas: which binary to use?	Karl M Johnson	GPU Computing	15	2015-10-13 04:44
settings for cudaLucas	fairsky	GPU Computing	11	2013-11-03 02:08
Trying to run CUDALucas on Windows 8 CP	Rodrigo	GPU Computing	12	2012-03-07 23:20

2012-03-09, 22:47	#925
Batalov "Serge" Mar 2008 Phi(4,2^7658614+1)/2 9,497 Posts	Just these two (26059867 and the "M48"). I am not interested enough to make it a regular activity, I was only interested to see if this program works. My plan is to run gpuLucas on the same two numbers, but later, because the end result is somewhat underwhelmingly predictable.

2012-03-10, 03:11	#928
LaurV Romulan Interpreter Jun 2011 Thailand 22677₈ Posts	I re-ran a series of DC exponents which gave me bad residues in the past (sorry for poaching, they were already re-assigned). I have another 2 matches (totally 4) using v1.64 with -s and -t. Seems to be stable and "well behaved". I am trying 3 expos in the first-time-LL (45M+) front, I will not report the results before DC-ing them with P95 to make sure. CudaLucas v1.64, ~10 hours to go for the first two. By the way, I found a small cosmetic bug: when -c/-s/-t switches are paired together with -r, CL will crash. There should be a small description, or different pairing of the square brackets in the command line help, or better an improved implementation of the command line parser...

2012-03-10, 08:13	#930
Dubslow Basketry That Evening! "Bunslow the Bold" Jun 2011 40<A<43 -89<O<-88 3×29×83 Posts	Regarding what is safe round off error -- when testing which FFT size to use, Prime95 requires that the average round off be less than .24 (roughly), NOT less than .49. Here's what George had to say: http://www.mersenneforum.org/showpos...&postcount=102 That would presumably prevent errors like LaurV just encountered.

2012-03-10, 09:30	#933
msft Jul 2009 Tokyo 610₁₀ Posts	The roundoff error have two causes, fft length or HW error. HW error need down clock.