mersenneforum.org  

Go Back   mersenneforum.org > Great Internet Mersenne Prime Search > Software > Mlucas

Reply
 
Thread Tools
Old 2020-01-18, 03:54   #12
ewmayer
2ω=0
 
ewmayer's Avatar
 
Sep 2002
República de California

2×13×443 Posts
Default

OK, starting from a copy of the OP's last-checkpoint file and running the last few thousand iterations using a debug-enabled build under gdb, I have found the cause of the bug - there is a small-multiplier computation in PRP final-residue postprocessing which needed an additional (mod b^2) operation, where b is the PRP-test base. None of my PRP runs to date revealed the error.

Anyone who downloaded/built the current 3. Dec code snapshot can incremental-rebuild by compiling the attached patched Mlucas.c file and relinking. I'll upload updated source tarballs and ARM binaries over the weekend.

Once I see that OP has successfully completed the bug-affected run with the updated build and submitted the result I'll ask for an early double-check of the exponent, just to be on the safe side.

Thanks again for the bug report!
Attached Files
File Type: bz2 Mlucas.c.bz2 (74.9 KB, 68 views)

Last fiddled with by ewmayer on 2020-01-18 at 03:57
ewmayer is offline   Reply With Quote
Old 2020-01-18, 21:43   #13
ewmayer
2ω=0
 
ewmayer's Avatar
 
Sep 2002
República de California

263768 Posts
Default

The PRP-residue postprocessing bug reported in post #10 above has been fixed - please grab latest code tarball (or ARM binary for folks running on ARM). If your current build is based on the 3 January code snapshot, my "fixed" Post #3 in the above thread has an incremental single-file-rebuild option.

Update: Coincidentally, a few hours after I uploaded the patched code and posted the above 'fixed' message, my latest haswell-quad PRP test, of an exponent ~96M, completed and hit the very same postprocessing bug. So I sent the above 96M exponent from my run out for an early double-check, which completed yesterday and verified the first-time-test result.

Since no other bugs have been reported in the past month, I am officially pronouncing v19 as the current stable release, several PRP-functionality-related bugs having been turned up and fixed as a result of the last 2 months' shakedown testing. Going to update the README.html page now.

Last fiddled with by ewmayer on 2020-01-28 at 19:37
ewmayer is offline   Reply With Quote
Old 2020-02-06, 00:06   #14
paulunderwood
 
paulunderwood's Avatar
 
Sep 2002
Database er0rr

339410 Posts
Default

I downloaded mlucas19_c2simd for my Odroid N2 and obtained a couple of WR PRP assignments. The assignments end in ",2" but no P-1 performance was indicated in the ".stat" file.

Last fiddled with by paulunderwood on 2020-02-06 at 00:09
paulunderwood is offline   Reply With Quote
Old 2020-02-06, 00:26   #15
ewmayer
2ω=0
 
ewmayer's Avatar
 
Sep 2002
República de California

2×13×443 Posts
Default

Quote:
Originally Posted by paulunderwood View Post
I downloaded mlucas19_c2simd for my Odroid N2 and obtained a couple of WR PRP assignments. The assignments end in ",2" but no P-1 performance was indicated in the ".stat" file.
The readme page notes that the fields related to p-1 testing are ignored by Mlucas. Thinking aloud, Is there a way to tweak the assignment-fetch to request only exponents for which p-1 has been done to the current default depth(s)?
ewmayer is offline   Reply With Quote
Old 2020-02-06, 00:34   #16
paulunderwood
 
paulunderwood's Avatar
 
Sep 2002
Database er0rr

65028 Posts
Default

Quote:
Originally Posted by ewmayer View Post
The readme page notes that the fields related to p-1 testing are ignored by Mlucas. Thinking aloud, Is there a way to tweak the assignment-fetch to request only exponents for which p-1 has been done to the current default depth(s)?
I popped "PFactor=..." into my gpuowl worktodo.txt file (2nd and 3rd lines). I should know soon whether to continue PRP'ing them with Mlucas.

Last fiddled with by paulunderwood on 2020-02-06 at 00:35
paulunderwood is offline   Reply With Quote
Old 2020-02-16, 20:01   #17
ewmayer
2ω=0
 
ewmayer's Avatar
 
Sep 2002
República de California

263768 Posts
Default

Quote:
Originally Posted by paulunderwood View Post
I popped "PFactor=..." into my gpuowl worktodo.txt file (2nd and 3rd lines). I should know soon whether to continue PRP'ing them with Mlucas.
I just did similarly with my latest batch of PRPs to-be-farmed-out to my various devices running Mlucas. I'm planning to add a few lines to the Mlucas readme to detail this, but want to make sure I get the different assignment-line formats for PRP and LL right in this regard. Let's review:

