mersenneforum.org MLucas, submit results?
 Register FAQ Search Today's Posts Mark Forums Read

 2015-05-16, 06:23 #12 alexvong1995   Dec 2014 37 Posts Yeah! So I have stepped through that fetal error and retry safely. I really need to learn gdb so that I can also debug my code like what you did. Pointers and segfaults are the most confusing things to newbie C programmers. Three Star Programmer is a good old joke. Regarding the duplicated lines, I think I should not be piping stdout to the stat file. Actually, I run mlucas by this command in tty1 Code: $nice ./Mlucas &> /dev/null My .bashrc is as followed: if it is tty1, run mlucas with the above command. The ttys are set up to be auto-logined. Will piping to /dev/null affect anything? 2015-05-16, 07:48 #13 alexvong1995 Dec 2014 37 Posts Building Mlucas for i386 on amd64 Quote:  Originally Posted by ewmayer Again, I would be interested in seeing the specific error message(s) you get - this sounds like it might be the ran-out-of-registers issue I mentioned, since unoptimized builds need more registers for the C code surrounding the inline-asm. (The message becomes too long so I have to post it here.) Yes. I think you are right, optimization makes better use of registers thus eliminating the run-out-register error. About the i386 build, I have managed to build after applying a patch to the source code (by trial-and-error) and build with Code: $ gcc -m32  -Di386_build -o mlucas *.c -lm
I try to build without -DUSE_SSE2 and -DUSE_THREADS because it is the case where mlucas almost get built (90/95 source files get built vs 5x/95 in the -DUSE_SSE2, -DUSE_THREADS or both attempts)
I find problem in radix44_ditN_cy_dif1.c and radix176_ditN_cy_dif1.c. Compiler complains about undeclared a0, a1 ... a9, b0, b1 ... b9 in the expansion of radix44_main_carry_loop.h and radix176_main_carry_loop.h respectively. So what I do is to copy the declreation inside the #ifdef USE_SSE2 ... #endif in front of the #include radix44_main_carry_loop.h, and it seems working magically. The problems and the solutions of radix44_ditN_cy_dif1.c and radix176_ditN_cy_dif1.c are identical.

Besides, there is also problem in get_fft_radices.c. When I try to compile, there are two case 7.
Code:
        case 7 :
numrad = 6; rvec[0] = 16; rvec[1] =  8; rvec[2] =  8; rvec[3] =  8; rvec[4] =  8; rvec[5] = 16; break;
case 7 :
numrad = 5; rvec[0] =  8; rvec[1] = 16; rvec[2] = 16; rvec[3] = 32; rvec[4] = 16; break;
So when USE_ONLY_LARGE_LEAD_RADICES is defined, there will be 2 case 7, causing compiler error. I try to add something like #ifdef USE_ONLY_LARGE_LEAD_RADICES. It does works, but mlucas will segfault after it finishes self-testing via
Code:
\$ ./mlucas -s m

Finally, when I do the self-testing mentioned above, mlucas exit after a fetal error when using 144 as one of its radices and the error message comes from
Code:
            default :
sprintf(cbuf,"FATAL: radix %d not available for ditN_cy_dif1. Halting...\n",radix_vec0); fprintf(stderr,"%s", cbuf);    ASSERT(HERE, 0,cbuf);
in mers_mod_square.c
The solution I attempted is to add a case 144 by copying case 288 below. This prevents mlucas from exiting after the fetal error occurs. Instead, a fetal error caused by insane ROE occurs, mlucas halt testing and try another radix set instead of 144.

These are what I find out last night. The patch is included in the attachment. I define the new feature test macro i386_build just to prevent the new changes break existing code. Maybe I will post the self-testing result after I am done with it.
Attached Files
 i386_build.diff.bz2 (1.6 KB, 122 views)

2015-06-01, 02:57   #14
ewmayer
2ω=0

Sep 2002
República de California

2×13×443 Posts

Alex, I reran the first ~30M iterations of your test on my Haswell quad and the rest on my new Broadwell NUC, final result matches yours. Max roundoff error I encountered using an AVX2-mode (that is an FMA-using) build was 0.375 (3 such during the run). Zipped .stat file attached.
Attached Files
 p67773569.stat.bz2 (137.4 KB, 130 views)

2015-06-09, 15:03   #15
Serpentine Vermin Jar

Jul 2014

52×131 Posts

Quote:
 Originally Posted by ewmayer Alex, I reran the first ~30M iterations of your test on my Haswell quad and the rest on my new Broadwell NUC, final result matches yours. Max roundoff error I encountered using an AVX2-mode (that is an FMA-using) build was 0.375 (3 such during the run). Zipped .stat file attached.
I'm doing a full double-check of M67773569 on Prime95 so we should see how that does in ~58 hours.

2015-06-12, 01:25   #16
Serpentine Vermin Jar

Jul 2014

52·131 Posts

Quote:
 Originally Posted by Madpoo I'm doing a full double-check of M67773569 on Prime95 so we should see how that does in ~58 hours.
Done, it matched. M67773569

 2015-06-12, 06:13 #17 ewmayer ∂2ω=0     Sep 2002 República de California 2×13×443 Posts Thanks for the verify - I had no doubts after my DC, but because my code isn't officially allowed to do both the 1st and 2nd runs (no power-of-2 residue shift is used), you just made it official. Does your logfile indicate what the max ROE for your run was?
2015-06-13, 03:12   #18
Serpentine Vermin Jar

Jul 2014

1100110010112 Posts

Quote:
 Originally Posted by ewmayer Thanks for the verify - I had no doubts after my DC, but because my code isn't officially allowed to do both the 1st and 2nd runs (no power-of-2 residue shift is used), you just made it official. Does your logfile indicate what the max ROE for your run was?
I'm just running Prime95 so only if it went over 0.4 at any point. I don't have that saved but it doesn't happen often and I tend to remember when it does. Well, not a specific exponent, but if I've seen one at all in the past few days. And I don't think I saw any the day I checked that one in.

I *think* it used the 3584K FFT size. Again, I kind of remember paying attention to that since it came up, and I made a mental note of that.

 Similar Threads Thread Thread Starter Forum Replies Last Post DuskFalls GPU Computing 5 2017-12-02 00:34 leonardyan96 PrimeNet 77 2017-06-01 16:18 fairsky Information & Answers 17 2013-09-16 19:49 dabaichi PrimeNet 5 2011-12-07 19:27 Unregistered Information & Answers 12 2011-11-12 20:07

All times are UTC. The time now is 16:52.

Wed Sep 30 16:52:13 UTC 2020 up 20 days, 14:03, 0 users, load averages: 1.29, 1.67, 1.74