Glucas/Mlucas errors...

[ewmayer]

Originally Posted by Xyzzy

I get a different Res64...

[code:1][Xyzzy:~/Desktop/mlucas] mvang% ./mlucas
looking for worktodo.ini file...
no worktodo.ini file found...switching to interactive mode.
Enter exponent, FFT length in K (set K = 0 for default FFT length) >84000013,4608
Enter 'y' to run a self-test, <return> for a full LL test >y
Enter number of iterations for timing test>
100
Enter index of radix set to be used for the FFT:
(See file fft_radix.txt for a list of available choices; enter -1 to get the default) >-1
Enter 'y' to enable per-iteration error checking, <return> for no error checking >y
p is prime...proceeding with Lucas-Lehmer test...
M( 84000013 ): using FFT length 4608K = 4718592 8-byte floats.
this gives an average 17.8019233279758 bits per digit
INFO: Using real* 8 for FFT sincos and DWT weights tables inits.
WARN: radix set -1 not available - using defaults.
Using complex FFT radices 9 16 16 32 32
100 iterations of M84000013 with FFT length 4718592
Res64: 6EA52961F9CAD418. Program: E2.7b
Clocks = 00:19:38.994
STOP[/code:1]

Ah, I didn't look closely enough at your output previously. You're using v2.7b for these - that's the (relatively ancient) Fortran-90 version - no wonder it's less accurate and a heck of a lot slower than expected. I thought you had built the C version of 2.7c at some point?

Using the C version of 2.7c, I have no trouble running the self-test for your 9.49M exponent at 480K FFT length:

[code:1]
M9490001: using FFT length 480K = 491520 8-byte floats.
this gives an average 19.307456461588540 bits per digit
INFO: Using real*16 for FFT sincos and DWT weights tables inits.
WARN: radix set -1 not available - using defaults.
Using complex FFT radices 15 16 32 32
100 iterations of M9490001 with FFT length 491520
Res64: 01A4E738255C522B. AvgMaxErr = 0.215053013. Program: E2.7c
Clocks = 00:00:05.533
[/code:1]

Also, to compare timing-test results between the f90 and C code, you need to run the f90 code for one more iteration than the C, or the C code for one less iteration than the f90. When I run the C/v2.7c code for 99 iterations, I get the same as your "100-iteration" result for v2.7b:

[code:1]
M84000013: using FFT length 4608K = 4718592 8-byte floats.
this gives an average 17.801923327975803 bits per digit
INFO: Using real*16 for FFT sincos and DWT weights tables inits.
WARN: radix set -1 not available - using defaults.
Using complex FFT radices 9 16 16 32 32
99 iterations of M84000013 with FFT length 4718592
Res64: 6EA52961F9CAD418. AvgMaxErr = 0.107991536. Program: E2.7c
Clocks = 00:01:09.213
[/code:1]

Using the more-accurate C version, I can also run all the way up to 87.7M at 4608K (though the RO warnings and the AvgMaxErr > 0.3 indicate this is too large an exponent for a full-length run at this FFT length - p ~= 87.0M is probably the maximum one could safely use):
[code:1]
M87700003: using FFT length 4608K = 4718592 8-byte floats.
this gives an average 18.586053424411350 bits per digit
INFO: Using real*16 for FFT sincos and DWT weights tables inits.
WARN: radix set -1 not available - using defaults.
Using complex FFT radices 9 16 16 32 32
M 87700003 Roundoff warning on iteration 77 maxerr = 0.437500000000
M 87700003 Roundoff warning on iteration 91 maxerr = 0.406250000000
100 iterations of M87700003 with FFT length 4718592
Res64: 3C41DA97B5B87409. AvgMaxErr = 0.323716518. Program: E2.7c
Clocks = 00:01:09.997
[/code:1]

[Xyzzy]

Originally Posted by ewmayer

Ah, I didn't look closely enough at your output previously. You're using v2.7b for these - that's the (relatively ancient) Fortran-90 version - no wonder it's less accurate and a heck of a lot slower than expected. I thought you had built the C version of 2.7c at some point?

That was on my Sun... This is my new iBook... I got the binary from that link I posted earlier... (I'd love to build a new binary, but I wouldn't know where to start!)

If you want a SSH account on my box to work on a Mac client let me know... :)

[Lorenzo]

Hello. Oups. What happened with Mlucas?

I got this on IBM Power8 and Red Hat 7.2.

Mlucas installed without problem ... I hope. Because now not sure.

