I've been running Prime95 for 5 years on 4 different W-98 and W-XP machines and even with my sons playing intense graphic video games I and they have never noticed it interfering with whatever we are doing. That's not to say there aren't apps it might interfere with; I've just not had the "pleasure". Now there have been times when my sons did complain their game was "lagging" and to humor them I have temporarily stopped Prime95 but I don't recall it making a difference. It turned out the delays were from other sources such as the game server they were interfacing with. Don't take this the wrong way, but it makes me wonder how many of your friends "performance impacts" were real and in how many cases Prime95 was a convenient scapegoat.
Wayne ----- Original Message ----- From: [EMAIL PROTECTED] Date: Friday, October 27, 2006 7:32 am Subject: Prime Digest, Vol 30, Issue 22 > Send Prime mailing list submissions to > [email protected] > > To subscribe or unsubscribe via the World Wide Web, visit > http://hogranch.com/mailman/listinfo/prime > or, via email, send a message with subject or body 'help' to > [EMAIL PROTECTED] > > You can reach the person managing the list at > [EMAIL PROTECTED] > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of Prime digest..." > > > Today's Topics: > > 1. Re: AMD Athlons (Hugh S. Myers) > 2. Re: reason a LL-test goes wrong (Was: Curious recent GIMPS > member) (david eddy) > 3. Re: AMD Athlons (John R Pierce) > 4. Re: reason a LL-test goes wrong (Was: Curious recent GIMPS > member) (Steinar H. Gunderson) > 5. Re: reason a LL-test goes wrong (Was: Curious recent GIMPS > member) (david eddy) > 6. Possible method to get more prime-searching participants > online (Moreton, Peter) > 7. Re: reason a LL-test goes wrong (Was: Curious recent GIMPS > member ) (Brian Beesley) > 8. AMD cpu types (Lars Geisler) > 9. Re: Possible method to get more prime-searching participants > online (jay ball) > 10. Re: Possible method to get more prime-searching > participantsonline (Jeremy Blosser) > > > ------------------------------------------------------------------- > --- > > Message: 1 > Date: Thu, 26 Oct 2006 13:31:24 -0600 > From: "Hugh S. Myers" <[EMAIL PROTECTED]> > Subject: Re: [Prime] AMD Athlons > To: "'The Great Internet Mersenne Prime Search list'" > <[email protected]> > Message-ID: <[EMAIL PROTECTED]> > Content-Type: text/plain; charset="US-ASCII" > > When you say Athlon, which chip are you talking of? AMD has a slew of > them... > > --hsm > P.s. for instance the last I heard (not current) the 64bit AMD > chips were > called Opterons... > > > -----Original Message----- > > From: [EMAIL PROTECTED] > > [EMAIL PROTECTED] On Behalf Of Jason Clements > > Sent: Thursday, October 26, 2006 12:47 PM > > To: The Great Internet Mersenne Prime Search list > > Subject: [Prime] AMD Athlons > > > > > > I've just got a shiny new Athlon 64 at work (running XP), > > replacing an extremely tired P3. > > > > It now seems to be tearing through the factorisations I'd > > limited the P3 to, in 3 or 4 days instead of c 6 weeks. > > > > I've upgraded to v24.14 for yet more speed - am I right in > > thinking this is the best version of Prime95 for this machine/OS ? > > > > Thanks > > Jason > > _______________________________________________ > > Prime mailing list > > [email protected] > > http://hogranch.com/mailman/listinfo/prime > > > > > > ------------------------------ > > Message: 2 > Date: Thu, 26 Oct 2006 21:26:01 +0000 > From: david eddy <[EMAIL PROTECTED]> > Subject: Re: [Prime] reason a LL-test goes wrong (Was: Curious recent > GIMPS member) > To: <[email protected]> > Message-ID: <[EMAIL PROTECTED]> > Content-Type: text/plain; charset="iso-8859-1" > > > > > > david eddy wrote: > > > The important reason a LL-test goes wrong is due to > > > using floating point FFT to perform exact integer arithmetic. > > > > Richard Woods wrote > > No, that's not it. > > ....... > > Yes thank you. > > It figures that if one iteration has a non-sero probability of > rounding error > then 30,000,000 of them will have 100% error rate. > > So the gradual increase in error rate with exponent size (which > would make choosing ~30% > errror rate as the optimum) does not apply. We have effectively > got a step function. > The range for a given FFT size chooses itself. > > David Eddy > > > _________________________________________________________________ > Be one of the first to try Windows Live Mail. > http://ideas.live.com/programpage.aspx?versionId=5d21c51a-b161- > 4314-9b0e-4911fb2b2e6d > > > ------------------------------ > > Message: 3 > Date: Thu, 26 Oct 2006 14:27:14 -0700 > From: John R Pierce <[EMAIL PROTECTED]> > Subject: Re: [Prime] AMD Athlons > To: The Great Internet Mersenne Prime Search list <[email protected]> > Message-ID: <[EMAIL PROTECTED]> > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > Hugh S. Myers wrote: > > >When you say Athlon, which chip are you talking of? AMD has a > slew of > >them... > > > >--hsm > >P.s. for instance the last I heard (not current) the 64bit AMD > chips were > >called Opterons... > > > > > > the opterons are the SERVER versions of the Athlon 64. The Athlon > 64 > (which he specifically mentioned) is the Athlon 64bit desktop > version. Opteron 2XX models are for dual socket servers, and > 8xx > models are for 4 or 8 socket servers. There's also been an > Opteron > 1XX, which is indistinguishable from a particular high end Athlon > 64 XP > version (or something like that). > > AMD's version identification gets pretty confusing after that, > with > different versions of the "Athlon 64 3200+" coming out at > different > times, etc. To really narrow it down, you need to know the chip > version > (code names like San Diego, Venice, etc), the actual core clock > speed, > the cache size, and the fabrication version (1.3uM, 90nM, etc). > > > ------------------------------ > > Message: 4 > Date: Fri, 27 Oct 2006 02:15:49 +0200 > From: "Steinar H. Gunderson" <[EMAIL PROTECTED]> > Subject: Re: [Prime] reason a LL-test goes wrong (Was: Curious recent > GIMPS member) > To: [email protected] > Message-ID: <[EMAIL PROTECTED]> > Content-Type: text/plain; charset=utf-8 > > On Thu, Oct 26, 2006 at 09:26:01PM +0000, david eddy wrote: > > It figures that if one iteration has a non-sero probability of > rounding error > > then 30,000,000 of them will have 100% error rate. > > You seem to be assuming that > > a) all iterations will have the same probability of rounding > error, and that > b) the probabilities are independent. > > I'm not sure if I want to accept any of those off-hand, especially > as the end > result doesn't go well with real-life data. > > /* Steinar */ > -- > Homepage: http://www.sesse.net/ > > > ------------------------------ > > Message: 5 > Date: Fri, 27 Oct 2006 02:31:48 +0000 > From: david eddy <[EMAIL PROTECTED]> > Subject: Re: [Prime] reason a LL-test goes wrong (Was: Curious recent > GIMPS member) > To: The Great Internet Mersenne Prime Search list <[email protected]> > Message-ID: <[EMAIL PROTECTED]> > Content-Type: text/plain; charset="iso-8859-1" > > > > On Thu, Oct 26, 2006 at 09:26:01PM +0000, david eddy wrote: > > > It figures that if one iteration has a non-sero probability > of rounding error > > > then 30,000,000 of them will have 100% error rate. > > > > > You seem to be assuming that > > > > a) all iterations will have the same probability of rounding > error, and that > > b) the probabilities are independent. > > > > I'm not sure if I want to accept any of those off-hand, > especially as the end > > result doesn't go well with real-life data. > > > > /* Steinar */ > > This was not a proposition from Wittgenstein:) > > Under very general assumptions: > The chance of 30,000,000 successful iterations is zilch unless each > iteration is practically a certainty. > > The point I have been trying to make is that IF the probability of an > erroneous LLtest for a particular exponent were say 5% for a > particularFFT length, then it would cost more time to test and > check it using a > 20% larger FFT (with negligible chance of error). > We may still prefer not to risk the 5% chance of error on a first time > LL test, but anyway the number of exponents involved in the debate > is negligible since the chance of error rises so abruptly from > zero to 100% > > David Eddy > _________________________________________________________________ > Be one of the first to try Windows Live Mail. > http://ideas.live.com/programpage.aspx?versionId=5d21c51a-b161- > 4314-9b0e-4911fb2b2e6d > > > ------------------------------ > > Message: 6 > Date: Fri, 27 Oct 2006 09:41:42 +0200 > From: "Moreton, Peter" <[EMAIL PROTECTED]> > Subject: [Prime] Possible method to get more prime-searching > participants online > To: "The Great Internet Mersenne Prime Search list" > <[email protected]> > Message-ID: > <[EMAIL PROTECTED]> > Content-Type: text/plain; charset="utf-8" > > I'd like to preface this email with "IMHO" :-) > > Lot's of folk I have talked with about Prime95 have installed P95 > on their desktop, and then de-installed it due to the performance > impact it had on the machine as a whole. Even though the P95 > process runs at a low scheduler priority, it still uses 100% of > the available CPU (obviously!), and can leave XP 'gasping for > breath'. Basically, the XP scheduler is not that clever at > maintaining responsiveness of forground apps when low priority > tasks exist that are compute-bound. > > I was wondering if George W might consider including some extra > logic in the next version of P95 to cause it to 'back-off' the CPU > under some circumstances. One might define a configuration flag to > turn on this feature, say 'niceflag' meaning 'be nice to the other > processes'. > Various approaches could be used and I'll propose just one: > > if (keyboard OR mouse activity) AND (niceflag=true) > { > sleep 100msec // Let the forground > app have unhindered access to the CPU for 1/10th sec > } > > (OpenVMS hackers will remember a similar feature of the scheduler > called "priority boosting" which occured when a task completed a > terminal I/O. This feature maintained responsiveness to user > applications when the CPU was saturated) > > regards, peter moreton > > > > > > > ------------------------------ > > Message: 7 > Date: Fri, 27 Oct 2006 08:12:25 +0000 > From: Brian Beesley <[EMAIL PROTECTED]> > Subject: Re: [Prime] reason a LL-test goes wrong (Was: Curious recent > GIMPS member ) > To: The Great Internet Mersenne Prime Search list <[email protected]> > Message-ID: <[EMAIL PROTECTED]> > Content-Type: text/plain; charset="iso-8859-1" > > On Friday 27 October 2006 02:31, david eddy wrote: > > > > > > You seem to be assuming that > > > > > > a) all iterations will have the same probability of rounding > error, and > > > that b) the probabilities are independent. > > > > > > I'm not sure if I want to accept any of those off-hand, > especially as the > > > end result doesn't go well with real-life data. > > > > > > /* Steinar */ > > > > Under very general assumptions: > > The chance of 30,000,000 successful iterations is zilch unless each > > iteration is practically a certainty. > > Given allowance for imprecise wording this statement is pretty > well accurate. > > However the unit is actually not per iteration but per floating > point > operation. > > The number of floating point operations per iteration is a step > function as it > is dependent on the FFT run length, but is clearly comparable to > the number > of iterations per L-L test. > > So th number of places that an error can occur, for an exponent > around > 30,000,000, is something of the order of 10^15. (Yeah, there's a > multiplier > in there, and a complication caused by the FFT being done in > multiple phases > for various reasons e.g. memory organisation, but I think you > should get my > drift.) > > So, if e is the error rate per floating point operation, then the > probability > of the L-L test being correct is of the order of (1-e)^(p^2). > Which, as David > points out, tends to zero very rapidly as e increases from > infinitesimal > values. > > Coming back to Steiner's point (a), the uniformity of rounding > error rate > across all iterations is clearly incorrect. You can pick a > ludicrously small > FFT run length and still get away without errors in the first few > iterations > - because we start with a small number (4) it takes of the order > of log (run > length) iterations before rounding errors _can_ occur. > > As for (b); this is also an unfounded assumption though I'm not > sure it's > important except for exact calculation of the relative probability > of an > error in an operation affecting the result for an iteration and/or > the final > result. > > Which is something of a moot point. > > Accuracy of a FFT convolution seems to be dependent on the > distribution of 0 & > 1 bits in the mantissae of the floating-point elements of the > deconvoluted > work vector being "not too random". If there is a totally random > distribution > then sometimes the transformations will run into rounding errors & > sometimes > they won't. If we pick a sufficiently large run length & run a few > thousand > iterations we can start to examine the raw rounding errors as the > difference > between floating-point values as stored and the nearest integer > (we know the > deconvoluted values _must_ be integers). Then, with the experience > we have, > we can say that if the average rounding error is less than a > critical value, > it is unlikely that we have rounded any FP values to the wrong > integer (which > is the true cause of the rounding error). > > If we find the average error is too high then the best thing to do > is to > abandon and start again with the next bigger run length. > > This computation is expensive so we save time by omitting it for > exponents > which are well below the sane upper bound for a particular run length. > > > > The point I have been trying to make is that IF the probability > of an > > erroneous LLtest for a particular exponent were say 5% for a > particular> FFT length, then it would cost more time to test and > check it using a > > 20% larger FFT (with negligible chance of error). > > We may still prefer not to risk the 5% chance of error on a > first time > > LL test, but anyway the number of exponents involved in the debate > > is negligible since the chance of error rises so abruptly from > zero to 100% > > Sure, but with all the work which has been done (including > analysis of many, > many actual results where roundoff errors were detected and > corrected as well > as results which were apparently OK) the selection of run length > for optimum > performance is still something of an art rather than a science. If > we plot > average, or maximum observed, rounding error at, say, iteration > 1000 against > exponent for a fixed (but reasonable) run length, we do not get a > smooth > monotonic rise, as logic would expect - rather a graph suggestive > of white > noise superimposed on an exponentially rising trend line (but > clipped at > y=0.5 because of the way the error is measured!). For a small > range of > exponents, even around the FFT run length cutoff point, the > "noise" actually > dominates the underlying trend. > > I'm not saying that a modest efficiency improvement couldn't be > achieved by > tinkering with (generally reducing) run length cutoffs. However I > believe > that anything which could be done would be marginal to the project > as a whole > - well under 1% - and could easily be offset by the psychological > effect on > users of returning excess "bad" results for reasons outside their > control. > Regards > Brian Beesley > > > ------------------------------ > > Message: 8 > Date: Fri, 27 Oct 2006 09:51:58 +0200 > From: Lars Geisler <[EMAIL PROTECTED]> > Subject: [Prime] AMD cpu types > To: The Great Internet Mersenne Prime Search list <[email protected]> > Message-ID: <[EMAIL PROTECTED]> > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > Hi - from www.cpuid.com/cpuz.php you can download a small program > that > identifies your cpu with all details. > Best regards > > Lars Geisler > > > > > ------------------------------ > > Message: 9 > Date: Fri, 27 Oct 2006 07:05:04 -0400 > From: jay ball <[EMAIL PROTECTED]> > Subject: Re: [Prime] Possible method to get more prime-searching > participants online > To: The Great Internet Mersenne Prime Search list <[email protected]> > Message-ID: <[EMAIL PROTECTED]> > Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed > > > On Oct 27, 2006, at 03:41, Moreton, Peter wrote: > > > I'd like to preface this email with "IMHO" :-) > > > > Lot's of folk I have talked with about Prime95 have installed > P95 > > on their desktop, and then de-installed it due to the > performance > > impact it had on the machine as a whole. Even though the P95 > > process runs at a low scheduler priority, it still uses 100% of > the > > available CPU (obviously!), and can leave XP 'gasping for > breath'. > > Basically, the XP scheduler is not that clever at maintaining > > responsiveness of forground apps when low priority tasks exist > that > > are compute-bound. > > > > I was wondering if George W might consider including some extra > > logic in the next version of P95 to cause it to 'back-off' the > CPU > > under some circumstances. One might define a configuration flag > to > > turn on this feature, say 'niceflag' meaning 'be nice to the > other > > processes'. > > This feature already exists. It's called "throttle" in the > configuration files. throttle=10 will pause for 10ms after each > iteration. You obtain a noticeable slowdown, and your "idle cpu" > will be at 80% (well, depending on your machine and ms). > > I use it for a different reason: the heat of the power brick on my > > laptop it quite noticeable. By adding the throttle, it can no > longer > fry eggs. > > I would love to see throttle moved onto one of the main > configuration > screens in the software; as opposed to its current buried in > undoc.txt status. > > There are other "be nice" items in undoc.txt too, such as "don't > run > when program X runs." > > so, your "IMHO" is more than an opinion, it's a feature. :-) > > -j > > > ------------------------------ > > Message: 10 > Date: Fri, 27 Oct 2006 08:31:34 -0500 > From: "Jeremy Blosser" <[EMAIL PROTECTED]> > Subject: Re: [Prime] Possible method to get more prime-searching > participantsonline > To: "'The Great Internet Mersenne Prime Search list'" > <[email protected]> > Message-ID: <[EMAIL PROTECTED]> > Content-Type: text/plain; charset="us-ascii" > > Hmm... just an idea, but why not a "screensaver mode"? > > > -----Original Message----- > > From: Moreton, Peter [EMAIL PROTECTED] > > Sent: Friday, October 27, 2006 2:42 AM > > To: The Great Internet Mersenne Prime Search list > > Subject: [Prime] Possible method to get more prime-searching > > participantsonline > > > > I'd like to preface this email with "IMHO" :-) > > > > Lot's of folk I have talked with about Prime95 have installed > P95 on their > > desktop, and then de-installed it due to the performance impact > it had on > > the machine as a whole. Even though the P95 process runs at a low > > scheduler priority, it still uses 100% of the available CPU > (obviously!),> and can leave XP 'gasping for breath'. Basically, > the XP scheduler is not > > that clever at maintaining responsiveness of forground apps when low > > priority tasks exist that are compute-bound. > > > > I was wondering if George W might consider including some extra > logic in > > the next version of P95 to cause it to 'back-off' the CPU under some > > circumstances. One might define a configuration flag to turn on this > > feature, say 'niceflag' meaning 'be nice to the other processes'. > > > > Various approaches could be used and I'll propose just one: > > > > if (keyboard OR mouse activity) AND (niceflag=true) > > { > > sleep 100msec // Let the > forground app have > > unhindered access to the CPU for 1/10th sec > > } > > > > (OpenVMS hackers will remember a similar feature of the > scheduler called > > "priority boosting" which occured when a task completed a > terminal I/O. > > This feature maintained responsiveness to user applications when > the CPU > > was saturated) > > > > regards, peter moreton > > > > > > > ------------------------------ > > _______________________________________________ > Prime mailing list > [email protected] > http://hogranch.com/mailman/listinfo/prime > > > End of Prime Digest, Vol 30, Issue 22 > ************************************* > _______________________________________________ Prime mailing list [email protected] http://hogranch.com/mailman/listinfo/prime
