help request for LL double-check

preda · 2017-04-12, 02:02

Hi,
I'm working on a GPU LL-checker for radeon gpus (OpenCL-based ATM). I've started doing some validation runs (for debugging), and I get this interesting result:
the residue for M39527687, according to my implementation, is 0x8CDEA969BA2CF98B.

But this exponent has been validated (LLd twice) with the outcome 0x8CDEA969BA2CF98A (see http://www.mersenne.ca/exponent/39527687 ).

Now I'm mystified as to what would produce this strange off-by-one residue in my implem (I would normally expect a more catastrophic error from a bug).

Could somebody do one more LL on M39527687 (and report the residue), to convince me that the error is on my side.

thanks,
Mihai

GP2 · 2017-04-12, 02:26

You didn't provide information about how much other testing you've done.

Have you tried your implementation on some very small exponents, say between 1M and 2M ?

If so, do you get the same off by one error?

If not, can you try it one more time on a different exponent in the 39M range and see if you get the same error?

Prime95 · 2017-04-12, 02:42

Quote:

Originally Posted by preda

Now I'm mystified as to what would produce this strange off-by-one residue in my implem (I would normally expect a more catastrophic error from a bug).

I'd guess the odds are 2^63-to-1 that this is a program bug. Everything worked just fine except there is a bug in printing the 64-bit residue (most likely some kind of dropped carry out of the topmost bit). Is this your own program?

preda · 2017-04-12, 14:11

The program right now works with some fixed power-of-two FFTs only (2M and 4M), which allows LL on about up-to-40M and up-to-80M (a bit less than that, about 18.5 bits per word). But it can't do too-small bits-per-word due to the way carry propagation is implemented (because small bits produce long carry chains).

Thus, in short, I haven't tested it on small exponents. OTOH I did test in on other exponents in the 35M range and it did produce the correct residue. For this particular exponent mentioned here I did run it twice, once with 2M FFT and once with the 4M, and got the same result.

This would seem to indicate the problem to be related to carry propagation, yes. This is my own program, I'm preparing right now to open source it on github just need to do a bit more polishing (and finding out the root of this bug).

ATH · 2017-04-12, 14:30

I can test it again, ETA 14-18 hours depending on how much I use my computer tonight.

preda · 2017-04-12, 15:22

Thanks! it's a GPU LL? CUDALucas?

ATH · 2017-04-13, 06:47

As expected it matched: http://mersenne.org/M39527687

It was run on a Haswell-E 5960X using all 8 cores, Prime95 28.9 build 2.

preda · 2017-04-13, 07:07

Thank you! indeed as expected.

Interesting, my program did verify correctly other exponents, e.g. https://www.mersenne.org/report_expo...000201&exp_hi=

Need to look deeper into this problem.

preda · 2017-04-13, 07:10

A side question, how did you self-assign that exponent in prime95 for a 3rd LL? (I think the "manual testing" web interface would not assign an exponent that's already verified).

GP2 · 2017-04-13, 07:37

Quote:

Originally Posted by preda

A side question, how did you self-assign that exponent in prime95 for a 3rd LL? (I think the "manual testing" web interface would not assign an exponent that's already verified).

You can always add a line like this:

Code:

AdvancedTest=39527687

But I just checked and this isn't documented in either readme.txt or undoc.txt

PS,
If mprime/Prime95 is not running, you can just edit worktodo.txt directly to add the line.

If it is already running, then it's best to create a new file called either worktodo.add or worktodo.add.txt with the line, and then mprime/Prime95 will automatically delete this file and append its contents to worktodo.txt the next time it does a disk write of save files (every ten minutes, by default, unless you changed DiskWriteTime in prime.txt).

If you edit worktodo.txt directly while mprime/Prime95 is already running, then your changes might get overwritten and undone. However, this will usually work if you also create an empty worktodo.add or worktodo.add.txt file. I've done this, for instance, to reorder the lines in worktodo.txt in order to pause one exponent and start another. As above, this takes effect at the next disk write (e.g., 10 minutes after the timestamp on your p* save files).

ATH · 2017-04-13, 12:01

I just added the line to the worktodo.txt
Test=39527687,75,1

2017-04-12, 02:02	#1
preda "Mihai Preda" Apr 2015 3·457 Posts	help request for LL double-check Hi, I'm working on a GPU LL-checker for radeon gpus (OpenCL-based ATM). I've started doing some validation runs (for debugging), and I get this interesting result: the residue for M39527687, according to my implementation, is 0x8CDEA969BA2CF98B. But this exponent has been validated (LLd twice) with the outcome 0x8CDEA969BA2CF98A (see http://www.mersenne.ca/exponent/39527687 ). Now I'm mystified as to what would produce this strange off-by-one residue in my implem (I would normally expect a more catastrophic error from a bug). Could somebody do one more LL on M39527687 (and report the residue), to convince me that the error is on my side. thanks, Mihai

2017-04-13, 06:47	#7
ATH Einyen Dec 2003 Denmark 110001010111₂ Posts	As expected it matched: http://mersenne.org/M39527687 It was run on a Haswell-E 5960X using all 8 cores, Prime95 28.9 build 2. Last fiddled with by ATH on 2017-04-13 at 06:47

Similar Threads
Thread	Thread Starter	Forum	Replies	Last Post
Double-check request	Xyzzy	Mlucas	21	2015-06-10 14:34
Double Check	Unregistered	Information & Answers	3	2011-10-01 04:38
First check and double check llrnet servers.	opyrt	Prime Sierpinski Project	3	2009-01-02 01:50
Double-check check?	M0CZY	Software	15	2008-10-30 14:20
Double Check P-1	PhilF	PrimeNet	6	2005-07-03 14:36

2017-04-12, 02:26	#2
GP2 Sep 2003 5·11·47 Posts	You didn't provide information about how much other testing you've done. Have you tried your implementation on some very small exponents, say between 1M and 2M ? If so, do you get the same off by one error? If not, can you try it one more time on a different exponent in the 39M range and see if you get the same error?

2017-04-12, 14:11	#4
preda "Mihai Preda" Apr 2015 1371₁₀ Posts	The program right now works with some fixed power-of-two FFTs only (2M and 4M), which allows LL on about up-to-40M and up-to-80M (a bit less than that, about 18.5 bits per word). But it can't do too-small bits-per-word due to the way carry propagation is implemented (because small bits produce long carry chains). Thus, in short, I haven't tested it on small exponents. OTOH I did test in on other exponents in the 35M range and it did produce the correct residue. For this particular exponent mentioned here I did run it twice, once with 2M FFT and once with the 4M, and got the same result. This would seem to indicate the problem to be related to carry propagation, yes. This is my own program, I'm preparing right now to open source it on github just need to do a bit more polishing (and finding out the root of this bug).

2017-04-12, 14:30	#5
ATH Einyen Dec 2003 Denmark 3⁵·13 Posts	I can test it again, ETA 14-18 hours depending on how much I use my computer tonight.

2017-04-12, 15:22	#6
preda "Mihai Preda" Apr 2015 3×457 Posts	Thanks! it's a GPU LL? CUDALucas?

2017-04-13, 07:07	#8
preda "Mihai Preda" Apr 2015 3×457 Posts	Thank you! indeed as expected. Interesting, my program did verify correctly other exponents, e.g. https://www.mersenne.org/report_expo...000201&exp_hi= Need to look deeper into this problem.

2017-04-13, 07:10	#9
preda "Mihai Preda" Apr 2015 3·457 Posts	A side question, how did you self-assign that exponent in prime95 for a 3rd LL? (I think the "manual testing" web interface would not assign an exponent that's already verified).

2017-04-13, 12:01	#11
ATH Einyen Dec 2003 Denmark 3⁵·13 Posts	I just added the line to the worktodo.txt Test=39527687,75,1