[Mar 02 21:59:06] M43892801 Iter# = 200000 clocks = 00:16:24.308 [  0.0984 sec/iter] Res64: A82FA0F649C8F274. AvgMaxErr = 0.170602632. MaxErr = 0.250000000
[Mar 02 22:20:42] M43892801 Iter# = 210000 clocks = 00:21:35.630 [  0.1296 sec/iter] Res64: BAFC8160194E1EFA. AvgMaxErr = 0.000000000. MaxErr = 0.000000000

[ewmayer]

Originally Posted by Lorenzo

Hello. Oups. What happened with Mlucas?

I got this on IBM Power8 and Red Hat 7.2.

Mlucas installed without problem ... I hope. Because now not sure.

[Mar 02 21:59:06] M43892801 Iter# = 200000 clocks = 00:16:24.308 [  0.0984 sec/iter] Res64: A82FA0F649C8F274. AvgMaxErr = 0.170602632. MaxErr = 0.250000000
[Mar 02 22:20:42] M43892801 Iter# = 210000 clocks = 00:21:35.630 [  0.1296 sec/iter] Res64: BAFC8160194E1EFA. AvgMaxErr = 0.000000000. MaxErr = 0.000000000

Hi, Lorenzo - Through your v14.1, and *only* in scalar-double mode (x86 SIMD always leaves it on) Mlucas will turn off roundoff error checking of convolution outputs if the first 200k iterations run without any ROE warnings. When I first coded this the typical performance hit of ROE checking was 3-7% ... never seen an actual slowdown like yours, much less a huge slowdown.

This feature was one of the first things I ditched in my current v16.0 code-dev plan ... too dangerous, as ROE warnings can catch not just dangerously high errors but many forms of data corruption.

Your results should be fine, but I suggest you manually go into your Mlucas.c source file, change line 342 from
relax_err=TRUE;
to
relax_err=FALSE;
recompile that file, relink your binary and halt/restart your run.

[Lorenzo]

ewmayer, Thank you very much!

Now it working as before. Very strange with speed. Hope i will verify LL-test.

[Mar 28 11:29:42] M43892801 Iter# = 17350000 clocks = 00:16:25.361 [  0.0985 sec/iter] Res64: 9B98340B8DDCA51F. AvgMaxErr = 0.170527673. MaxErr = 0.226562500
[Mar 28 11:46:07] M43892801 Iter# = 17360000 clocks = 00:16:24.359 [  0.0984 sec/iter] Res64: C4197B369FA08B12. AvgMaxErr = 0.170579383. MaxErr = 0.250000000
[Mar 28 12:02:32] M43892801 Iter# = 17370000 clocks = 00:16:25.449 [  0.0985 sec/iter] Res64: B61947BA0900E712. AvgMaxErr = 0.170759450. MaxErr = 0.250000000
[Mar 28 12:18:57] M43892801 Iter# = 17380000 clocks = 00:16:24.465 [  0.0984 sec/iter] Res64: 964B7F7B7BE64D97. AvgMaxErr = 0.170774248. MaxErr = 0.234375000
[Mar 28 12:35:23] M43892801 Iter# = 17390000 clocks = 00:16:25.531 [  0.0986 sec/iter] Res64: 285FDC8DAC1094B6. AvgMaxErr = 0.170833351. MaxErr = 0.218750000
[Mar 28 12:51:48] M43892801 Iter# = 17400000 clocks = 00:16:24.742 [  0.0985 sec/iter] Res64: B1C09B8BBF18AF65. AvgMaxErr = 0.170672593. MaxErr = 0.250000000

[ewmayer]

Originally Posted by Lorenzo

Now it working as before. Very strange with speed. Hope i will verify LL-test.

We aim to please. :) When the current run finishes, let us know if the result matches that of the 1st-time test already on file.

Still can't believe removal of the extra operations used in the roundoff check caused such a huge slowdown - your compiler must be doing some really bizarre 'optimizations'.

[Lorenzo]

[May 06 00:24:49] M43892801 Iter# = 41170000 clocks = 00:02:29.151 [  0.0149 sec/iter] Res64: 853F7CB9D2160D0B. AvgMaxErr = 0.199261261. MaxErr = 0.281250000

[May 06 00:27:19] M43892801 Iter# = 41180000 clocks = 00:02:29.457 [  0.0149 sec/iter] Res64: 038A7FDF252DD6C4. AvgMaxErr = 0.199309877. MaxErr = 0.281250000

Hello! Looks like i have some problem.
There are Ok? Or MaxErr shouldn't be greater than 0.25?

[Prime95]

MaxErr cannot exceed 0.5. You are looking good.

[Lorenzo]

Originally Posted by Prime95

MaxErr cannot exceed 0.5. You are looking good.

Ahhh, yes!) Just got result. 43892801 was succesfully doublecheced.
Thank you!