PRP=C57FF1C644A0CB16F5E2B5B3A9FC4E1D,1,2,98024161,-1,77,0 - Trailing '0' indicates p-1 has been done. We only want to do p-1 if trailing digit = 1 or 2, in which case we change PRP to Pfactor and paste the resulting assignment into the worktodo file for Prime95/mprime or gpuOwl. (Does CudaLucas also support p-1? Unfamiliar with it.)

Test=DDD21F2A0B252E499A9F9020E02FE232,48295213,69,0 - Trailing '0' indicates p-1 has *not* been done. How to munge the assignment into a p-1 one?

For DC assignments of either type, the same 2 trailing-digit conventions hold, yes? And if some p-1 was done prior to the first-time test of a given exponent, in preparation for handing out a 2nd time as a DC, does the server ever change the trailing digit from "p-1 has been done" to "p-1 needed" to reflect that deeper p-1 should be done prior to the DC?
ewmayer is offline   Reply With Quote
Old 2020-02-16, 21:31   #18
kriesel
 
kriesel's Avatar
 
"TF79LL86GIMPS96gpu17"
Mar 2017
US midwest

7×631 Posts
Default

Quote:
Originally Posted by ewmayer View Post
Let's review:

PRP=C57FF1C644A0CB16F5E2B5B3A9FC4E1D,1,2,98024161,-1,77,0 - Trailing '0' indicates p-1 has been done. We only want to do p-1 if trailing digit = 1 or 2, in which case we change PRP to Pfactor and paste the resulting assignment into the worktodo file for Prime95/mprime or gpuOwl. (Does CudaLucas also support p-1? Unfamiliar with it.)
No, CUDALucas does LL only, without Jacobi check. If you want CUDA P-1, that would be CUDAPm1, a separate app described by its author as alpha software.
Quote:
Test=DDD21F2A0B252E499A9F9020E02FE232,48295213,69,0 - Trailing '0' indicates p-1 has *not* been done. How to munge the assignment into a p-1 one?

For DC assignments of either type, the same 2 trailing-digit conventions hold, yes? And if some p-1 was done prior to the first-time test of a given exponent, in preparation for handing out a 2nd time as a DC, does the server ever change the trailing digit from "p-1 has been done" to "p-1 needed" to reflect that deeper p-1 should be done prior to the DC?
Requesting a manual or PrimeNet P-1 assignment for the exponent in question will generate the prime95 form of P-1 assignment record with the correct # of tests saved included. Prime95 uses that integer as input to select appropriate bounds to maximize probable testing time saved, as does CUDAPm1.
The reference post for assignment (worktodo entry) format by app, version and type is at https://www.mersenneforum.org/showpo...8&postcount=22
kriesel is online now   Reply With Quote
Old 2020-02-22, 20:52   #19
ewmayer
2ω=0
 
ewmayer's Avatar
 
Sep 2002
República de California

1151810 Posts
Default

Readme has been updated with guidance re. doing preliminary p-1 using one of the GIMPS clients which support it. Ken, thanks for the comments.
ewmayer is offline   Reply With Quote
Old 2020-03-07, 19:43   #20
ewmayer
2ω=0
 
ewmayer's Avatar
 
Sep 2002
República de California

2·13·443 Posts
Default

