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
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
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
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
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
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
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 pX.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
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
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
Re: Decamega Tests (was: RE: Mersenne: GIMPS client output)
"Brian J. Beesley" wrote: 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 Notice that in v19 if you set it to get 10 Million range numbers you get a warning about it taking a year on a 500 Mhz P-2, and odds of 1 in 250,000. _ Unsubscribe list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
