Mersenne Digest Monday, May 21 2001 Volume 01 : Number 855 ---------------------------------------------------------------------- Date: Sat, 19 May 2001 10:55:59 -0400 From: =?iso-8859-1?Q?Roger_Gari=E9py?= <[EMAIL PROTECTED]> Subject: Mersenne: Fw: numeric hazards of high performance CPU design => Pentium 4 - constant speed problem I came about this information on degrading calculations after about 10 minutes of usage. I think it can help explain stange behavour on your test of Prime 95 for P4. Don't be confuse by the web page title. - -------------------------------------------------------- Roger Gari�py :-) <- :-( [EMAIL PROTECTED] - ----- Original Message ----- From: "validlab" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Thursday, May 17, 2001 5:20 PM Subject: numeric hazards of high performance CPU design > > http://www.inqst.com/articles/athlon4/0516main.htm _________________________________________________________________________ Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers ------------------------------ Date: Sat, 19 May 2001 08:38:53 -0700 From: Timothy Luders <[EMAIL PROTECTED]> Subject: Re: Mersenne: Different results Hello Mersenne, George woltman wrote: >This suggestion is actually a high priority for the next release. The >error is probably caused by some driver or program initialization that isn't >saving the FPU state properly. The error is benign as you found out. >I think the main advantage of this feature is it will lead to slightly faster >boot times and thereby improve prime95's reputation of not interfering with >your everyday work. Glad to see this. 99% of errors form my computer are at boot usually after a new program install. I try to remember to uncheck Windows95 service when installing anything but sometimes it slips by. Timothy Luders replying form the digest _________________________________________________________________________ Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers ------------------------------ Date: Sat, 19 May 2001 16:52:22 +0100 (BST) From: Chris Jefferson <[EMAIL PROTECTED]> Subject: Re: Mersenne: Fw: numeric hazards of high performance CPU design => Pentium 4 - constant speed problem I just felt I had to say, that I am very disturbed by this. The idea of my CPU simply shutting down when it overheats is a sensible idea. This is much more dodgy, espicaly as there doesn't seem to be any way of finding out, short of lots of benchmarks, if your processor is doing this... :-( It also raises problems for prime95, as it looks like running prime95 will reduce your PC's speed by half. I am going to recieve a pentium 4 shortly, and although I shall try to send it back for an AMD processor, if I can't I shall run tests with prime95. However if these figures are true then it won't be searching for primes :-( Chris - -- Chris Jefferson, Girton College, Cambridge, CB3 0JG - --------------------------------------------------- http://mrjeff.webjump.com Don't bother, it's not worth looking at. On Sat, 19 May 2001, Roger Gari�py wrote: > > I came about this information on degrading calculations after about 10 > minutes of usage. > > I think it can help explain stange behavour on your test of Prime 95 for P4. > > Don't be confuse by the web page title. > > -------------------------------------------------------- > Roger Gari�py :-) <- :-( > [EMAIL PROTECTED] > > ----- Original Message ----- > From: "validlab" <[EMAIL PROTECTED]> > To: <[EMAIL PROTECTED]> > Sent: Thursday, May 17, 2001 5:20 PM > Subject: numeric hazards of high performance CPU design > > > > > > http://www.inqst.com/articles/athlon4/0516main.htm > > _________________________________________________________________________ > 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: Sat, 19 May 2001 16:24:55 -0400 From: George Woltman <[EMAIL PROTECTED]> Subject: Re: Mersenne: Fw: numeric hazards of high performance CPU design => Pentium 4 - constant speed problem Hi, At 04:52 PM 5/19/2001 +0100, Chris Jefferson wrote: >I just felt I had to say, that I am very disturbed by this. The idea of my >CPU simply shutting down when it overheats is a sensible idea. This is >much more dodgy, espicaly as there doesn't seem to be any way of finding >out, short of lots of benchmarks, if your processor is doing this... :-( Although I've not run LL tests for extended periods of times, I have never noticed the CPU throttling down by half. Time will tell if this is a significant problem or will only be seen in cheap P4 machines with inadequate cooling. Regards, George _________________________________________________________________________ Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers ------------------------------ Date: Sat, 19 May 2001 22:53:13 -0000 From: "Brian J. Beesley" <[EMAIL PROTECTED]> Subject: Re: Mersenne: Fw: numeric hazards of high performance CPU design => Pentium 4 - constant speed problem At 04:52 PM 5/19/2001 +0100, Chris Jefferson wrote: >I just felt I had to say, that I am very disturbed by this. The idea >of my CPU simply shutting down when it overheats is a sensible idea. >This is much more dodgy, espicaly as there doesn't seem to be any way >of finding out, short of lots of benchmarks, if your processor is >doing this... :-( Actually this is nothing new. My Toshiba Satellite 200 CDS (100 MHz Pentium P5, manufactured December 1996) even has a BIOS setting to let you either turn on an extra cooling fan or reduce the processor speed if required; and the manual states that, if the processor still gets too warm even with the fan running, the speed will be reduced anyway. The laptop system provides this option as a choice since the user may require continued (relatively) fast operation or may wish to maximize battery life (by not running the fan). Seems to make sense to me. In any case I'd rather have the processor slow down than cook itself to the point of system instability. What _is_ a concern is that the the CPU temperature sensor is appropriately positioned and calibrated so that the speed is reduced (thus reducing power consumption and therefore heat output) _before_ the limiting die temperature is reached, so that there is minimal risk of incorrect operation. I am far from convinced that this design criterion is always met. Also, many BIOSes allow the overheat throttle speed to be set to 100% - disabling this safety feature. In any case, CPU overheat throttling should be thought of as a hardware preservation device. Its presence is not an excuse for a lack of provision of proper cooling to the processor. The alternative of the system shutting down is viable, and achievable by BIOS configuration in all the recent systems I've seen (by setting the "throttled" speed to zero). In practise, this is likely to cause a total system crash; IMHO almost all users would rather the system limped on, possibly restoring itself to normal operation if the cause of the excess heating is removed, than simply ceasing to respond. Having said all that, a system which does exhibit thermal throttling almost certainly has either an inadequate heatsink, or grossly restricted airflow, or is operating in an unacceptably high ambient temperature. It should be possible to prevent thermal throttling by fixing one or more of these problems. BTW if you have Prime95 or mprime running with a displayed console window, reduced clock speed will be evident. Since the CPU clock _but not the memory bus speed_ will be reduced, the clocks per iteration will _fall_ to an unusually low level. However you should notice that the "per iteration time" no longer corresponds to real elapsed time between output lines. On 19 May 2001, at 16:24, George Woltman wrote: > > Although I've not run LL tests for extended periods of times, I have > never noticed the CPU throttling down by half. Time will tell if this > is a significant problem or will only be seen in cheap P4 machines > with inadequate cooling. It would be interesting to see if George has any data from his system as to any difference in steady-state CPU temperature depending on whether Prime95 is running the "old" x87 code, or the "new" SSE2 code; also whether he noticed any rise in CPU temperature as the SSE2 code has been improved in efficiency. If you read the article _carefully_ you will see that the author's chief concern is for the existing 0.18 micron fab 1.7GHz variant of the Pentium P4 processor. P4s rated at lower speeds will have a lower power consumption and are therefore less likely to overheat. In any case, one of the systems referred to in the text as sufferring from the "10 minute" performance drop was found to have a misaligned air duct which would reduce the processor cooling efficiency markedly. The article's conclusion is that customers requiring fast P4 systems may well find it worthwhile waiting for the 0.13 micron fab variants which will be coming online later this year - together with new Intel chipsets which support DDR SDRAM. I don't know for a fact whether there really is a problem with overheating in the 1.7GHz P4 for which there isn't an adequate heatsink; whether there is a quality control problem resulting in temperature sensors being set too sensitive to prevent _some_ installations from thermal _damage_; whether the cooling provided by the systems referred to in the article is deficient in design or construction; or whether the testing facility used by the authors of the article simply has too high an ambient temperature. However it is _certain_ that the processors built using 0.13 micron technology will consume less power at the same clock speed than existing 0.18 micron parts. BTW the existing 1.33 GHz Athlon is also quite close to the limit of what even the best heatsinks can cope with without the die temperature becoming critical. Though reducing the mask dimensions will continue to help for some time to come, we are in fact arriving at a crossroads in processor design. Sometime fairly soon, either a better way of extracting heat from the processor die has got to be found, or a different cooling system will be required. Or power consumption constraints will begin to limit the performance of "consumer" systems; this is my personal guess as to what will happen, since few people really need even the "throttled" performance of existing consumer CPUs. I wonder if it would be possible to market a high-performance desktop computer using evaporative cooling, and running mprime, as an office humidifier ;-> Regards Brian Beesley _________________________________________________________________________ Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers ------------------------------ Date: Sun, 20 May 2001 03:36:48 +0200 From: "Steinar H. Gunderson" <[EMAIL PROTECTED]> Subject: Mersenne: Re: numeric hazards of high performance CPU design => Pentium 4 - constant speed problem On Sat, May 19, 2001 at 10:53:13PM -0000, Brian J. Beesley wrote: >BTW if you have Prime95 or mprime running with a displayed console >window, reduced clock speed will be evident. Since the CPU clock _but >not the memory bus speed_ will be reduced, the clocks per iteration >will _fall_ to an unusually low level. However you should notice that >the "per iteration time" no longer corresponds to real elapsed time >between output lines. Hmmm... What do you mean by "a displayed console window"? An MS-DOS-window? I'm quite positive that mprime on Linux doesn't slow that much down when I open up a copy of /bin/sh, at least :-) /* 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: Sun, 20 May 2001 17:54:09 +0000 (GMT) From: Russel Brooks <[EMAIL PROTECTED]> Subject: Re: Mersenne: Fw: numeric hazards of high performance CPU,design => Pentium 4 - constant speed problem George Woltman wrote: > Although I've not run LL tests for extended periods of times, I would have thought Prime95's author was also a big user of it. Cheers... Russ _________________________________________________________________________ Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers ------------------------------ Date: Sun, 20 May 2001 16:58:59 US/Eastern From: [EMAIL PROTECTED] Subject: Mersenne: Pentium 4 (v21) George: What exponent ranges are fully optimized for P4 at this time? in the 4.5M range, my time is .018 sec on a 1.4 GHz. Is their a schedule for further releases. Is there a chance for further optimization for a P3? - --------------------------------------------- This message was sent using GSWeb Mail Services. http://www.gasou.edu/gsumail _________________________________________________________________________ Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers ------------------------------ Date: Sun, 20 May 2001 19:31:08 -0400 From: George Woltman <[EMAIL PROTECTED]> Subject: Mersenne: Re: Pentium 3 & 4 (v21) Hi, At 04:58 PM 5/20/2001 +0000, [EMAIL PROTECTED] wrote: >What exponent ranges are fully optimized for P4 at this time? All of them. I may be able to optimize a little bit more, but don't expect more than a few percent improvement. >Is their a schedule for further releases. No. If a bug is found in the beta you can expect a fix quickly. Otherwise, I'll do either one of two things: Add a few new bells and whistles, do some QA and release it soon OR take some extra time to add harder features and consequently release it later. >Is there a chance for further optimization for a P3? An interesting question.... Some of what I've learned about the P4's bottlenecks may apply to the P3 as well! I'll need to run some tests. If these tests are encouraging it might be possible to speed up the P3 code 25% (wild guess). One problem. I don't own a P3. Cheapskate that I am, I've looked at upgrading my overclocked Celeron 300A to a Celeron 600 (hopefully overclocking it to 900). I can do this for about $90 - not a bad deal at all. The Celeron 600 has the same internals as the P3 except for a smaller L2 cache. I'll keep y'all posted. Regards, George P.S. I'll also examine the Athlon docs so that any P3 optimizations will likely help there too. _________________________________________________________________________ Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers ------------------------------ Date: Mon, 21 May 2001 14:14:36 +0200 From: Alexander Kruppa <[EMAIL PROTECTED]> Subject: Re: Mersenne: ECM Question... Steve Phipps wrote: > > While we're on the subject, can someone explain how to derive the group > order for factors found using ECM? I've been carrying out ECM on an old PC > for almost a year now, and I'd like to be able to derive, and factorise, > the group orders for the factors that I've found. > > I've been making an effort to understand the maths, and I'm getting there > slowly, but I've found nothing yet that explains how to derive the group > orders. If my understanding is correct, you would need to know the > equations used by mprime to derive the co-ordinates of the starting point > for each curve. > > Anyway, if someone could explain how to derive the group order, or point > me in the right direction, I'd be very grateful. > > Regards, > Steve I'm by no means an expert on ECM, but let me try.. There seems to be a formula to compute the order of an elliptic curve over Z/p*Z, p prime, but that formula is afaik rather complicated to compute. What you can do when you want the order of a successful ECM curve is this: p is the factor of N that was found by the curve, go_p is the order of the curve and go_p(x) is the order of x in that curve. If a!=0 but a*q=0, q prime, then q is the group order of a and a factor of the order of the group. (0 is the neutral element here). You can run the sucessful ECM curve normally, but test for a factor after every multiplication with a prime q and see if the factor p is now found - if so, then q is a factor of the group order. Remember the q's and restart the curve, but multipliying the initial point x with all the q's to find smaller factors of the group order. A very informal algorithm might look like this: known_go = 1 restart: set x to the initial point x = x*known_go if gcd(x_z, N) > 1 print known_go, exit for all primes and prime powers q below bound B x = x * q if gcd(x_z, N) > 1 then known_go *= q, goto restart This will reveal the order of the initial point x. But we want the order of the group (go_p), not that of x (go_p(x)). However we know that that gp_p(x) | go_p, and p+1-sqrt(p) <= go_p <= p+1+sqrt(p) . Since go_p(x) is usually much larger than 2*sqrt(p), the second equation has only one solution in integer k if you replace go_p by k*go_p(x). Find the correct k, i.e. by trunc((p+1+sqrt(p)) / go_p(x)), and k*go_p(x) is the group order you wanted. I once tried this with the mprime ecm code and actually were able to verify the known group orders of some factors, but I never really cleaned up and debugged the code - for example, you cant stop and restart the go run, and after the run all the internal variables are probably not restored cleanly enough to continue with regular curves, etc. If there is interest in this code, I'll try to clean it up enough to make it more or less suitable for public display - provided George has no objection to spreading a modified version of his code. Ciao, Alex. _________________________________________________________________________ Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers ------------------------------ Date: Mon, 21 May 2001 14:24:27 +0200 From: Alexander Kruppa <[EMAIL PROTECTED]> Subject: Re: Mersenne: Another ECM question Nathan Russell wrote: > > Is it (at least) theoretically possible that some larger factors are > unfindable with ECM due to the limited number of sigma producable by > George's random number generator? > > Nathan I dont think this is a problem. Limits in the RNG would only mean problems if it causes many sigmas to be duplicated and the chance of getting a fresh, yet untested sigma decreases substantially. The RNG in Prime95 produces up to 16-digit numbers, and if the number of curves you try stays well below the square root of the number of possible values the RNG produces, then the chance of a duplicate sigma is negligible. For Prime95, if you test less than 10^8 curves on one number, you're safe. If you have to test more than a hundred million curves, then ECM is not the proper algorithm for finding that particular factor, anyways. Ciao, Alex. _________________________________________________________________________ Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers ------------------------------ Date: Mon, 21 May 2001 18:39:18 -0000 From: "Brian J. Beesley" <[EMAIL PROTECTED]> Subject: Mersenne: Delayed startup Hi, linux users should have no problem automatically starting mprime with a delay. Just stick "sleep n && " in front of whatever command you use to start mprime; this will cause a delay of n seconds before mprime starts up. For Windows users (Win 9x/ME/NT/2000), I have written a small program which delays n seconds ( 0 < n <= 300 ) then runs an arbitary command. Download (18.6 KBytes) ftp://lettuce.edsc.ulst.ac.uk/gimps/software/DelayRun.zip unpack it & move the executable to some folder mentioned in your execution path - C:\Windows\Command works on most Win 9x systems. Then change the command line (but nothing else) in the shortcut in the startup folder which causes Prime95 to run; precede the existing command with "DelayRun n ", (NB the quotes are not needed, but the spaces are!) where n is the number of seconds you want to elapse before Prime95 is started. DelayRun may be used to launch _any_ program after a suitable delay. It remains resident until the invoked command terminates, but will consume no resources. I'd prefer to avoid that, but the C library on my old version of Visual C++ seems to be broken & the "exec" family of routines doesn't work as advertised. If it is invoked with a "ridiculous" delay interval or no command follows, DelayRun simply prints usage hints and exits. Note that the total maximum length of the command line is 127 characters. Apart from that, there should be no limitations on the use of the DelayRun program. I have placed the program in the public domain, waiving all intellectual property rights. I hope that DelayRun will be of some use to those requiring this facility pending the release of a version of Prime95 with a built-in startup delay option. Regards Brian Beesley _________________________________________________________________________ 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 #855 ******************************