Ken reports build failure using msys2 under Windows -- "signal issues and real time extensions lib not available."
Code:
ken@condorella MINGW64 ~/mlucas/mlucas_v19/build
$ gcc -c -O3 ../src/*.c >& build.log

ken@condorella MINGW64 ~/mlucas/mlucas_v19/build
$ grep error build.log
../src/fermat_mod_square.c:1842:18: error: 'SIGHUP' undeclared (first use in this function); did you mean 'SIGFPE'?
../src/fermat_mod_square.c:1844:18: error: 'SIGALRM' undeclared (first use in this function); did you mean 'SIGABRT'?
../src/fermat_mod_square.c:1846:18: error: 'SIGUSR1' undeclared (first use in this function); did you mean 'SIG_ERR'?
../src/fermat_mod_square.c:1848:18: error: 'SIGUSR2' undeclared (first use in this function); did you mean 'SIG_ERR'?
../src/mers_mod_square.c:2533:18: error: 'SIGHUP' undeclared (first use in this function); did you mean 'SIGFPE'?
../src/mers_mod_square.c:2535:18: error: 'SIGALRM' undeclared (first use in this function); did you mean 'SIGABRT'?
../src/mers_mod_square.c:2537:18: error: 'SIGUSR1' undeclared (first use in this function); did you mean 'SIG_ERR'?
../src/mers_mod_square.c:2539:18: error: 'SIGUSR2' undeclared (first use in this function); did you mean 'SIG_ERR'?
../src/Mlucas.c:187:21: error: 'SIGHUP' undeclared (first use in this function); did you mean 'SIGFPE'?
../src/Mlucas.c:189:21: error: 'SIGALRM' undeclared (first use in this function); did you mean 'SIGABRT'?
../src/Mlucas.c:191:21: error: 'SIGUSR1' undeclared (first use in this function); did you mean 'SIG_ERR'?
../src/Mlucas.c:193:21: error: 'SIGUSR2' undeclared (first use in this function); did you mean 'SIG_ERR'?

ken@condorella MINGW64 ~/mlucas/mlucas_v19/build
$ gcc -o Mlucas-x86 *.o -lm -lrt
C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/8.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe: cannot find -lrt
collect2.exe: error: ld returned 1 exit status

ken@condorella MINGW64 ~/mlucas/mlucas_v19/build
$ pacman -Su librt
error: target not found: librt

ken@condorella MINGW64 ~/mlucas/mlucas_v19/build
$ pacman -Su rt
error: target not found: rt
Any advice from fellow msys2 users welcome - I no longer have any Win-box to play with this myself.

Ken, which version of Windows, and which precise built-in Linux distro?
ewmayer is offline   Reply With Quote
Old 2020-03-07, 21:04   #21
kriesel
 
kriesel's Avatar
 
"TF79LL86GIMPS96gpu17"
Mar 2017
US midwest

7×631 Posts
Default

The preceding was on msys2/mingw64 (on Windows 7 x64 Pro, as fully patched as I could make it, HP Z600 dual E5645).
I went a few rounds with msys2's pacman implementation which is adapted from Arch Linux from what I've read, searching for the rt library without success. POSSIBLY it's on some mirror somewhere, if it has been ported.

I'm currently updating msys2 and its packages. This is taking a while, since I have a lot running and am frequently getting "Connection timed out after 10030 milliseconds" or similar from pacman.
kriesel is online now   Reply With Quote
Old 2020-03-08, 00:01   #22
kriesel
 
kriesel's Avatar
 
"TF79LL86GIMPS96gpu17"
Mar 2017
US midwest

105018 Posts
Default

"MSYS2 is a software distro and building platform for Windows

At its core, it is an independent rewrite of MSYS, based on modern Cygwin (POSIX compatibility layer) and MinGW-w64 with the aim of better interoperability with native Windows software. It provides a bash shell, Autotools, revision control systems and the like for building native Windows applications using MinGW-w64 toolchains.

It features a package management system, Pacman, to provide easy installation of packages. It brings many powerful features such as dependency resolution and simple complete system upgrades, as well as straight-forward package building." https://www.msys2.org/

Mlucas v17 built ok on msys2, as did v17.1, a year ago. But V19 did not, this week, partly because it requires linking to the real time extensions library librt. https://docs.oracle.com/cd/E36784_01...ibrt-3lib.html

But there is no librt in msys2's package list. https://github.com/msys2/MSYS2-packages https://packages.msys2.org/search?t=pkg&q=rt
And there's no libc listed either.

And v18 didn't go so well either, today, on msys2, after a full update of msys2.
Code:
ken@condorella MINGW64 ~/mlucas/mlucas_v18/build
$ grep error build.log
../src/fermat_mod_square.c:1869:18: error: 'SIGHUP' undeclared (first use in this function)
../src/mers_mod_square.c:2382:18: error: 'SIGHUP' undeclared (first use in this function)
../src/Mlucas.c:182:21: error: 'SIGHUP' undeclared (first use in this function)

ken@condorella MINGW64 ~/mlucas/mlucas_v18/build
$ gcc -o Mlucas-x86 *.o -lm -lrt
C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/9.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe: cannot find -lrt
collect2.exe: error: ld returned 1 exit status

Last fiddled with by kriesel on 2020-03-08 at 00:03
kriesel is online now   Reply With Quote
Reply

Thread Tools


Similar Threads
Thread Thread Starter Forum Replies Last Post
Mlucas v18 available ewmayer Mlucas 48 2019-11-28 02:53
Mlucas version 17.1 ewmayer Mlucas 96 2019-10-16 12:55
MLucas on IBM Mainframe Lorenzo Mlucas 52 2016-03-13 08:45
Mlucas on Sparc - Unregistered Mlucas 0 2009-10-27 20:35
mlucas on sun delta_t Mlucas 14 2007-10-04 05:45

All times are UTC. The time now is 02:28.

Tue Sep 22 02:28:30 UTC 2020 up 11 days, 23:39, 0 users, load averages: 1.59, 1.51, 1.57

Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2020, Jelsoft Enterprises Ltd.

This forum has received and complied with 0 (zero) government requests for information.

Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.2 or any later version published by the Free Software Foundation.
A copy of the license is included in the FAQ.