![]() |
Re: Glucas/Mlucas errors...
[quote="Xyzzy"][quote="ewmayer"]Try 84000013, which should yield a 100-iteration Res64 = C7323B8F92DCB618.[/quote]
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][/quote] 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] |
Re: Glucas/Mlucas errors...
[quote="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?[/quote]
That was on my Sun... This is my new [url=http://www.teamprimerib.com/jpg/ibook.jpg]iBook[/url]... 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... :) |
1 Attachment(s)
Hello. Oups. What happened with Mlucas? :sad:
I got this on IBM Power8 and Red Hat 7.2. Mlucas installed without problem ... I hope. Because now not sure. [CODE][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. [COLOR="Red"]AvgMaxErr = 0.000000000. MaxErr = 0.000000000[/COLOR] [/CODE] |
[QUOTE=Lorenzo;430176]Hello. Oups. What happened with Mlucas? :sad:
I got this on IBM Power8 and Red Hat 7.2. Mlucas installed without problem ... I hope. Because now not sure. [CODE][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. [COLOR="Red"]AvgMaxErr = 0.000000000. MaxErr = 0.000000000[/COLOR] [/CODE][/QUOTE] 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. |
[B]ewmayer[/B], Thank you very much! :smile:
Now it working as before. Very strange with speed. Hope i will verify LL-test. [CODE][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[/CODE] |
[QUOTE=Lorenzo;430232]Now it working as before. Very strange with speed. Hope i will verify LL-test.[/QUOTE]
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'. |
[CODE][May 06 00:24:49] M43892801 Iter# = 41170000 clocks = 00:02:29.151 [ 0.0149 sec/iter] Res64: 853F7CB9D2160D0B. AvgMaxErr = 0.199261261. MaxErr = [COLOR="red"]0.281250000[/COLOR]
[May 06 00:27:19] M43892801 Iter# = 41180000 clocks = 00:02:29.457 [ 0.0149 sec/iter] Res64: 038A7FDF252DD6C4. AvgMaxErr = 0.199309877. MaxErr = [COLOR="Red"]0.281250000[/COLOR] [/CODE] Hello! Looks like i have some problem. :cry: There are Ok? Or MaxErr shouldn't be greater than 0.25? |
MaxErr cannot exceed 0.5. You are looking good.
|
[QUOTE=Prime95;433290]MaxErr cannot exceed 0.5. You are looking good.[/QUOTE]
Ahhh, yes!) :smile: Just got result. [URL="http://www.mersenne.org/report_exponent/?exp_lo=43892801&full=1"]43892801[/URL] was succesfully doublecheced. Thank you! |
| All times are UTC. The time now is 05:39. |
Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2021, Jelsoft Enterprises Ltd.