Mersenne Digest Wednesday, September 22 1999 Volume 01 : Number 630 ---------------------------------------------------------------------- Date: Tue, 21 Sep 1999 21:25:02 +0200 From: "Floris Looyesteyn" <[EMAIL PROTECTED]> Subject: Mersenne: FDIV Pentium error I was wondering if Prime95 is affected by the Pentium FDIV bug. (or some name like that). I ask this because now i'm also using it on my laptop (great work george!) and when i installed linux some time ago it said the processor had this bug. Floris Looyesteyn _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com _________________________________________________________________ Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers ------------------------------ Date: Tue, 21 Sep 1999 22:58:59 +0200 From: "Lars Lindley" <[EMAIL PROTECTED]> Subject: Re: Mersenne: FDIV Pentium error > I was wondering if Prime95 is affected by the Pentium > FDIV bug. (or some name like that). > I ask this because now i'm also using it on my laptop > (great work george!) and when i installed linux some time > ago it said the processor had this bug. > It should not be a problem because Linux recognizes the bug and uses a workaround. Regards /Lars _________________________________________________________________ Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers ------------------------------ Date: Tue, 21 Sep 1999 23:11:46 +0200 From: "Steinar H. Gunderson" <[EMAIL PROTECTED]> Subject: Mersenne: Re: Re: Timing(?) errors On Tue, Sep 21, 1999 at 02:03:54PM -0500, Willmore, David wrote: >Correct, it does not. Normally, though, when you're swapping, proper L2 >cache coloring is the least of your performance problems. Yes, but if you _force_ swap-out-swap-in, like ReCache does? /* 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: Tue, 21 Sep 1999 23:12:58 +0200 From: "Steinar H. Gunderson" <[EMAIL PROTECTED]> Subject: Mersenne: Re: FDIV Pentium error On Tue, Sep 21, 1999 at 09:25:02PM +0200, Floris Looyesteyn wrote: >I was wondering if Prime95 is affected by the Pentium >FDIV bug. (or some name like that). I've run it with on a P60 (with the FDIV bug) for 2-3 years now (at least pre-PrimeNet), and it has never been a problem. Remember that the bug influences FDIV only (which is very slow -- and thus George doesn't use it that much ;-) ), and not to a very great extent either. /* 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: Tue, 21 Sep 1999 16:59:20 -0500 From: "Willmore, David" <[EMAIL PROTECTED]> Subject: RE: Mersenne: Re: Re: Timing(?) errors Random chance. I wouldn't count on it. > -----Original Message----- > From: Steinar H. Gunderson [SMTP:[EMAIL PROTECTED]] > Sent: Tuesday, September 21, 1999 4:12 PM > To: [EMAIL PROTECTED] > Subject: Mersenne: Re: Re: Timing(?) errors > > On Tue, Sep 21, 1999 at 02:03:54PM -0500, Willmore, David wrote: > >Correct, it does not. Normally, though, when you're swapping, proper L2 > >cache coloring is the least of your performance problems. > > Yes, but if you _force_ swap-out-swap-in, like ReCache does? > > /* 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 _________________________________________________________________ Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers ------------------------------ Date: Tue, 21 Sep 1999 18:07:44 -0400 From: George Woltman <[EMAIL PROTECTED]> Subject: Re: Mersenne: Interesting PrimeNet Error Hi, At 06:24 PM 9/20/99 -0700, Eric Hahn wrote: >Sending text message to server: >M10461667 has a factor: 7841028322998353783 >Sending expected completion date for M10461667: Sep 21 1998 >ERROR 11: Exponent already tested. > >Yes, the expected completion date message was expected as >the machine was still testing (for smaller factors) > >I just found it interesting that PrimeNet would produce an >error like this. What would happen if Prime95 should happen >to find a smaller factor? Would it be accepted? This is really a flaw in our original design that we've never bothered to fix. I believe prime95 shouldn't send an expected completion date if it has already reported a factor. However, it is a low priority bug. The server will happily accept any smaller factors you find. Regards, George _________________________________________________________________ Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers ------------------------------ Date: Tue, 21 Sep 1999 18:03:06 -0400 From: George Woltman <[EMAIL PROTECTED]> Subject: Re: Mersenne: Prime95 v19 oops... Hi, At 10:09 PM 9/20/99 +0300, Jukka Santala wrote: >Something I forgot from earlier playing, the manual factoring savefiles >on Prime95 v19 at least don't work out too well especially on dual-CPU >machines... Since these savefiles will always be named "p0000000" >regardless of the -A parameter and exponent to test ;) This is a v18 bug that I declined to fix. Maybe I should delete that Advanced/Factor menu choice :) To work around this create one directory for each CPU. This is the only known flaw in dual-CPU environments. Regards, George _________________________________________________________________ Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers ------------------------------ Date: Tue, 21 Sep 1999 16:27:09 -0700 From: Eric Hahn <[EMAIL PROTECTED]> Subject: Mersenne: Factoring Does anybody know if there is an exponent where the factor is, or know whether there is a proof on whether a factor can (or can't) be, a root?? A square?? To clarify this: We know that any factor of 2^p-1 is in the form 2kp+1. Letting x >=2, Can (2kp+1)^x = 2^p-1 ?? Can (2kp+1)^x * (2kp+1) ... = 2^p-1 ?? Eric Hahn _________________________________________________________________ Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers ------------------------------ Date: Tue, 21 Sep 1999 19:47:41 -0400 From: George Woltman <[EMAIL PROTECTED]> Subject: Re: Mersenne: v19 manual workdodo.ini error. Hi, At 02:42 PM 9/18/99 +0200, Lars Lindley wrote: >I discovered a lost exponent in the team-report and thought I would >reassign that exponent for myself. >I manually edited the worktodo.ini by adding the row >DoubleCheck=3393469,61 on the first line. >I thought that prime95 would put the exponent I was working on on >hold to do the doublecheck first as v18.1 would have. >To my surprise it continued with the old exponent. I've tracked down and fixed this bug that Lars and Rick reported. Look for a new v19 beta in the next day or two (I'll announce it to the mailing list). Regards, George _________________________________________________________________ Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers ------------------------------ Date: Tue, 21 Sep 1999 21:39:08 -0400 From: Jud McCranie <[EMAIL PROTECTED]> Subject: Re: Mersenne: Factoring At 04:27 PM 9/21/99 -0700, Eric Hahn wrote: We know that any factor of 2^p-1 is in the form 2kp+1. >Letting x >=2, > Can (2kp+1)^x = 2^p-1 ?? > Can (2kp+1)^x * (2kp+1) ... = 2^p-1 ?? No known factors of Mersenne numbers have x>1, but it hasn't been proven that it is impossible. +---------------------------------------------------------+ | Jud McCranie | | | | Programming Achieved with Structure, Clarity, And Logic | +---------------------------------------------------------+ _________________________________________________________________ Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers ------------------------------ Date: Tue, 21 Sep 1999 19:44:08 -0700 From: Eric Hahn <[EMAIL PROTECTED]> Subject: Re: Mersenne: Iteration Times (was: GIMPS client output) At 09:47 AM 9/21/1999 -0700, James Escamilla wrote: >Wouldn't the run time at 4.231 be about 10 years? Yes, for that particular exponent (79,299,959), it would take approx. 10 yrs. and 231 days to test. That's assuming 4 items: 1) A P2 266MHz PC was being used the entire time. 2) The PC was being used exclusively to test the exponent 24/7. 3) The 4.231 sec/iter is constant (which it isn't!) 4) A factor isn't found (below 2^62 is unsuccessful at least!) Eric Hahn _________________________________________________________________ Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers ------------------------------ Date: Tue, 21 Sep 1999 20:43:18 -0700 (PDT) From: poke <[EMAIL PROTECTED]> Subject: Re: Mersenne: FDIV Pentium error All programs are affected by the FDIV bug. It is a bug in the design of the microprocessor. Linus has a way around it. The brain dead morons at Microsoft have to make everyone else wait for a solution (That has yet to come AFIK). Linux on the other hand usually has problems solved in a matter of hours. - -Chuck On Tue, 21 Sep 1999, Floris Looyesteyn wrote: > I was wondering if Prime95 is affected by the Pentium > FDIV bug. (or some name like that). > I ask this because now i'm also using it on my laptop > (great work george!) and when i installed linux some time > ago it said the processor had this bug. > > Floris Looyesteyn > > > _________________________________________________________ > Do You Yahoo!? > Get your free @yahoo.com address at http://mail.yahoo.com > > _________________________________________________________________ > Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm > Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers > -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ : WWW: http://www.silverlink.net/poke : : E-Mail: [EMAIL PROTECTED] : ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ : Ask Mike! Aviation's response to Dear : : Abby. http://www.avstarair.com : ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ _________________________________________________________________ Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers ------------------------------ Date: Wed, 22 Sep 1999 00:42:30 -0400 From: "Chris Nash" <[EMAIL PROTECTED]> Subject: Re: Mersenne: M(M(127)) and other M(M(p)) Hi folks > Wait, that might just be the reason to search! Will only searched up to > k=4 for M(M(6972593)), but if 2*k*M(p)+1 divides M(M(p)), then you've just > beaten the world record! Non-Mersenne's might once again grace the top > 10 list! I really hope that neither Will Edgington (with M(M(6972593))) nor Chip Kerchner (with M(M(1398269))) dedicated any computer time whatsoever to search for factors 2*k*M(p)+1 up to k=4. As Will's page http://www.garlic.com/~wedgingt/MMPstats.txt points out, since M(p)=1 mod 3, k cannot be 1 mod 3. Also, since M(p)=-1 mod 8 for odd p>=3, k must be 0 or 1 mod 4 (otherwise 2 is not a quadratic residue of this supposed factor, the 8x+-1 condition). It follows then the first possible factor of M(M(p)) has k=5. Chris Nash Lexington KY UNITED STATES _________________________________________________________________ Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers ------------------------------ Date: Wed, 22 Sep 1999 00:28:18 -0500 From: Ken Kriesel <[EMAIL PROTECTED]> Subject: Re: Mersenne: FDIV Pentium error Poke's post sounds like a troll, but what the heck, I'll respond. At 08:43 PM 1999/09/21 -0700, poke wrote: > >All programs are affected by the FDIV bug. No. Not all programs use the FPU. Some that do, do not use instructions affected by the bug. >It is a bug in the design of >the microprocessor. Yes. But there was a recall program of about a year's duration, back when the P5-100 was the fastest rated speed that Intel sold. >Linus has a way around it. >The brain dead morons at Microsoft have to make everyone else wait >for a solution >(That has yet to come AFIK). Microsoft announced patches years ago, for FDIV error workarounds in their operating systems of the time, as well as the calculator applet and the Excel spreadsheet. >Linux on the other hand usually has problems solved in a >matter of hours. Microsoft does regression testing of patches before releasing. They don't always get it right on the first release of their patches, but the variety of combinations that face them is mind-numbing. It's hard to imagine that a thorough regression testing could be performed in a few hours. This is not meant to be flamebait; just stating the facts as I recall them. I know and respect coworkers who regularly use Linux, and occasionally use it myself. >-Chuck > > > >On Tue, 21 Sep 1999, Floris Looyesteyn wrote: > >> I was wondering if Prime95 is affected by the Pentium >> FDIV bug. (or some name like that). My recollection is Prime95 is unaffected. Will Edgington had not at that time detected any factors missed due to the pentium FDIV bug. George and I had a conversation about workarounds for the pentium FDIV bug 3 June 1996. Here are some old URL's I included then. See http://pentium.intel.com/procs/support/pentium/fdiv/swpatch/patch.txt This includes the personal names of the discoveror and other early investigators. See also a couple levels up from that page for more info. Also: http://www.free.net/ftp/systems/pentium/division.letter for someone else's approach to the calculate both ways and check method. http://almond.srv.cs.cmu.edu/afs/cs.cmu.edu/project/verify/www/srt-bdd.html search April issues of Dr Dobb's journal for an article by Time Coe. http://enigma.db.erau.edu/~flynnt/pentium.html for a FAQ. Also has Nicely matl. Nicely discovered the flaw. http://www.mathworks.com/README.html "The Pentium Papers", many links. coe.txt and pratt.txt are worth reading. also moler_6 and moler_7. http://www.mathworks.com/Moler_7.txt If you detect a buggy pentium, you must shift your operands out of the situation where the known-bad bit pattern occurs in one of the divide attempts. The gist of it is, scale operands by 3 to ensure differing bit patterns, and there's a sizable performance hit. >> I ask this because now i'm also using it on my laptop >> (great work george!) and when i installed linux some time >> ago it said the processor had this bug. >> >> Floris Looyesteyn Ken Ken Kriesel, PE <[EMAIL PROTECTED]> _________________________________________________________________ Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers ------------------------------ Date: Wed, 22 Sep 1999 11:17:03 -0400 From: George Woltman <[EMAIL PROTECTED]> Subject: Mersenne: Version 19 - beta #3 Hi all, Thanks to everyone for the thorough testing of v19. I've fixed several bugs mainly dealing with worktodo.ini and expected completions dates. Only one "serious" bug was found - creating the half-hourly P-1 save files would sometimes lead to ILLEGAL SUMOUT errors. The new prime95 beta can be downloaded at: ftp://entropia.com/gimps/p95b.zip The linux beta dynamicly linked with glibc 2.1 is at: ftp://entropia.com/gimps/mprb.tgz The linux beta staticly linked is at: ftp://entropia.com/gimps/sprb.tgz For the really brave, the completely untested Windows NT service version is at: ftp://entropia.com/gimps/ntb.zip Two new items: 1) Mprime and ntprime now support a -c command line argument to contact the primenet server and exit. 2) The file undoc.txt describes all the previously undocumented features of prime95. Regards, George _________________________________________________________________ Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers ------------------------------ Date: Wed, 22 Sep 1999 11:15:06 -0600 From: Aaron Blosser <[EMAIL PROTECTED]> Subject: RE: Mersenne: Version 19 - beta #3 That reminds me George... For others besides George: I'd devoted 5 weeks of time on a PII-450 w/ 1GB RAM to run a test using v19.0.1 The run was on: Pminus1=16777216,1000000,40000000,1,24 It actually took about 31 days which fit my estimate of 30 days pretty darn good. Per George's request, I kept a close eye on the memory usage and during the entire run (only 1 stop/restart during the entire time since I had to upgrade that server) it behaved quite well. No memory leaks. Memory usage averaged around 120-130 MB but peaked around 145MB during the initialization stage, but then went down to between 120-130MB. I'll be emailing you the savefile George... was it supposed to do anything besides say "Stage 2 complete" when it was done? One thing I *did* notice though... When it finished, it just sat there, with only "Stage 2 complete" being the last thing output to the window, but the Prime95.exe process continued to draw all idle cycles and memory usage "stuck" at about 30MB or so. Since I'd configured it to NOT contact Primenet (at your request), shouldn't it have said something like "no work to do" or whatever? Anyway, that's my "bug report". :-) For what it's worth, I did not have any ILLEGAL SUMOUT errors when it would save my p-1 temp file. Aaron ps - All: notice I have a new email address...temporarily. @Home is transferring my service to a new address and, rather than simply change the address on my subscription, they had to cancel my old account, setup a new one, and once the old one is fully out of their system, then I can get my old email address back. Sigh...sorry to anyone who has tried to send me email and had it bounce...it'll be back up "soon" according to TCI, er, I mean AT&T. > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED]]On Behalf Of George > Woltman > Sent: Wednesday, September 22, 1999 9:17 AM > To: [EMAIL PROTECTED] > Subject: Mersenne: Version 19 - beta #3 > > > Hi all, > > Thanks to everyone for the thorough testing of v19. I've > fixed several bugs > mainly dealing with worktodo.ini and expected completions dates. > Only one "serious" bug was found - creating the half-hourly P-1 save > files would sometimes lead to ILLEGAL SUMOUT errors. _________________________________________________________________ Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers ------------------------------ Date: Wed, 22 Sep 1999 14:31:48 -0600 From: Aaron Blosser <[EMAIL PROTECTED]> Subject: RE: Mersenne: Version 19 - beta #3 George, I downloaded the Prime95 beta and ran into one problem: I changed the computerID of the machine and then before it got a chance to contact Primenet to update that info, I also told it to update completion dates and told it to contact the server. What happened was strange...it contacted Primenet, updated the computer info and sent expected completion dates, just like it should have. But then, it kept resending expected completion dates over and over. I noticed that prime.spl was in the directory but that it wasn't being deleted after actually sending the completion dates. The file size was 1 byte, just like it should have been, but it just stayed there, so every time Prime95 polled to look for that file (or whatever), it'd resend again and again and again. I had backed up the old version and save files and I'm back to that now. For what it's worth, the NT service version is okay AFAIK. But then, I noticed that the NTSETUP.EXE program is the same as the one in v18 Aaron _________________________________________________________________ Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers ------------------------------ Date: Wed, 22 Sep 1999 17:07:03 -0400 From: "Rick Pali" <[EMAIL PROTECTED]> Subject: RE: Mersenne: Version 19 - beta #3 From: Aaron Blosser > I noticed that prime.spl was in the directory > but that it wasn't being deleted after actually > sending the completion dates. The same thing happened to me. I deleted the file and all is working fine now. The only thing I'm concerned about is that the spl may not be deleted the next time it tries to contact the server in it's automated schedule. We'll see. Rick. - -+--- [EMAIL PROTECTED] http://www.alienshore.com/ _________________________________________________________________ Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers ------------------------------ Date: Wed, 22 Sep 1999 17:24:32 -0400 From: George Woltman <[EMAIL PROTECTED]> Subject: Mersenne: Oops - Version 19 - beta #4 Hi all, If you downloaded beta #3 this morning please download beta #4. Beta #3 likes to repeatedly send expected completion dates. The prime95 beta can be downloaded at: ftp://entropia.com/gimps/p95b.zip The linux beta dynamicly linked with glibc 2.1 is at: ftp://entropia.com/gimps/mprb.tgz The linux beta staticly linked is at: ftp://entropia.com/gimps/sprb.tgz For the really brave, the completely untested Windows NT service version is at: ftp://entropia.com/gimps/ntb.zip Sorry for the trouble, George _________________________________________________________________ Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers ------------------------------ Date: Mon, 20 Sep 1999 21:17:31 +0100 From: "Brian J. Beesley" <[EMAIL PROTECTED]> Subject: Decamega Tests (was: RE: Mersenne: GIMPS client output) On 20 Sep 99, at 1:06, Rick Pali wrote: > The only question that comes to mind is if you had to plough through > factoring before you got to the LL test...but then I realise that you still > wouldn't be done if that were true. You don't have to pre-factor, if you choose "Test" or "Time" from the "Advanced" menu. > > I signed up for an exponent in the 33mil range and the factoring alone took > 13 days on a P3-500. Ah, so we're maybe not doing enough trial factoring. I guess your completion time is about a year; trial factoring should take between 5% and 10% of the time for a LL test, & 13 days is only about 3.5%. I think we should probably go one bit deeper, this would double the trial factoring time - but would save the whole year, if you managed to find a factor. > I'd originally does it for testing purposes, but after > that I've just got to let it continue. :-) Well, why not? > > In a year's time, I'd love to see some numbers on how many signed up for tem > million digit numbers and later quit for smaller exponents... I think you need to be a true enthusiast to take on a single test taking ~ 1 year. Lots (attracted by ca$h) won't realise what it means, for a week or two, & may then drop out 8-( To avoid this happening to too many people, I think we should be a bit more upfront that testing a 10 million digit number is going to take about a year, even on a state-of-the-art system. I have several fastish systems - a couple of them are running QA stuff at the moment - I may voluntarily take on a 10 million digit number on _one_ of them, but I certainly wouldn't choose to run tests of that length on _all_ of them! Regards Brian Beesley _________________________________________________________________ Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers ------------------------------ Date: Thu, 23 Sep 1999 03:30:44 +0200 From: "Robert van der Peijl" <[EMAIL PROTECTED]> Subject: Mersenne: GIMPS page in Dutch To all Dutch-speaking subscribers to this mailing list: There is a GIMPS page in Dutch at: http://www.dse.nl/~m31/mersenne/prime.htm Just 'klik op de link', and let me know what you think. I would appreciate any comments you could give me. Please respond by private e-mail to: Robert van der Peijl <[EMAIL PROTECTED]>. Tot ziens op de Nederlandstalige GIMPS pagina! (=see you!) _________________________________________________________________ Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers ------------------------------ Date: Wed, 22 Sep 1999 23:05:41 EDT From: [EMAIL PROTECTED] Subject: Mersenne: multi-exponent bug in Mlucas 2.6c Dear Mersenners: I have bad news and good news. First the bad: David Willmore has reported a bug in Mlucas 2.6c, which may cause some or all exponents beyond the first in a multi-exponent (range) test to yield incorrect results. For people doing first LL tests on large exponents, since v2.6 is only one month old, you're probably still on exponent number 1, and thus should be OK. The bug is most likely to affect double-checking (what David has been doing)- I apologize for any wasted DC time that may have resulted due to this. What was happening is this (sorry - this necessarily gets a tad technical): when the code detects that a new exponent is being done, it deallocates all the arrays, figures out the new FFT size, reallocates at the new size, and re-inits things like sincos data and DWT weights. No problem there. But...the DWT weights are calculated starting with a parameter, the number of "bigwords" (residue digits represented with respect to base = 2^ceiling(p/n)) in the Crandall-Fagin mixed-radix representation. For exponent p and runlength n, the number of bigwords is mod(p,n). This parameter was being properly reset in the master squaring routine for each new p, but its value was also being saved in one of the auxiliary routines (for carry propagation) and there it was only being reset if the FFT length changed, not for a new p at the same n. To see this in action, create a scratch directory, within which there is a range file containing the following 2 small p's (both of which use n=512): 9689 11213 These are in fact both Mersenne prime exponents, but when you run v2.6c on them, only the first is found to be prime. This possibility slipped through my usual pre-release tests since (a) my self-tests used multiple p's, but all with different n; (b) the incorrect bigwords parameter leads to an incorrect carry propagation step, but the resulting residue digits are still all whole numbers, i.e. you won't see any fatal roundoff errors as a result. Thus, here is how this would affect your testing: 1) Any first exponent out of a range should be fine; 2) Any exponent preceded by one that yields a different runlength is OK; 3) Any exponent preceded by one that uses the same runlength will be bad. If you're not sure where your current exponents fit into the above, you can check whether these runs are OK or not as follows: 1) Stop the run in question. 2) Get the beta of Mlucas v2.7: <ftp://209.133.33.168/pub/mayer/README>. 3) Install the proper binary for your platform; 4) Copy the range file into one named worktodo.ini in your LL test directory. (you don't need to worry about renaming the savefiles - 2.7 uses Prime-95- like savefile names, i.e. your old ones won't get overwritten.) 5) Fire up v2.7. As soon it has done at least 2000 iterations, compare the 2000-iteration Res64 (in the pXXXXX.stat file) to the analogous one in your old run's "status" file. If they're the same, stop v2.7 and let v2.6 finish the exponent (just restart it - no need to play with files). Note that if v2.6 was < 20% of the way through the exponent, it may be faster to just let 2.7 redo it from scratch - the comparative 2000- iteration timings in the files will tell you which will be faster. (5) contains the good news - a beta of v2.7 is available, and it runs significantly faster than v2.6, especially on the Alpha. See my forthcoming posting about what's new and improved in v2.7. (Also see the README file.) David W. also writes: << On the [CPU] which was given a mix of numbers (112K fft and 128K fft size) something odd is happening. The Iteration time for the 112K fft was 3:08 (for 2K iterations). Now, when it switched to the 128K size exponent, the CPU time for 2K iterations went up to 4:34!! The run which has always been doing 128K size exponents has been taking 3:48 very consistently through both exponents. Any idea what would cause that? >> Possibly some weird cache behavior or interaction with other processes? On the other hand, if you got 4:34 for the first 2000 squarings, much of that may be initialization time, and the time should be lower for all subsequent checkpoints. On my 400 MHz Alpha 21164, v2.7 gives per-iteration times of .069 and .078 seconds at 112 and 128K, respectively. That translates into 2000-iteration times of 1:44 and 1:57 (mm:ss) on your 533MHz 21164. Best regards, - -Ernst _________________________________________________________________ Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers ------------------------------ Date: Wed, 22 Sep 1999 23:05:45 EDT From: [EMAIL PROTECTED] Subject: Mersenne: beta of Mlucas v2.7 available As I noted in my previous message, a beta of Mlucas v2.7 is now available. ftp://209.133.33.168/pub/mayer/README has details. There is source code and binaries for selected platforms (Alpha/Unix, SGI Irix). Alex Kruppa mentioned that he may have access to the SPARC F90 v2 compiler (hopefully better than v1), in which case we may also have SPARC binaries soon. I'll post a Linux binary once any near-term bugfixes have been taken care of. (I don't want to bug my contacts at Compaq (compaqts?) more than necessary.) What's new? Here are the major items: 1) The code now uses an in-place FFT, as well as getting all its FFT sincos and DWT weights data via small-table multiplies, rather than by reading large arrays. Overall the memory needed is 1/4 that of v2.6 - just a bit over 8 MB at FFT length 1024K, for example. This greatly improves cache utilization and leads to nice performance gains - 20-40% faster on Alpha (21064 and 21164 - haven't had a chance to try the 21264 yet), 10-25% faster on MIPS. 2) Filename conventions have been changed to be more similar to Prime95. 3) The code now reads just the first entry in the worktodo.ini file at the start of each new run, allowing users to add/delete/modify other entries in the file at will. 4) The code now saves each run's statistics (what used to get written to the status file and then deleted at the end of the run) in its own file. This will make it easier to compare timings of future versions and (in case of results later shown to be bad) pinpoint where problems occurred. 5) The code can test exponents up to 78.3 million. Note that v2.7 savefiles are incompatible with v2.6 - I didn't want to add the complicated logic that would be needed to allow for backwards compatibility. OK, now for the stuff users really want to see - here are timings on Alpha 21064, 21164 and MIPS R10000, the two platforms I have easy access to (You can compare these to the v2.6 timings I posted on 21 August): Platform/per-iteration time (sec) 200MHz21064 400MHz21164 195MHz R10K 250MHz R10K cache sizes 8KB L1 32kB L1 32kB L1 unknown 96KB mixed 512KB L2 4MB L2 1MB L2 FFT length: ---------- ---------- ---------- ------------- 64K .095 .035 .041 .035 80K .12 .045 .054 .047 96K .16 .057 .069 .062 112K .19 .069 .082 .074 128K .21 .078 .100 .090 160K .27 .098 .118 .115 192K .32 .115 .143 .144 224K .39 .140 .170 .170 256K .48 .177 .221 .210 320K .65 .241 .261 .248 384K 1.06 .316 .345 .317 448K 1.29 .399 .388 .354 512K 1.39 .545 .525 .451 640K 1.88 .620 .649 .543 768K 2.35 .756 .814 .659 896K 2.73 .890 .932 .771 1024K 2.96 1.20* 1.16 .937 1280K 3.20 1.32 1.40 1.13 1536K 4.15 1.86* 1.90* 1.54* 1792K 4.99 2.13 2.04 1.68 2048K 5.45 2.73 2.57 2.22 2560K 6.93 3.16 3.25 2.61 3072K 8.33 4.02 3.92 3.16 3584K 9.96 4.53 4.58 3.69 4096K 11.42 5.62 6.14 7.26* Thus, things are looking pretty good for runlengths of current interest (64-1024K). I've only begun playing with optimization of the new in-place scheme - this should help the really big runlengths a lot. The only obviously anomalous timings are marked with asterisks and are: a) 400MHz 21164 at 1024K (reason unknown); b) 250MHz R10K at 4096 (weird, but unlikely to affect your current work :) c) 21164and both R10K's at 1536K - until I get around to writing a set of radix-12 pass routines, this FFT length needs one more pass through the data than its neighbors. Strangely, this doesn't hurt on the 21064. (Not that you'd want to ever run a full LL test with 1536K FFT on a 21064.) * * * * In the coming weeks I'll flesh out the above table, e.g. by adding timings for more platforms as well as comparisons with Prime95 v19 and MacLucasUNIX. That will be the basis for a timings webpage. I can also add timings for other codes, but to keep things from getting out of hand, I plan to use at least a few reasonable criteria a candidate code should meet to get included on the timings page. This may seem heavyhanded, but we need to allow non-Intel clients to quickly determine what works best on their hardware, rather than just telling them to pick one of the dozen-odd codes from the "other available source code" page, which lists no performance benchmarks. Here is what I propose - your comments are welcome: 1) Must allow exponents up to 20 million (this will keep shifting as GIMPS work progresses). 2) Must exhibit a relative performance index (RPI) of at least 33% for at least half the non-factored exponents in the range {lower limit of current double-checking} <= p <= {limit set in (1)}, on at least one reasonably popular platform (say, at least 10000 such CPUs have been sold). The RPI for an exponent p is defined as follows: (time for Prime95 to test M(p) on x86) *(clock rate of x86) RPI(p) = ------------------------------------------------------------- x 100% (time for code X to test M(p) on CPU Y)*(clock rate of CPU Y) For example, Mlucas 2.7 at 384K (the accuracy is similar enough to Prime95 to allow us to just consider FFT length - if code X is significantly less accurate or allows just power-of-2 FFT lengths, we may have to compare different FFT lengths in the above formula) takes .316 sec. George gives a time of .211 sec on his 400MHz PII for the same FFT length. Since the two CPU clock rates are the same, Mlucas has an RPI of (.211/.316)x100% or about 67%, meaning that at that runlength, it performs about 67% as well on the 21164 as Prime95 on the PII. For the same FFT length, on the 250 MHz R10K, we have nearly the same per-iteration time as on the 400MHz 21164, but the clock rate is lower: .211 * 400 RPI = ---------- x 100% = 106%, .317 * 250 meaning that the MIPS performs slightly better than Prime95 running on a PII with the same clock speed. 3) Source code (except possibly for things like validation keys) freely available. Cheers, - -Ernst p.s.: As this message is rather long, if you reply to the list, *please* don't append the whole thing. _________________________________________________________________ Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers ------------------------------ Date: Thu, 23 Sep 1999 06:26:44 +0200 From: "Robert van der Peijl" <[EMAIL PROTECTED]> Subject: Mersenne: Front-end design I wrote to George Woltman: I wonder if there are any volunteers out there willing to design and write an attractive front-end for the v19 GIMPS client. There is, I believe, considerable interest in having a smart-looking user-interface on the Win/Linux/? desktop. Running, it would only use very few extra processor cycles. A project of limited size, someone could manage and coordinate it, including the QA testing. George Woltman replies: The Windows user-interface should be easy - simply translating the resource file. Linux might be tougher - I'm not very familiar with that environment. He further writes: There are some Linux folks that like the present program because it doesn't use X-windows. Of course, offering a choice can't hurt. Ideally, the interface would be the same as the Windows interface so that help and readme files would work in both environments. If someone writes an X-Windows front end I'd be happy to look at using it in a future release. So, here's my appeal to you all: Any programmers/designers interested in writing a nice front-end? 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? Once the prime client has a nice-looking GUI, those millions running their fancy SETI@home screensavers looking for intelligence will all come rushing over to GIMPS! ;-) Robert van der Peijl mailto:[EMAIL PROTECTED]?Subject=front-end _________________________________________________________________ Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers ------------------------------ Date: Wed, 22 Sep 1999 21:44:22 -0700 (PDT) From: poke <[EMAIL PROTECTED]> Subject: Re: Mersenne: FDIV Pentium error I just wanted to apologize for my arrogant response to the FDIV Pentium error post. I lost several hours of work that day when our company's installation of SMS rebooted my machine with only five seconds notice, in order to install a patch and used the message to vent. Please accept my apologies... - -Chuck -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ : WWW: http://www.silverlink.net/poke : : E-Mail: [EMAIL PROTECTED] : ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ : Ask Mike! Aviation's response to Dear : : Abby. http://www.avstarair.com : ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ _________________________________________________________________ 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 #630 ******************************
