Mersenne Digest Saturday, September 25 1999 Volume 01 : Number 632 ---------------------------------------------------------------------- Date: Fri, 24 Sep 1999 18:40:48 +0300 From: Jukka Santala <[EMAIL PROTECTED]> Subject: Re: Mersenne: Front-end design Robert van der Peijl wrote: > Now, everybody, _PLEASE_: > If you're thinking <<How about a nifty gadget such-and-such?>>. > Let's NOT send all THAT to the mailing list! > The list would get swamped in tons of traffic. So please, okay? Though you ask this, I find the topic rather appropriate for the list, especially given the angle of "HOW can we visualize the process of mathemathical operations?". So, unless somebody comes up with a better avenue for discussing it, or threatens me with a hammer, I'll take my best shot... It's _not_ a call for discussion of every little knob and letter in the proposed GUI, though! Actually, the main reason I do is because there's something I've been for long hoping from the "distributed computing" projects, in vain... Something so obivious and simple I'm wondering why it hasn't already been included, if it's just me or... Oh well ;) Anyway, rather than keep you all in suspense, which sounds tempting too, I'll just tell it since I'm dying to see this one out there: How about a grpah of how much CPU-time the calculations are taking? One of the strongest drawbacks to the various distributed computing projects is that there's simply no way to know how much CPU your "real work" is takng at any given time, it's just 100% CPU utilization all the time. This is pretty dumb, especially when you have a program running that seems to know just how much spare time there is in the system at any given time. Now, for the Unix client there's a real problem here. Yes, I agree the main client should be a console application. I'm wondering if it's possible to build an executable that runs both console and X, though..? The big problem is that we don't have enough data outside of the program to draw almost any graphics... getting the structure-definitions of the intermediary files could be a good start, though. Other suggestions for graphics: (Comments in private, though, preferably, if there's anything new coming out I can post summaries). I'd work on this myself if I had the time and source, being I don't... - - progress bars like "Go!Zilla", using various bitmaps that are slowly revealed. Images related to computer & math theory would be preferred. - - comparements to "worst competitors" on the CPU-years category etc, preferably with runnign real-time stats, which brings us to... - - simple chat system. With the Internet connectivity routines already in place, allowing chatting with other people running the Prime95/mprime client shouldn't be much of a chore. - - for checking large Mersenne numbers, I think the only kind of "status display" really making sense would be a multi-color graph of the status of the full Mersenne search. Many of these suggestions seem to also require changes to the existing PrimeNet server, or even a new server to take off some of the "non-essential chores" like the competitors & world check status displays, which is another reason why I think this can't be just brainstormed in private, disconnected from all the rest of the GIMPS effort, like we were operating in a vacuum. -Donwulff _________________________________________________________________ Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers ------------------------------ Date: Fri, 24 Sep 1999 17:56:05 +0200 From: "Steinar H. Gunderson" <[EMAIL PROTECTED]> Subject: Mersenne: Re: Linux error 2250 (was Front-end design) On Thu, Sep 23, 1999 at 05:45:39PM -0400, George Woltman wrote: >>Incidentally, can anyone explain why under v19.0.2 I'm getting "ERROR 2250: >>Server unavailable" messages? >Someone told me that glibc-2.1 (as compared to v18's libc5) uses different >files or network setup or something. I am a Linux know-nothing, so perhaps >a list member can enlighten all of us. Please give us some more debug info, then :-) What does error 2250 provoke? This sure doesn't come from glibc, but from the PrimeNet code. The problem is finding out what provokes this error. (Hint: give us the content of the variable `errno' and let's see what we can find :-) ) /* Steinar */ - -- Homepage: http://members.xoom.com/sneeze/ _________________________________________________________________ Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers ------------------------------ Date: Fri, 24 Sep 1999 17:57:48 +0200 From: "Steinar H. Gunderson" <[EMAIL PROTECTED]> Subject: Mersenne: Re: Conflict with Windows Schedule agent? On Thu, Sep 23, 1999 at 06:52:40PM -0400, Jud McCranie wrote: >The only >thing (other than the regular system stuff) that I have running is >Prime95. Any ideas? Try to turn off Prime95 and then retest, OK? :-) It's not easy to say if Prime95 is the problem, without trying without it. /* Steinar */ - -- Homepage: http://members.xoom.com/sneeze/ _________________________________________________________________ Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers ------------------------------ Date: Fri, 24 Sep 1999 18:09:54 +0100 From: Tony Forbes <[EMAIL PROTECTED]> Subject: Re: Mersenne: Important info on M(M(p)) from Wilfrid Keller Lucas Wiman <[EMAIL PROTECTED]> writes >[...] >> when I found out than Curt Noll had started an attack on M(M(127)) with >> superior hardware. I imagine that by now he has carried the search much >> further. > >This is further evidence for why GIMPS is such a good idea! (as if we >needed more) Well, yes ... but in practice when you work on a problem with considerably more powerful hardware than has previously been applied to it, there is little cost in starting again from scratch, and it double- checks the work that has already been done. >If Curt Noll and you have been working together, your computer time would >not have been wasted, nor would (presumably) much of his. This is the >beauty of distributed computing projects, but this illistrates how *key* >centrilization is. Of course, soon after Curt started working on M_M_127 I collaborated with him - by retiring! >Now, I think that it might be a nifty (tm) idea if GIMPS/primenet >were to start looking for factors of double Mersenne numbers. If I >understand correctly, much of the code is already written (changes to >the P-1 code, and the normal factoring code), and I'm sure that such things >could interest mathematicians more than finding the next Mersenne prime. The only feasible approach for M_M_61 and above is trial-division. I recently blew the dust off by my program MFAC and gave it a run. For M_M_61 it processes divisors N*M_61 + 1 on an AMD/400 at about 2.2 billion N's per hour. (6 billion/hour for M_M_31.) If people are interested, and unless someone else can do better, after a bit of tidying up I can make this program available. Then we need a mechanism for handing out work. I am happy to volunteer, but it will have to be done manually. - -- Tony _________________________________________________________________ Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers ------------------------------ Date: Fri, 24 Sep 1999 19:00:07 +0100 From: "Brian J. Beesley" <[EMAIL PROTECTED]> Subject: Re: Mersenne: Front-end design On 23 Sep 99, at 16:18, Robin Stevens wrote: > > > There are some Linux folks that like the present program because it > > > doesn't use X-windows. > > I certainly do! A program like mprime that is supposed to run in > > background at all times should not depend on a X server running. > > Quite. For a start, some of the servers on which I have mprime running > don't have an X server. I'm not always logged into them That's enough of a reason to convince me. Also, running X on a system increases substantially the memory requirements of a system and its need for either substantial backing store or fast network support. As it is, a linux mprime client / room warmer (without X) is happy with a 170 MB disk (practically free from the junkyard). 16 MB of RAM is adequate, 32 MB is comfortable & 64 MB is overkill. You may have noticed that SDRAM prices had already doubled in a month even _before_ the Taiwan earthquake - which, one suspects, will not improve the supply situation - so the extra 16 MB of RAM you _really need_ to run X is going to cost you something of the order of $25. And you need a graphics card to run X, too - my linux mprime client doesn't contain one! Regards Brian Beesley _________________________________________________________________ Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers ------------------------------ Date: Fri, 24 Sep 1999 14:22:06 EDT From: [EMAIL PROTECTED] Subject: Mersenne: Mlucas 2.7x on SPARC Alex Kruppa has done some SPARC timings of Mlucas 2.7x compiled using the newish SPARC f90 v2 compiler, which appears to be much better than v1. (At last, 64-bit loads and stores - hooray! Seems ridiculous for such a thing to be worth cheering about, but like I said, v1 was *really* bad.) He writes: << I've got a binary that needs 0.183 secs / iteration with the 256K array size now. Seems the Fortran section of Sun Compilers borrowed a few smart guys from the C section. :) Mlucas_2.7x on a UltraSparc II 300 Mhz is almost as fast as on a 400 Mhz Alpha 21164. >> Hi, Alex, and many thanks for the timings. That sounds promising - note that the latest README file has a complete set of timing/accuracy tests for cases from 64-4096K. << I tried all sorts of compiler flags - unfortunately, the optimization flags are not linear, especially -O5 tends to produce much slower code than -O4 when combined with other flags. >> I see similar weird slowdowns using the -O5 compile option on some (not all) Alpha CPUs (generally the older ones.) I wonder if both compilers are doing similar "optimizations" at -O5. << I'm using -fast -libmil -xlibmopt -fnsyes now, which seems to give close to optimal performance. >> As long as it correctly runs the self-tests, faster is better. Note that a few of the self-tests will give some roundoff warnings, especially if the compiler in question doesn't support extended-precision floats, used (when available) by Mlucas for sincos and DWT weights tables initializations. << I dont know whether this is also optimal on other types of UltraSparc, I only have Ultra60s for testing. >> Let me know where I can ftp the binary, and I suspect we'll soon get lots more SPARC timings - it's a popular Unix platform. Thanks, Ernst _________________________________________________________________ Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers ------------------------------ Date: Fri, 24 Sep 1999 20:03:42 +0100 From: "Brian J. Beesley" <[EMAIL PROTECTED]> Subject: Re: Mersenne: Front-end design On 24 Sep 99, at 18:40, Jukka Santala wrote: > Yes, I agree the main client should be a console application. I'm with you on that ... > I'm wondering if it's > possible to build an executable that runs both console and X, though..? Why would you _want_ to do that? (See below...) > The big problem is that we don't have enough data outside of the program > to draw almost any graphics... _This_ is the problem. What needs to be agreed is the data which the "main client" should make available to any graphics front-end, and any control information to be fed back in the opposite direction. Having done that, the main client just (optionally) outputs data as required to a virtual device (possibly just a shared memory block) for the front end to use, and monitors the controls for any change needing action. This need not be any heavier than the action of the current Prime95 client, or mprime run with the -d switch, writing the iteration data to the (virtual) console. Actually the NT service client, NTPrime, already does something similar to this (in a more limited way - but the ideas are the same). It uses an independent program (NTSetup) to control PrimeNet settings, local options, etc., however it just so happens that NTSetup is built to look similar to the Prime95 front end. The point here is that doing it this way means that the clients can use a common message block specification, so the GUI can be written by somebody who doesn't need to know the intimate details of the client - the message block specification is enough to work from. This allows X & Windoze hackers to roll their own fancy GUI without needing to be able to compile the whole client - making infinite variety of presentation possible, without losing control over the client code. (We _need_ that control for reasons of maintaining faith in the integrity of the results we are producing). Regards Brian Beesley _________________________________________________________________ Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers ------------------------------ Date: Fri, 24 Sep 1999 15:03:29 EDT From: [EMAIL PROTECTED] Subject: Mersenne: Mlucas 2.7: accuracy David Willmore writes: <<Oh, you're having a bad day, now: mars-test> cat p02608007.stat M( 2608007 ): using an FFT length of 131072 this gives an average 19.8975143432617 bits per digit M 2608007 Roundoff warning on iteration 995 maxerr = 0.406250000000 ... M 2608007 Roundoff warning on iteration 46031 maxerr = 0.437500000000 M 2608007 Roundoff warning on iteration 46042 maxerr = 0.500000000000 FATAL ERROR...Halting execution. >> Hi, David - Yep, it looks a like I better set s.t. like 2.6M as the upper limit for 128K. v2.7 gives away a bit of accuracy for the sake of speed. Right now, your only option is to run from scratch using v2.6c (as long as it's the first exponent in the range file, the run should be OK), or (what may be faster) use 2.7x at 160K, e.g. by explicitly listing the run length in interactive mode - delete or rename the worktodo.ini file and enter s.t. like Mlucas <== perhaps add output redirection on this line... 2608007,163840 <return> <return> You can redirect the output to a file and use crtl-Z and bg to restart the job in background mode, allowing you to log out. I'm working on adding some kind of automated error detection/FFT length resetting to the next release, but it adds a lot of program logic and hence takes time to do - I didn't want to wait for that before releasing a beta version. Thanks for the info - keep those bug/problem reports coming. - -Ernst _________________________________________________________________ Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers ------------------------------ Date: Fri, 24 Sep 1999 20:49:29 +0200 From: "Steinar H. Gunderson" <[EMAIL PROTECTED]> Subject: Mersenne: Iteration meter (hooray, a GUI!) - --YZ5djTAD1cGYuMQK Content-Type: text/plain; charset=us-ascii Linux folks, Here's my small GUI program. It uses the framebuffer device to produce a graph of the iteration time (ie. lower is better). It assumes a couple of things: 1. You already have framebuffer set up. 2. You're running mprime v19. 3. You know what you're doing. (Don't come running to me if you need help compiling, setting up your framebuffer device etc.) 4. Your fb device is using 32 bpp (NOT 24, 16, or 8 bpp...) 5. You like weird colours. Run (after compilation): ./mprime -d | itermeter Every time mprime would normally output a line, a flashy bar comes up. If your X resolution is the same as your fb resolution (and if you run 32 bpp in X), try switching to X for a bit of a weird effect :-) Don't expect this to ever be ready for a general release. It's just a piece of crap that I smacked together in 10-15 minutes. (Hope nobody minds about my 3K-attachment -- the file wasn't that big, so I didn't bother to FTP upload it etc.) /* Steinar */ - -- Homepage: http://members.xoom.com/sneeze/ - --YZ5djTAD1cGYuMQK Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="itermeter.c" /* * made by Sesse 24.9.99 * no copyrights as of current -- have fun */ #include <sys/mman.h> #include <fcntl.h> #include <unistd.h> #include <stdio.h> /* w/h = actual width/height */ /* fw = virtual width */ /* fbdev = framebuffer device */ #define w 800 #define fw 1024 #define h 600 #define fbdev "/dev/fb0" void main(void) { int fd = open(fbdev, O_RDWR); int i = 16; char *buf = mmap(NULL, fw*h*4, PROT_READ|PROT_WRITE, MAP_SHARED, fd, 0); float max = 1.0f; memset(buf, 0, fw*h*4); while (!(feof(stdin))) { int ijunk; float fjunk, iter_time; int y, x, p; float barheight; scanf("Iteration: %d / %d [%f%%]. Per iteration time: %f sec. (%d clocks)", &ijunk, &ijunk, &fjunk, &iter_time, &ijunk); do {} while (getchar() != '\n'); if (iter_time > max) iter_time = max; barheight = (float)iter_time/(float)(max)*(float)(h-32); p = 0; for (y = h-16; y > h-16-barheight; y--) { int rcomp = 0, gcomp = 0, bcomp = 0; float val = (float)(++p) / barheight; /* 0/4: 100% red */ /* 1/4: 50/50 red/green */ /* 2/4: 100% green */ /* 3/4: 50/50 green/blue */ /* 4/4: 100% blue */ if (val < 0.5f) { rcomp = 255 - (val * 512.0f); } if ((val > 0.25f) && (val < 0.5f)) { gcomp = (val - 0.25f) * 1024.0f; } if ((val > 0.5f) && (val < 0.75f)) { gcomp = 255 - ((val - 0.5f) * 1024.0f); } if (val > 0.5f) { bcomp = (val - 0.5f) * 512.0f; } buf[4*fw*y + 4*i] = buf[4*fw*y + 4*i + 1] = buf[4*fw*y + 4*i + 2] = buf[4*fw*y + 4*(i+16)] = buf[4*fw*y + 4*(i+16) + 1] = buf[4*fw*y + 4*(i+16) + 2] = 0xff; buf[4*fw*y + 3] = buf[4*fw*y + 4*(i+16) + 3] = 0; for (x = i+1; x < i+16; x++) { buf[4*fw*y + 4*x ] = bcomp; buf[4*fw*y + 4*x + 1] = gcomp; buf[4*fw*y + 4*x + 2] = rcomp; buf[4*fw*y + 4*x + 3] = 0; } } /* draw vertical top line */ memset(buf + 4*fw*(h-16-(int)barheight) + 4*i, 0xff, 64); i %= w-34; i += 16; } close(fd); } - --YZ5djTAD1cGYuMQK-- _________________________________________________________________ Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers ------------------------------ Date: Fri, 24 Sep 1999 16:48:33 -0400 From: George Woltman <[EMAIL PROTECTED]> Subject: Mersenne: V19 source code Hi, At 05:27 PM 9/23/99 +0100, Chris Jefferson wrote: >Where can I get the most recent Prime95 source code from? I've just uploaded the v19 source code. You can download it from http://www.mersenne.org/source.htm The only restriction I've placed on the code is that if you use it to find Mersenne primes, you must adhere to the GIMPS prize rules at http://www.mersenne.org/prize.htm The v19 code is much more usable in other math projects. It would be interesting to see if it could be adapted to Proth prime searching (and whether it is enough faster to be worth the effort) or some other new number theory projects. Regards, George _________________________________________________________________ Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers ------------------------------ Date: Fri, 24 Sep 1999 17:13:46 -0400 (EDT) From: Lucas Wiman <[EMAIL PROTECTED]> Subject: Re: Mersenne: Important info on M(M(p)) from Wilfrid Keller > >Now, I think that it might be a nifty (tm) idea if GIMPS/primenet > >were to start looking for factors of double Mersenne numbers. If I > >understand correctly, much of the code is already written (changes to > >the P-1 code, and the normal factoring code), and I'm sure that such things > >could interest mathematicians more than finding the next Mersenne prime. > > The only feasible approach for M_M_61 and above is trial-division. I I was speaking about using part of the P-1 code to speed up trial factoring for the larger exponents (though, of course an FFT multiply is included in the LL code, but I don't think they are the same one (P-1 has to n*m, whereas LL has to by n*n)) > recently blew the dust off by my program MFAC and gave it a run. For > M_M_61 it processes divisors N*M_61 + 1 on an AMD/400 at about 2.2 > billion N's per hour. (6 billion/hour for M_M_31.) If people are > interested, and unless someone else can do better, after a bit of > tidying up I can make this program available. Q: Is this program in ANSI C? It would probably be a good idea to do so if not, as this would attract UNIX users... - -Lucas _________________________________________________________________ Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers ------------------------------ Date: Fri, 24 Sep 1999 17:58:20 -0400 (EDT) From: Lucas Wiman <[EMAIL PROTECTED]> Subject: Mersenne: trial factoring using P-1's GCD I've been wondering about this lately... If we are to begin P-1 testing on larger exponents, this implies lower trial factoring limits (though possibly only by 1 or 2 bits). Now, P-1 requires an investment of a GCD on two numbers each of similar size to Mn. So, since we are investing this much (computational) engery in a GCD, why not cram in as many factors as we can? Would it be possible to find multiply the (a^q-1) mod Mn by small (possible) factors skipped due to the lower factoring bounds faster than it would to directly check these possible factors? Gack, that was a bit unclear, say that k*n+1 divides Mn, k is non-B1-smooth. Which would take more time, checking (directly) to see if k*n+1 divides Mn, or multiplying (a^q-1) by k*n+1? (assuming k*n+1 is around 64 bits) Lucas _________________________________________________________________ Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers ------------------------------ Date: Fri, 24 Sep 1999 16:02:22 -0700 From: "John R Pierce" <[EMAIL PROTECTED]> Subject: Re: Decamega Tests (was: RE: Mersenne: GIMPS client output) > Sounds like loop unrolling is what you're talking about. Most modern compilers (try > to) do this already automatically. However, I've experimented on different variations > of this with the Linux source to, I think, v16 or so, where it seemed possible to > attain small benefits from various variations of look-unrolling. The biggest problem > here is that the number of iterations isn't divisible by any fixed amount. Because of > that the last few iterations need to be done "manually" outside the unrolled block. > The main advantage of such unrolling comes from not needing to check for the number > of timed events present in Prime95/mprime between each iteration - due to cache > considerations actually copying the whole FFT code out as many times as needed > instead of just using calls to it is probably even worse. There's another trick to this, primarily useful in assembler not C programming... Say you unroll something 16 times.... Take teh actual iteration count modulo 16, and JMP into the loop at that offset to start with the repeat counter set to the count/16. i.e. if you need to do, say, 60 iterations of the inner code, thats 48 + 12, so you set the loop count to 3, and jump to the 4th block of the 16 (16-12 = 4) Anyways, prime95 is HEAVILY unrolled, using assembler macros to generate the inline linear inner 'loops'. - -jrp _________________________________________________________________ Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers ------------------------------ Date: Fri, 24 Sep 1999 16:24:11 -0700 From: Will Edgington <[EMAIL PROTECTED]> Subject: Mersenne: Factors Everywhere Eric Hahn writes: [I've already replied in detail to Eric privately.] I've come up with this SWAHBI (like a SWAG, but an idea instead of a guess). Hm, "silly, wild *ssed, half-baked idea" ? That's not an acronym I've seen before.:) What I'm looking for is the following two items for *all* Mersenne numbers 2^p-1 where p is prime and p>1: 1) All known factors (including, but not limited to, the smallest known factor (noted if it isn't)) My data contains some prime exponents with as many as eight known prime factors. 2) Largest potential factor attempted I have this as well, but there are also some gaps in the trial factoring efforts to date, which I also keep track of and try to close. I ask that the two items are human-readable at the very least. The format I use is described in the mersfmt.txt file; it is human readable, being primarily alphanumeric plus parentheses and colon (:). Conversion to just about any other printable format is easy; UNIX has lots of tools that allow this sort of text manipulation. I've pulled a couple of files off mersenne.org (FACTORS.ZIP and NOFACTOR.ZIP) as well as off Alex Kruppa's page. While the files appear complete as far as I can tell, they only cover the ranges of p between 11 - 9,999,991 and 33,219,281 - 35,999,993. Correct. George has still not asked me for my data for exponents above 10 million, but it's probably almost as easy to retest as to have me send (my data isn't very deep for the exponents above 21 million or so), and makes for a good double check. They also don't cover *all* known factors! Correct; since GIMPS is mainly looking for Mersenne primes, Prime95 stops at the smallest factor (which is not always the first factor it finds for an exponent because of the 16 pass approach in the sieving code). Any and all information on the ranges between 10M - 33.22M and above 36M is greatly appreciated, as well as any known factors not listed in the files I've pulled. My prime exponent data for all ranges is now about 111 MB; this includes all known factors, each exponent's largest attempted trial factor, and all the ECM and P-1 effort (but no P-1 save files). The gaps data is another 9MB, and the P-1 save files, mostly from Factor98, are about another 110 MB. All but the P-1 save files use the format described in: http://www.garlic.com/~wedgingt/mersfmt.txt ... which is human readable and accepted by the mers package programs. The P-1 save files are understood by the mers package's extract enough to print most everything but the "residue" itself, including the beta release's extract understanding the new P-1 save file format of George Woltman's Prime95 v19. Extract's understanding of the P-1 save file formats will be extended, when I get around to it, to converting from one P-1 format to another. Conrad Curry writes: Will Edgington maintains this information, but it may be hundreds of megabytes in size. If a website, such as Entropia, has the space it will be useful to make this database available (in many small compressed files) so that others may use it. Yes, but the first problem is that my 56Kb modem is in the way.:( But I would be willing to upload it a range at a time over a month or so, going back to the start to update ranges that have changed since their last upload, if someone out there has enough web disk space for it. And what GIMPS needs, the list of prime exponents with some data but no known factors, is still quite small, especially in the binary DATABASE format (which extract can print in the mersfmt.txt format); that DATABASE file for all prime exponents with data but no factors is only 2MB presently. It is produced by the contract program during my updates and put in the mersdata.{zip,tgz,tar.gz} file. Eric Hahn writes: If no information is known where p>100M, then what can I do?? I have some data for exponents over 2^31. The smallest prime exponent with no data is only 21556027 presently (though I increase it some with every update), however, and most of the data is below that. Also, generating new data for a given prime exponent under about 2^60 (if your machine has an eight byte integer type available in C) or so is easy using mersfacgmp; all it takes is CPU time. Will http://www.garlic.com/~wedgingt/mersenne.html mers.tgz mers.tar.gz mers.zip mersfmt.txt mersdata.tgz mersdata.tar.gz mersdata.zip _________________________________________________________________ Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers ------------------------------ Date: Fri, 24 Sep 1999 19:34:09 EDT From: [EMAIL PROTECTED] Subject: Mersenne: and, from WAY out in left field... (Note that the Subject: line refers to a small portion of my reply, not to the original posting.) Ian L McLoughlin writes: >I have the idea that most people posting to the list are software programmers. >I am a humble chemist more into 2,4-Dihydroxybenzene or antivirals..(Acyclovir??) Hi, Ian: The first comment probably includes me. Regarding is the second - until a few years ago I was a humble Aerospace Engineer trying desperately to scrounge for scarce funding in my chosen specialty, theoretical & computational fluid mechanics. I would have been perfectly content to just stick with my legal pads and modest computer resources and do some basic work (the kind that doesn't need a million-dollar lab), but at most research-oriented engineering schools all they care about is how much grant money one brings in. Then, a little over three years ago, I noticed a little blurb about something called the "Great Internet Mersenne Prime Search" in Science Magazine, and now, a scant few years later, life is very different for me. My job propsects are less certain, but damn, I'm having fun. My research doesn't seem to have suffered, either - it's just a lot more interesting, and nobody cares about less money for capital building projects on my account. In other words, people who psot to and read this list come from all sorts of backgrounds, often ones which will surprise you. You are welcome here, even if you don't intend to prove the generalized Riemann hypothesis. >I must admit, I like Hilbert best of all... Yeah, that Scott Adams, he writes a mean comic strip...oh, that's with an H, you say? As in, Hilbert space...the final frontier. >Perhaps somebody can write a programme for pure integer based calculations.,??? As others have pointed out, these tend to be much slower than their floating-point brethren, but all-integer is still interesting from a theoretical (and perhaps someday soo, practical) perspective. Richard Crandall has an all- integer Nussbaumer convolution code for testing Fermat numbers which I think is available at his website (www.perfsci.com). Jason Papadopoulos has created a highly optimized version of same code for Pentium/Linux which may be of interest ([EMAIL PROTECTED]). The latter code was used for the bulk of the distributed all-integer verification of our (floating-point) proof of the character of the 24th Fermat number (official announcement to come soon). Best regards, Ernst _________________________________________________________________ Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers ------------------------------ Date: Fri, 24 Sep 1999 19:49:57 -0400 From: Pierre Abbat <[EMAIL PROTECTED]> Subject: Re: Mersenne: Front-end design I suggest a couple of named pipes for control (the front end writes to one and reads from the other, and mprime vice versa). Since writing to a pipe whose reader is stuck can get you blocked when the pipe is full, and writing to a pipe with nothing at the other end results in a SIGPIPE, mprime should not output anything to the pipe unless told to do so, and should trap SIGPIPE and turn off output. phma _________________________________________________________________ Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers ------------------------------ Date: Fri, 24 Sep 1999 21:01:21 EDT From: [EMAIL PROTECTED] Subject: Mersenne: Re: Mlucas 2.7x on SPARC The SPARC binary Alex Kruppa sent me of Mlucas 2.7x is at my ftp site: ftp://209.133.33.182/pub/mayer/README ftp://209.133.33.182/pub/mayer/bin/SPARC/Mlucas_2.7x.exe.gz My browser auro-uncompressed the .exe file during transmission and I had to rezip it, so if you get any errors in uncompressing, please try grabbing the original: www.informatik.tu-muenchen.de/~kruppa/Mlucas2.7x.gz I don't even know if the above runs on a machine that doesn't have an f90 compiler installed (i.e. whether the code needs any f90-specific RTL files)- I don't think it does, but anyone with an f90-less SPARC can easily find out. Remember, this a beta - please send me your comments/suggestions/timings /bug reports without delay! Enjoy, Ernst p.s.: visitors to Alex's website should check his class schedule (Stundenplan)- one of his professors has a name that is vaguely familiar. I know I've been busy, but I didn't realize I've been THAT busy, nor that I'd grown a beard. Dementia sets in... _________________________________________________________________ Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers ------------------------------ Date: Fri, 24 Sep 1999 20:44:19 -0700 From: Spike Jones <[EMAIL PROTECTED]> Subject: Mersenne: dont quit your day jobs... Good news, 10 megadigit prime bounty hunters! I previously reported calculating that the mathematical expectation of collecting the $100K EFF prize was about 18 cents per year. I sharpened the analysis a bit and discovered an error! Assuming a 400 MHz PII, running 24-7-52 the EFF mathematical expectation is actually worth closer to about 21 cents per year. {8^D spike _________________________________________________________________ Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers ------------------------------ Date: Sat, 25 Sep 1999 01:23:14 EDT From: [EMAIL PROTECTED] Subject: Mersenne: Re: and, from WAY out in left field... Hi, Ian: >Frankly I can't see any point updating to V19 when I am already testing a >factor of 9Meg+...especially with a Cyrix 333 Now you have some idea how the (non-Intel) Unix folks have felt for much of the past 3-4 years...and those are often US$5000-20000 machines. As with all distributed efforts, we all contribute what we can. It's not a contest, except perhaps amongst us programmers, in terms of pushing each other to continually improve our codes. >Sorry, I am bitter and can't afford a 550 Pentium..... Hopefully soon - here prices have dropped below 1000 $US for 500MHz systems- you can get a 300-400MHz PII virtually for free if you're willing to pay $20/month for 36 months of unlimited Internet access. You should try buying online, e.g. at www.valueamerica.com or some such store. >I update regularly but no time is credited... You usually don't get credit until an exponent or several factoring assignments have completed, and at the moment the forner is taking months even on decent hardware. Also, manual tests (like I do on my Unix boxes) don't get cerdited on the Entropia top producers pages, but do on George's master list. On the other hand, if you have been doing stuff for many months and are connected to PrimeNet yet see no credit, contact Scott <[EMAIL PROTECTED]>. >How do I know that the exponent I am testing has not already run to >conclusion.? PrimeNet (so far as I know - I didn't write the networking software) doesn't hand out duplicate assignments unless it doesn't "hear" from machine X for a long time - George is interested in the large-scale progress of the search (which would be impeded by unnecessary work duplication) more than finishing off all exponents below so-and-so-many millions by Y2K. Chin up - the cheap Pentia are out there, you just to have find them - perhaps prices are higher in the UK, but the Internet makes that a non-issue, I think. Cheers, Ernst _________________________________________________________________ Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers ------------------------------ Date: Fri, 24 Sep 1999 23:08:54 -0700 From: Will Edgington <[EMAIL PROTECTED]> Subject: Re: Mersenne: Front-end design Pierre Abbat writes: I suggest a couple of named pipes for control (the front end writes to one and reads from the other, and mprime vice versa). Since writing to a pipe whose reader is stuck can get you blocked when the pipe is full, and writing to a pipe with nothing at the other end results in a SIGPIPE, mprime should not output anything to the pipe unless told to do so, and should trap SIGPIPE and turn off output. Um, there are easier ways. For one, file descriptors can be set non-blocking on all (modern) UNIX variants, which prevents getting stuck waiting for the other program and from getting a SIGPIPE. Also, most modern UNIXs implement pipes on top of UNIX domain (local to one machine) sockets; TCP/IP uses the same function call interface, sockets, but different addressing (for likely obvious reasons). See rw.c of the mers package and the Prime95 primenet.[ch] source code for how TCP/IP sockets can be used. Feel free to ask me, privately, detailed questions; I've been using TCP/IP via C, mostly for Mersenne stuff oddly enough:), off and on since about 1986. Will http://www.garlic.com/~wedgingt/mersenne.html _________________________________________________________________ Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers ------------------------------ Date: Sat, 25 Sep 1999 10:42:42 +0200 From: Guillermo Ballester Valor <[EMAIL PROTECTED]> Subject: Re: Mersenne: Re: FFTW for GIMPS? Hi: [EMAIL PROTECTED] wrote: > > Guillermo Ballester Valor writes: > > << Do you Know the GNU-FFTW package ?(The Fastest Fourier Transform in the > West). Last week I thought it would be interesting to see if it is as > fast as they say. It is really a fast C-written FFT code. >> > .... > > My comment is this: If you want to create a fast FFT-based program in a > short time, FFTW is certainly a good way to do it. On the other hand, if > you're really striving for extreme performance (i.e. trying to write a > code that possibly many people will use intensively), it is best to have > a code whose details you understand well. In my case, the latter criterion > (and the fact that I wanted to learn as much as I could about FFTs) led me > to write my own code. I started with the Numerical Recipes FFT (slow and > not very accurate, but easy to play with) about 3 years ago and have been > working on it ever since - my current code looks nothing like the NR FFT, > but you have to start somewhere. > Yes, certainly I've be able to adapt lucdwt and McLucasUNIX in four days. On the other hand, my goal only was to know if working with FFTW is a good idea, and timings obtained make me think it could be. > Looking at the FFTW timings page, for a length-262144 real-vector transform > they list (http://www.fftw.org/benchfft/results/alpha467.html) > a performance of around 105 "MFlops" on a 467 MHz Alpha 21164. Using > their definition of MFlops for real FFTs, this translates to a per-FFT time of > > 0.5*[5*262144*log2(262144) Flop]/[115 MFlop/sec] = 0.112 sec. > > My LL code does 2 FFT's plus other operations per Mersenne-mod squaring, > so we estimate about 80% of the per-iteration time equals one FFT. At 256K > vector length it needs .177 sec per iteration on a 400 MHz 21164, which > leads to an estimate of .40*.177*400/467 = 0.061 sec on a 467MHz 21164 > which is significantly faster than FFTW. > If your comparison were ported to intel machines, which is wrong, your code will run nearly as fast as mprime!!. You say your code is twice faster than FFTW, sure it is, *BUT* in my pentium-166 the short code I wrote do an iteration of my actual exponent 3975659 in 0.901 seconds while mprime take only 0.359. This makes a RPI=40%. Then, your code will reach nearly 90% !and without lots of assembler code!. Is there any linux or window Mlucas 2.7 executable for intel machines? It would be nice to look at timings. P.S. The source I sent to E. Mayer was buggy, it was an early version I sent him :-(, if somebody want to the source, mail me in private. | Guillermo Ballester Valor | | [EMAIL PROTECTED] | | c/ cordoba, 19 | | 18151-Ogijares (Spain) | | (Linux registered user 1171811) | _________________________________________________________________ Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers ------------------------------ End of Mersenne Digest V1 #632 ******************************
