-u username -p passwordIf you have a GPU, the doGPU.pl script can be used by doWork.pl to run mfaktc or mfakto, but only versions of those programs that I have modified to specify tasks on the command line rather than in a worktodo.ini file. I am currently trying to get my changes to mfaktc and mfakto accepted by their developers, but that's been a very slow process for many reasons. Without a GPU, the mersfacgmp program will be used, which is likely too slow for current GIMPS trial factoring tasks to help much. The primary purpose of this package is for my own use, to try to factor smaller Mersenne numbers, rather than help GIMPS find new Mersenne primes. The primary program for that is the Linux 'ecm' program, which can do the P-1 and P+1 methods, including creating save files for later runs, as well as ECM factoring. The other essential script for my own use is now mersServer.pl, added in 2020, which tracks the status of the factoring efforts and accepts connections from doWork.pl on other computers to ask for tasks and report results. Unfortunately, I do not currently have an IP address that can be seen on the Internet as a whole, so I can't provide access to my server but intend to do so in the future, perhaps thru Sourceforge. The installation section below is now incorrect in that:
% make install... is now supported and will install the programs and scripts in the parent directory ('..') of the current directory.
If you want to try to factor Mersenne numbers, you will have to make do with the full instructions below; there are too many possibilities and a couple of other libraries that are likely needed.
Further, you should read the top of the makefile (or Makefile.nofac, if you use it); there are several kinds of computers that will run the programs faster if they are compiled slightly differently as noted in the makefile.
But, if all you want to do is look for Mersenne Primes using the Lucas-Lehmer test, are willing to wait years, perhaps, for a single result, you have a list of exponents to test from the Manual Testing web page and you have unpacked the tar or zip file that the mers package comes in, then it's likely that all you need to do is:
% make -f Makefile.nofacand wait for it to compile and test the Lucas-Lehmer testers (fftlucas, mersenne1, mersenne2, and MacLucasUNIX).
% make >& make.output(give any other arguments to make that you want right after "make"). If that complains about a "null redirect" or similar, then you're using a Bourne (sh) or compatible shell and it wants something like:
% make > make.output 2>&1to do the same thing (put stdout and stderr in the same file). Then, after the make completes, email me the file. On most UNIX machines that have email to the Internet:
% mail wedgingt@acm.org < make.outputwill do it. The contents of make.output may not have everything I need to solve the problems, but it should tell me what questions to ask you to get the info I need from your computer.
Since I presently only have access to Ubuntu Linux and MSWindows10 with Cygwin for testing this package, I have to rely on others to test the package on other platforms and send me back changes, guesses at things to try, or at least the error messages. Further, note that George Woltman's programs run much faster on nearly all Intel platforms, including Intel Linux, FreeBSD, NT, Microsoft Windows, etc. Further, John Sweeney has taken many of the ideas from George's code and produced a C language version for Macintosh PowerPC systems (the binary of which is also on George's web page just above); it too appears to be faster than this package's programs on the same hardware. With help from several other people, I have ported John Sweeney's code back to UNIX and it seems to run correctly on several UNIX variants, including Linux, SunOS, SGIs, and IBMs with PowerPC CPUs, so it is now included in this package as MacLucasUNIX. Also, Ernst Mayer has written a Fortran90 program for doing Lucas-Lehmer tests, so, if you have a Fortran90 compiler, that's probably going to be faster than mersenne1 - but perhaps not MacLucasUNIX - of this package. See the mers project on Sourceforge for more and links to others with much more information on these other programs and how to get them.
The other README files (README.fftlucas and README.mersenne1) were originally comments at the top of their respective .c files; they are now very out-of-date and are only retained to show each program's origins, references, and so on. In fact, none of the usage information that was in those files in prior releases was accurate; it's now been deleted entirely to prevent further confusion.
None of the "guts" (calculations-related code) of these programs (with the exception of extract) originated with me; my changes have all been to improve usability and portability, to take advantage of "long double" or "long long" if they're available, define the details of the checkpoint formats, and similar things.
Almost all of the programs of the package that do extensive calculations call setup.c's setup() function, which reduces the priority as low as I know how to lower it so that other programs are always preferred by the CPU. Setup() also sets some signal handlers so that a SIGTERM (terminate, usually 15; sent by the usual UNIX shutdown command), a SIGINT (interrupt, usually 2; often control-C), or a SIGHUP (hangup, usually 1; often sent by logging out) tells the program to save what it's doing and exit as soon as possible.
The libgmp library is also now available as a package for most Linux distributions.
GCD(2^a - 1, 2^b - 1) = 2^GCD(a, b) - 1For example, a prime exponent Mersenne number is a factor of all Mersenne numbers whose exponent is a multiple of that prime. Second:
M(2*n) = 2^(2*n) - 1 = (2^n)^2 - 1^2 = (2^n - 1)*(2^n + 1)
= M(n)*(M(n) + 2)
So the mers package programs will thus only print factors of M(n) + 2
for M(2*n). Third:
M(4*n - 2) + 2 = 2^(4*n - 2) + 1 = (2^(2*n - 1) - 2^n + 1) *(2^(2*n - 1) + 2^n + 1) So L and M are defined as: L = 2^(2*n - 1) - 2^n + 1 M = 2^(2*n - 1) + 2^n + 1and the programs and scripts try to factor both of them whenever it is given a Mersenne exponent that is an odd multiple of 4.
The Mersenne.pm Perl module pulls all of these "predictable" factors out before trying factor what remains. See the description of the "mers format" for more details and my mersenne web page for some related proofs.
% mv -i Makefile Makefile.fac % mv -i Makefile.nofac Makefile... before running "make" or using:
% make -f Makefile.nofac... instead of just 'make'.
Mersfacint does not require libgmp.a, but Makefile.nofac does not try to compile it.
Otherwise, the installation will likely consist of simply typing "make install" to your shell and waiting for the package to compile and test itself; exceptions are noted below. The package was well tested under SunOS 4.x and 5.x, (RedHat) Linux, HPUX, DEC Ultrix, DEC Alpha OSF, SGI Irix 5.x, and probably others I'm forgetting at the moment; only SunOS 5.x and SGIs using cc presently need Makefile edits, though HPUX and DEC machines benefit from different optimization options. SGIs running Irix 6.x are reported to have problems; please let me know if you do not have problems there or if you can solve them.
If your computer has a 'long double' type with one compiler (say, the FSF's gcc) but not with a different compiler (say, the cc that came with the operating system), using the compiler that has 'long double' should result in substantially faster Lucas-Lehmer test programs, since the FFT run length can often be reduced due to the greater floating point precision.
Extract is reported to compile fine using djgpp on Win/NT 4.0.
Compilation has been at least attempted under OpenVMS on DEC Alphas.
Support for the Amiga has improved, but a gcc compiler problem there is currently stalling further progress, though I have heard nothing on this since the v2.7.2.1 release of gcc.
The usual format read and written by both rw.c and most of the others is documented in mersfmt.txt.
By default, most programs except extract read from stdin and write to stdout. Extract defaults to reading George Woltman's DATABASE file and printing a human-readable copy of it on stdout. Most programs treat arguments that do not start with a "-" as filenames or, if positive integers that do not name files, exponents. "-" by itself means read stdin now rather than not at all or - if no other file arguments are given - only after all other arguments are processed. The usage information for programs that use rw.c's input() is briefly described near the top of rw.c itself and will be printed as part of most error messages related to incorrect usage. Somewhat longer descriptions of options for all of the programs:
-a For trial factoring only, do not stop on finding the first
factor; keep looking for more. Mmtrial and merskfac always
behave this way. Otherwise, it is not the default for
programs using rw.c's input().
-b For the Lucas-Lehmer test programs, use a (much faster) binary
checkpoint format that is not portable between machines nor
useful via TCP/IP (default).
-c # Create a new checkpoint after every # iterations
(Lucas-Lehmer testers only). Any value less than
5000 will be treated as 5000. Overrides the
FFTLUCAS_CHECKPOINT environment variable, which can also be
used to set this checkpoint interval. Default is no
checkpointing at all.
-d Duplicate the normal output to stderr. Mostly so that "-d -n"
will print the results locally as well as sending them to the
server. Can also be given as "-d-", "-d -", "-dstderr", "-d
stderr", or, to write to stdout, "-dstdout" or "-d stdout",
or, to write to a particular file, "-dfilename" or "-d
filename". Note that "-d -n", e.g. will be treated the same
as "-dstderr -n". Default is to not duplicate the output.
This will never truncate a file; it always appends.
-D For sprpgmp only, print any pseudo-prime (but not proven prime)
cofactors.
-e # For programs that use rw.c's input(), gives the power of two
at which trial factoring should stop. As a special case,
'-e 1' will factor from the prior extent past the next higher
power of two. The default is to do the number of trials given
by -m.
-h For programs that call rw.c's input(), use the human readable
checkpoint format, which is portable between computers with
the same length of double (or long double) and can be sent
over TCP/IP. This option is only valid with fftlucas; using
it with any of the other LL testers will print an error and
exit to avoid a problem with human readable checkpoint round
off errors.
-h For contract, print a brief help message and exit.
-i For contract, specify the file to read from.
-m # For trial factoring only, check # (more) possible trial
factors (values of k in 2*k*p + 1). Default is one sieve pass
(which itself defaults to about 98,000 trials, quite small).
This can also be specified in the input with a line like
"trials 98000", which all programs using rw.c's input() know
about and, if not a trial factorer, skip and ignore. In the
-n (TCP/IP) case, the server uses "trials #" lines to control
how long the client runs without interaction.
-o For programs that use rw.c's input(), -o is like -d, but for
the "primary" output rather than the duplicate output, but
this defaults to stdout, including when used like "-o-" and
"-o -". This always appends, never truncates.
-o For contract, specify the output file, but "-o-" will create
a file named "-" and "-ostdout" will create a file named
"stdout" (e.g.).
-r # # For extract, and programs that use rw.c's input(), limit all
testing to exponents between or equal to the two numbers
given. Data for exponents outside the range will be read
correctly and ignored. This also applies to input from the
server via -n; the range is reported to the server on
connecting to it.
-s For trial factoring, do a "small" number of trial factors
for each exponent (this is mostly for the tests in the
Makefile). The number of trials is presently one sieve
pass, presently 98,304 trials if the sieve array's size
is not changed from the distribution value of 4096.
-t Print (real or "wall clock") time information to stderr. If
you have getrusage() and #define USE_RUSAGE, the user and
system CPU times will also be printed; see below in the
Makefile section for how to do this.
-u For contract, ignore information for Mersenne numbers
of known primality (that is, for composite exponents or for
which a factor or LL test residue is known).
-v Print some version information. Other arguments are processed
normally; this does not cause an exit. The version info is
always sent to the server when connecting to it if the -n flag
is given.
-v For contract, increment the verbosity of the output to the
user (counts of exponents, e.g.).
-1, -2, -3, -4, -m
For extract only, indicates how many columns to use when
printing the data from the DATABASE file. The first three,
-1, -2, and -3, will print the exponent, the power of two
indicating the extent of factoring (if -2 or -3), and the flag
indicating how many Lucas-Lehmer tests have already been
performed (-3), separated by commas. -4 and -m print the same
info as -3, but in the "mers format" that I developed on my own
before GIMPS was formed: "M( exponent )[UH]: extent". Nearly
all of the programs will now read the -1, -2, -4, and -m
output formats of extract.
Unknown arguments starting with "-" cause error and usage messages to
be printed and the program to exit, except in the cases of extract,
which simply prints a warning and continues with the next argument,
and contract, which ignores them completely. Contract prints a usage
message and exits if any argument does not start with a "-". If FFTLUCAS_CHECKPOINT is in the environment, it is taken to be the number of iterations between writing checkpoint files by the LL test programs (fftlucas, mersenne1, mersenne2, and MacLucasUNIX); it is checked once before all arguments, so a -c command line option will override any value in the environment.
The checkpoint file names are hard-wired to "#", "c#", and "t#" (without the quotes) where # is the exponent being LL-tested. The LL test programs only write to "c#", renaming the prior "c#" to "t#" each time.
The LL test programs (MacLucas*, mersenne1 & 2, and fftlucas) can, of course, read checkpoint files produced by any of the four programs, even binary ones from stdin (as long as any binary checkpoint was produced on a computer of the same architecture).
None of the programs can test an exponent below 31, but all Mersenne numbers with an exponent less than 787 are completely factored anyway, so this limit of 31 may increase in the future. Most of the programs can check any odd exponent Mersenne, but only prime exponent Mersennes can themselves be prime and composite exponent Mersennes have factors that the trial factorers will not check for.
Mersfacint does not run at all if it cannot find a native 64 bit integer type (usually 'long' (DEC Alphas, e.g.) or 'long long' (Intel Linux)).
Other than those that start with "-", extract treats all arguments as file names to open. If the last component (everything after the last "/") of the filename is "DATABASE" or "database", extract assumes it is a copy of George Woltman's old, no longer created by him, DATABASE file and prints it out in a human-readable power-of-2 format documented in mersfmt.txt that can be read by most of the programs. Other arguments are checked to see if they look like checkpoint filenames; if they do, the files are opened and the exponent, FFT run length, and iteration count are read and printed (plus the rest of the first line if it's a human-readable file) to stdout. If they don't look like checkpoint filenames, a warning is printed and extract starts over with the next argument. All lines, except for a DATABASE file, are prefixed by the appropriate filename.
% make DEFINE=-DTCPIPIf you have getrusage(), adding -DUSE_RUSAGE will print user and system CPU times along with the wall clock time given -t.
For SunOS 5.x (commonly mis-called Solaris, which technically applies to SunOS 4.x as well), see the top of the Makefile for some small editing you need to do before compiling. Or compile using:
% make DEFINE=-DSOLARISor:
% make DEFINE="-DSOLARIS -DTCPIP"if you also want TCPIP support.
For SGI's, setup() calls the SGI-specific function "schedctl(NDPRI, 0, NDPLOMIN)" to reduce the priority as low as possible, completely out of competition with normal programs. If similar things are present in other operating systems, please let me know.
On any computer, look for "OPT" to check the optimization, debugging, and profiling options to gcc or cc. In particular, I'm told that a couple of additional optimizer options will improve the speed by 20-30% under HPUX, different ones will give a 40% or so improvement for some AIX machines, and gcc on SGI's wants to know the exact CPU type; see the Makefile for details.
Also, "make TIME=time" will use the UNIX time program to run the tests to give you an idea of how long they take.
Please, as always, send any comments, questions, bug reports, bug fixes, code suggestions, etc. to me. Please include version numbers of the relevant files, at least of the file with main() in it or of this README.html file. See above for details on a simple way to email me the output from make.
Will Edgington wedgingt@acm.org (permanent) wedgingt@gmail.com Version $Id: README.html,v 8.1 2007/06/23 22:33:35 wedgingt Exp $