Mersenne Digest Monday, June 25 2001 Volume 01 : Number 864 ---------------------------------------------------------------------- Date: Fri, 22 Jun 2001 02:08:31 -0700 From: "John R Pierce" <[EMAIL PROTECTED]> Subject: Re: Mersenne: Good news for Pentium 3 and Celeron 2 owners > I feel it is ridiculous that George has to beg/borrow the latest > architecture in order to optimise Prime95. I also know from being a member > of the prime search community for the last three years the amount of hard > work George puts into the project. agreed. how come AMD isn't burying George in processors so he can better optimize for their architecture? _________________________________________________________________________ Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers ------------------------------ Date: Fri, 22 Jun 2001 06:23:14 -0400 (EDT) From: Kel Utendorf <[EMAIL PROTECTED]> Subject: Re: Mersenne: Good news for Pentium 3 and Celeron 2 owners On Fri, 22 Jun 2001, John R Pierce wrote: >> I feel it is ridiculous that George has to beg/borrow the latest >> architecture in order to optimise Prime95. I also know from being a member >> of the prime search community for the last three years the amount of hard >> work George puts into the project. > >agreed. how come AMD isn't burying George in processors so he can better >optimize for their architecture? Sounds like a good idea to me. I've long been impressed by the amount of work that George puts into this project, and would be very willing to contribute a few bucks so that we could purchase the needed hardware to further the project. The members of Team Anandtech have often contributed money and/or hardware to various things. I believe they supplied the $$$ and hardware for the team's personal proxy server for their distributed.net efforts, and have contributed to at least one "game box" for the team members. Why can't we do something similar? Of course, George would have to find the time to do all of this wonderful new coding...;-) Kel _________________________________________________________________________ Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers ------------------------------ Date: Fri, 22 Jun 2001 13:12:41 US/Eastern From: [EMAIL PROTECTED] Subject: Mersenne: Factoring on a P4 For some reason, I am at a loss to explain, a v21 P4 1.4 GHz factors significantely slower that a P3 v20 700MHz. Is there a reason, and solution, for this? Bradford J. Brown - --------------------------------------------- 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: Fri, 22 Jun 2001 18:46:43 -0000 From: "Brian J. Beesley" <[EMAIL PROTECTED]> Subject: Re: Mersenne: Factoring on a P4 On 22 Jun 2001, at 13:12, [EMAIL PROTECTED] wrote: > For some reason, I am at a loss to explain, a v21 P4 1.4 GHz factors > significantely slower that a P3 v20 700MHz. Is there a reason, and > solution, for this? Good question. AFAIK George has done nothing to the factoring code. You will see a big "speed loss" if you compare factoring under 2^64 with factoring over 2^64 on _any_ system - that's simply explained by triple- precision integer arithmetic being much slower than double-precision integer arithmetic. Intel's development for the P4 was very much geared towards making SSE2 work well. Unfortunately this left less room in the silicon for some of the "ordinary" integer stuff on which the factoring code (but not the LL testing code) in Prime95 depends. If memory serves me right, the 32 bit by 32 bit integer multiply instruction was badly hit by this. Consequently the factoring throughput of a P4 would be expected to be considerably less than that of a PIII running at the same clock speed. I would expect that a PIII-700 and a P4-1400 would probably run factoring at about the same speed. For now, those who are lucky enough to have P4 systems are probably best advised to stick to LL testing (and trial factoring - which will not be affected by any inefficiency in the P4 integer instructions), leaving trial factoring to those with slower systems. Conversely, if you need a system with optimal integer performance, you'd be much better advised to buy a system based on a fast Athlon processor than a system based on a Pentium 4. Athlons running integer code even run much cooler; the FPU turns itself off when it isn't needed, leading to a big drop in current consumption. BTW there was an "unreasonable" acceleration of trial factoring between the P5 architecture (Pentium Classic/MMX) and the P6 architecture (Pentium Pro / PII / PIII / Celeron / Xeon), so you can't simply assume that Intel doesn't care about integer performance! Regards Brian Beesley _________________________________________________________________________ Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers ------------------------------ Date: Fri, 22 Jun 2001 12:14:51 -0700 From: "Milton Brown" <[EMAIL PROTECTED]> Subject: Mersenne: Fw: [PrimeNumbers] AMD vs. Intel Floating Point - ----- Original Message ----- From: "Milton Brown" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Cc: "Milton Brown" <[EMAIL PROTECTED]> Sent: Friday, June 22, 2001 7:36 AM Subject: [PrimeNumbers] AMD vs. Intel Floating Point > The prime number group, might be interested in > these timings. > > Milton L. Brown > ----- Original Message ----- > From: "Jens-Peer Kuska" <[EMAIL PROTECTED]> > To: <[EMAIL PROTECTED]> > Sent: Thursday, June 21, 2001 11:20 PM > Subject: [mg29486] Re: AMD vs. Intel Floating Point > > > > Hi, > > > > a) the Mathematica speed comparsion from > > > > http://fampm201.tu-graz.ac.at/karl/timings40.html > > > > is posted regular in this news group > > b) on the www-site of *this* news group > > > > http://smc.vnet.net/mathgroup.html > > > > the second head line is a link to various speed > > comparsions found at > > > > http://smc.vnet.net/mathbench.html > > > > and it is quite natural to assume, that a poster to a > > news-group has visited the newsgroup hompage and > > is able to read and understand the headings on a page > > that begins with: > > > > ----------------------------------------------------------- > > >Designed by S. Christensen. > > > > > >MathGroup > > > > > >The Email Group for Mathematica Users > > > > > >Comparison of Mathematica on Various Computers > > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > > > > >MathGroup is now linked to the moderated newsgroup > > > > > >comp.soft-sys.math.mathematica > > > > > > on the Internet. Contact your local system administrator > > > to find out how to read this new group. > > ----------------------------------------------------------- > > > > *and* it is quite natural to assume that a poster to the news group > > has read the group rules (on the same page) one of it say: > > > > >PLEASE SEARCH THE ARCHIVES BEFORE YOU ASK WHAT MIGHT BE A COMMON > QUESTION. > > >See the links above for this. > > > > It must be also sayed, that the Mathematica speed depends in the > > most (symbolic) applications not on the floating point power > > of the CPU. The most actions performed by Mathematica are pointer > > operations with it's internal data structures. I would assume that > > 80-90 % of Mathematica's CPU load are pure interger operations. > > High precision calculations, symbolic operations, operations with > > integers, rationals ... all that don't use the floating point hardware. > > > > It depends shaply on the application how much floating point operations > > are used. But when a Mathematica function has such a huge floating > > point > > load it is always better to write a MathLink program. > > > > Regards > > Jens > > > > > > > > Morfeas79a wrote: > > > > > > Kofi > > > as it is well known the AMD processors up untill the model of K6-3D > > > have serious problems in their floating point operations - this can be > > > observed by running programs with great CPU load like SETI@home, the > > > time for a AMD computer to finish one work unit is about twice as big > > > as this in an Intel computer running on the same MHz. The problem has > > > been solved in later models. Of course all this is not known to > > > Mr.Kuska who thinks that 90% of the questions sent in this newsgroup > > > are of trivial nature or in anycase foolish. > > > > > > Regards > > > Jim > > > > > Unsubscribe by an email to: [EMAIL PROTECTED] > The Prime Pages : http://www.primepages.org > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/ > > _________________________________________________________________________ Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers ------------------------------ Date: Fri, 22 Jun 2001 21:15:47 +0000 (GMT) From: Russel Brooks <[EMAIL PROTECTED]> Subject: Mersenne: Donations Lawrence Cairns-Smith wrote: > I therefore suggest that a pay pal account (or similar) is set up. People > who wished could easily donate a few dollars to make sure that George has > available to him the latest architecture. I mean, come on, it wouldn't take Sounds good to me. While we're discussing donations let me suggest something similar. I just received the latest newsletter from the Electronic Frontier Foundation. http://www.eff.org In it they were asking for pc donations. If we could donate a pc we could also request that it (and maybe the rest of their pcs) run Gimps. Since EFF also sponsors a prime related prize this seem like a logical group to support. A mention in their newsletter would also be good advertising for Gimps. Cheers... Russ _________________________________________________________________________ Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers ------------------------------ Date: Fri, 22 Jun 2001 13:42:04 -0800 (AKDT) From: Gordon Bower <[EMAIL PROTECTED]> Subject: Mersenne: Proth observations After seeing a post on this list a few weeks ago I decided to branch out and try a few ranges from Michael Hartley's page looking for k*2^n-1 primes. I must say there is a bit of a thrill in actually discovering a new prime every day I run the program instead of proving two numbers a month composite. :) Anyway, a few curious observations I made, which surprised me: I have 2 computers, a P2-350 and P3-500. The program executes nearly 2 1/2 times as fast on the latter as on the former with nothing else running. Apparently the Proth code takes advantage of a lot of P3 features? With the same version of prime95 and the same version of proth on each computer, if you run them both at the same time, under Win2000 proth gets a higher priority and all the processing power, while under NT4, it's the other way round, and prime95 has to be stopped or have its priority reduced in the ini file to not smother proth. Curious. (Why run them both at once, you ask? If the computer is going to be on all night anyway, it'd be idle when proth finished a range unless prime95 was ready to take over as soon as proth was done.) I assumed that one value of k was pretty much the same as any other as far as execution time and the chance of finding primes. To my surprise this turned out not to be so: On the P3-500, for "most" 650<k<750, it takes about 5 hours for 16000<n<32000 and 12 hours for 32000<n<48000 -- but for k=701 it took less than 2 and just over 6 hours, respectively. The phenomenon is reproducible, doesn't seem to be an artifact of other programs or reboots or suchlike. Any number theorists care to explain what is special about k=701 that makes it easy to check for primality? A fun project. Now if Michael would just put a stop to that pesky server error I could submit a half dozen more primes to him... :) GRB _________________________________________________________________________ Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers ------------------------------ Date: Fri, 22 Jun 2001 18:25:14 -0400 From: George Woltman <[EMAIL PROTECTED]> Subject: Re: Mersenne: Proth observations Hey Gordon, At 01:42 PM 6/22/2001 -0800, Gordon Bower wrote: >After seeing a post on this list a few weeks ago I decided to branch out >and try a few ranges from Michael Hartley's page looking for k*2^n-1 >primes. >Anyway, a few curious observations I made, which surprised me: >I have 2 computers, a P2-350 and P3-500. The program executes nearly 2 1/2 >times as fast on the latter as on the former with nothing else >running. Apparently the Proth code takes advantage of a lot of P3 >features? You should look into newpgen and prp.exe. These two programs can be used to speed up your search for k*2^n+/-1 primes. >With the same version of prime95 and the same version of proth on each >computer, if you run them both at the same time, under Win2000 proth gets >a higher priority and all the processing power, while under NT4, it's the >other way round, and prime95 has to be stopped or have its >priority reduced in the ini file to not smother proth. Curious. Windows NT and Win2000 users should consider changing prime95's priority to two. There have been reports that idle priority doesn't work as documented in the Microsoft documentation. Regards, George _________________________________________________________________________ Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers ------------------------------ Date: Fri, 22 Jun 2001 23:45:46 +0100 From: "Michael Bell" <[EMAIL PROTECTED]> Subject: Re: Mersenne: Factoring on a P4 > BTW there was an "unreasonable" acceleration of trial factoring > between the P5 architecture (Pentium Classic/MMX) and the P6 > architecture (Pentium Pro / PII / PIII / Celeron / Xeon), so you > can't simply assume that Intel doesn't care about integer > performance! But they clearly don't care about it on the P4: Command Ticks on P2/P3 Ticks on P4 MOV 1 1 ADD/SUB 1 1 ADC/SBB 2 8 MUL 4 14-18 SHR/SHL 1 4 Michael. _________________________________________________________________________ Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers ------------------------------ Date: Fri, 22 Jun 2001 19:32:46 -0400 From: George Woltman <[EMAIL PROTECTED]> Subject: Mersenne: OT: P4 latencies Hi, At 11:45 PM 6/22/2001 +0100, Michael Bell wrote: >But they clearly don't care about it on the P4: > >Command Ticks on P2/P3 Ticks on P4 >MOV 1 1 >ADD/SUB 1 1 >ADC/SBB 2 8 >MUL 4 14-18 >SHR/SHL 1 4 Evaluating an architecture based on just latencies can be very misleading. For example the P4 has longish latencies on the SSE2 instructions that prime95 uses (6 for a load, 6 for a mul, 4 for an add). However, there is enough parallelism available that these latencies are almost completely hidden. Other architecture features that may well be more important: Cache structure & memory bandwidth Number of registers (to help programmer expose parallelism) Branch prediction and miss penalties. And many, many more. That said, the Athlon is a better performer for most applications today. The P4 was designed for higher clock speeds and memory bandwidth. Time will tell if Intel can ramp up the CPU speed to offset the Athlon's advantages. Regards, George _________________________________________________________________________ Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers ------------------------------ Date: Fri, 22 Jun 2001 19:38:43 -0400 From: George Woltman <[EMAIL PROTECTED]> Subject: Re: Mersenne: Donations Hi all, At 09:15 PM 6/22/2001 +0000, Russel Brooks wrote: > > I therefore suggest that a pay pal account (or similar) is set up. People > > who wished could easily donate a few dollars to make sure that George has > > available to him the latest architecture. I mean, come on, it wouldn't take > >Sounds good to me. I prefer to keep GIMPs a truly free project. There is a GIMPS member in the Orlando area with an Athlon. IF I get up energy to try some Athlon specific improvements, he has volunteered his machine. Having gained 20+% and a gut feeling that there isn't much more to be gained easily, I don't think I'll be doing that at this time. Thanks for the offers of help! Have fun, George _________________________________________________________________________ Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers ------------------------------ Date: Sat, 23 Jun 2001 03:17:09 +0200 (MET DST) From: [EMAIL PROTECTED] Subject: Re: Mersenne: Proth observations Gordon Bower <[EMAIL PROTECTED]> observes > After seeing a post on this list a few weeks ago I decided to branch out > and try a few ranges from Michael Hartley's page looking for k*2^n-1 > primes. I must say there is a bit of a thrill in actually discovering a > new prime every day I run the program instead of proving two numbers a > month composite. :) > I assumed that one value of k was pretty much the same as any other as far > as execution time and the chance of finding primes. To my surprise this > turned out not to be so: On the P3-500, for "most" 650<k<750, it takes > about 5 hours for 16000<n<32000 and 12 hours for 32000<n<48000 -- but for > k=701 it took less than 2 and just over 6 hours, respectively. The > phenomenon is reproducible, doesn't seem to be an artifact of other > programs or reboots or suchlike. Any number theorists care to explain what > is special about k=701 that makes it easy to check for primality? > Fix k = 701. We check that If n == 1 (mod 2) then k*2^n == 1 (mod 3) If n == 0 (mod 4) then k*2^n == 1 (mod 5) If n == 6 (mod 8) then k*2^n == 1 (mod 17) If n == 0 (mod 3) then k*2^n == 1 (mod 7) Therefore k*2^n - 1 can be prime only if n == 2 or 10 (mod 24). We can eliminate more potential values of n using If n == 8 (mod 18) then k*2^n == 1 (mod 19) If n == 18 (mod 20) then k*2^n == 1 (mod 41) If n == 6 (mod 28) then k*2^n == 1 (mod 29) Some congruences are redundant; for example If n == 6 (mod 12) then k*2^n == 1 (mod 13) eliminates nothing new. k = 701 has less such redundancy than the typical k. _________________________________________________________________________ Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers ------------------------------ Date: Fri, 22 Jun 2001 21:05:25 -0600 From: "Aaron Blosser" <[EMAIL PROTECTED]> Subject: Re: Mersenne: Proth observations > Windows NT and Win2000 users should consider changing prime95's priority > to two. There have been reports that idle priority doesn't work as documented > in the Microsoft documentation. I'd be curious about that... I haven't heard anything, but then I haven't looked either. :) As I've said before, the only time I've ever seen an actual program run slower when Prime95/NT was running is when I'm running any sort of video capture, such as NetMeeting. NetMeeting vid conferences just run DOG slow when I have my ntprime going, but if I stop the service, then the video picks up greatly. I figured that perhaps the codec just ran at idle priority also (which would make sense to me anyway), so you have two CPU intensive things competing for resources... Aaron _________________________________________________________________________ Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers ------------------------------ Date: Fri, 22 Jun 2001 20:27:42 -0700 From: Eric Hahn <[EMAIL PROTECTED]> Subject: Re: Mersenne: Factoring on a P4 Bradford J. Brown wrote: >For some reason, I am at a loss to explain, a v21 P4 1.4 GHz >factors significantely slower that a P3 v20 700MHz. Is there a >reason, and solution, for this? Hmmm... Good question... AFAIK, the only change George has or is going to make in the factoring code since v19... is to change the Athlon over to use the P2/P3 code path... instead of the 486 code path... Doing such will allow Athlons to trial-factor 2.5-3x faster... There really isn't a whole lot more speed increase that can be gained from the factoring code as a whole, AFAIK... You will also notice a BIG speed decrease with trial-factoring on ANY machine as you move from factoring up to 2^62... to factoring up to 2^64... to factoring above 2^64... This is expected with the extra instructions necessary to handle the larger trial-factor sizes... Eric _________________________________________________________________________ Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers ------------------------------ Date: Sat, 23 Jun 2001 06:52:26 -0000 From: "Brian J. Beesley" <[EMAIL PROTECTED]> Subject: Re: Mersenne: Factoring on a P4 - CORRECTION - ------- Forwarded message follows ------- From: "Brian J. Beesley" <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] Date sent: Fri, 22 Jun 2001 18:46:43 -0000 Subject: Re: Mersenne: Factoring on a P4 Copies to: [EMAIL PROTECTED] On 22 Jun 2001, at 13:12, [EMAIL PROTECTED] wrote: > For some reason, I am at a loss to explain, a v21 P4 1.4 GHz > factors significantely slower that a P3 v20 700MHz. Is there a > reason, and solution, for this? Good question. AFAIK George has done nothing to the factoring code. You will see a big "speed loss" if you compare factoring under 2^64 with factoring over 2^64 on _any_ system - that's simply explained by triple- precision integer arithmetic being much slower than double-precision integer arithmetic. Intel's development for the P4 was very much geared towards making SSE2 work well. Unfortunately this left less room in the silicon for some of the "ordinary" integer stuff on which the factoring code (but not the LL testing code) in Prime95 depends. If memory serves me right, the 32 bit by 32 bit integer multiply instruction was badly hit by this. Consequently the factoring throughput of a P4 would be expected to be considerably less than that of a PIII running at the same clock speed. I would expect that a PIII-700 and a P4-1400 would probably run factoring at about the same speed. Earlier I wrote: For now, those who are lucky enough to have P4 systems are probably best advised to stick to LL testing (and trial factoring - which will not be affected by any inefficiency in the P4 integer instructions), leaving trial factoring to those with slower systems. Slip of the brain, I'm afraid. I meant "LL testing (and P-1 factoring..." Incidentally ECM ought to run pretty well on the P4, though there may be some more optimization to come for the very small run lengths typically used by ECM. Regards Brian Beesley _________________________________________________________________________ Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers ------------------------------ Date: Sat, 23 Jun 2001 08:24:24 -0000 From: "Brian J. Beesley" <[EMAIL PROTECTED]> Subject: Re: Mersenne: OT: P4 latencies At 11:45 PM 6/22/2001 +0100, Michael Bell wrote: > >But they clearly don't care about it on the P4: > > > >Command Ticks on P2/P3 Ticks on P4 > >MOV 1 1 > >ADD/SUB 1 1 > >ADC/SBB 2 8 > >MUL 4 14-18 > >SHR/SHL 1 4 There are other things in the P4 architecture which offset this to some extent. Nevertheless, as I said earlier, the P4 designers had performance criteria weighted differently. If they could have squeezed a couple of million more transistors onto the die, no doubt they could have got the integer instructions to operate faster. Note that the P4 was designed as a workstation processor. Processors designed for servers are likely to have a different performance weighting. I'd expect the Itanium to fly through integer work - the 64 bit register width doubles throughput instantly, of course. Actually my 3 year old Alpha 21164-533 is still a most impressive system for pure integer work, even though it has less memory bus bandwidth than many current 32-bit systems and is running at what is no longer an impressive clock speed. On 22 Jun 2001, at 19:32, George Woltman wrote: > That said, the Athlon is a better performer for most applications > today. The P4 was designed for higher clock speeds and memory > bandwidth. Time will tell if Intel can ramp up the CPU speed to offset > the Athlon's advantages. Both the 1.33 GHz Athlon and the 1.7 GHz P4 have maximum power consumptions in excess of 60W and are known to be hard to cool effectively. In fact the main reason the P4 can run faster is that the die is larger, giving more surface area to conduct heat away. Significantly faster parts are going to depend on reducing the power consumption; both AMD and Intel are planning to shift from 0.18 micron to 0.13 micron masks, which will help a lot in this respect. Intel are ahead months ahead of AMD in making the change to 0.13 micron technology; in fact I believe Intel may already be shipping 0.13 micron PIII "Tutalin" processors, though I don't know where to find motherboards which support the lower operating voltages required. Regards Brian Beesley _________________________________________________________________________ Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers ------------------------------ Date: Sat, 23 Jun 2001 08:24:24 -0000 From: "Brian J. Beesley" <[EMAIL PROTECTED]> Subject: Re: Mersenne: Proth observations On 22 Jun 2001, at 13:42, Gordon Bower wrote: > After seeing a post on this list a few weeks ago I decided to branch > out and try a few ranges from Michael Hartley's page looking for > k*2^n-1 primes. I must say there is a bit of a thrill in actually > discovering a new prime every day I run the program instead of proving > two numbers a month composite. :) Yes, it does make a change. > > Anyway, a few curious observations I made, which surprised me: > > I have 2 computers, a P2-350 and P3-500. The program executes nearly 2 > 1/2 times as fast on the latter as on the former with nothing else > running. Apparently the Proth code takes advantage of a lot of P3 > features? Yes, Proth 6.6 has prefetch code for PIII and Athlon CPUs. > > With the same version of prime95 and the same version of proth on each > computer, if you run them both at the same time, under Win2000 proth > gets a higher priority and all the processing power, while under NT4, > it's the other way round, and prime95 has to be stopped or have its > priority reduced in the ini file to not smother proth. Curious. (Why > run them both at once, you ask? If the computer is going to be on all > night anyway, it'd be idle when proth finished a range unless prime95 > was ready to take over as soon as proth was done.) There is a marked difference in the process timeslot allocation algorithm between NT4 & W2K. (IMHO neither is as effective as the equivalent function in linux 2.2, further improved in linux 2.4, but that's a different story!) Also between Win95 and Win98. '95 behaves like NT4, and '98 behaves like W2K. Well, only on uniprocessor systems, since '9x/ME don't support SMP at all, but I think you get the drift? My strategy is: (1) run Proth at medium priority in factoring only mode to eliminate candidates with "small" factors; (2) on the same system, run PRP at low priority to check the survivors from stage 1 for probable primes; (3) on a different system (normally running Prime95), run Proth at medium priority to verify the probable primes. (If you don't have a "spare" system it would be best to do this in a seperate directory so as to save keep changing the Proth setup!) (1) takes a lot less time than (2) so even if (2) stops temporarily that's not a problem. Not much survives (2) so run (3) takes little time, even though it's much slower per candidate than the others! BTW so far _every_ probable prime I've found using PRP has been accepted as a genuine prime by Proth, though this is certainly not guaranteed. > > I assumed that one value of k was pretty much the same as any other as > far as execution time and the chance of finding primes. To my surprise > this turned out not to be so: On the P3-500, for "most" 650<k<750, it > takes about 5 hours for 16000<n<32000 and 12 hours for 32000<n<48000 > -- but for k=701 it took less than 2 and just over 6 hours, > respectively. The phenomenon is reproducible, doesn't seem to be an > artifact of other programs or reboots or suchlike. Any number > theorists care to explain what is special about k=701 that makes it > easy to check for primality? If you break the run down as above you will see that some values of k yield a much smaller proportion of candidates for psuedo-prime testing than others. Or, to put it another way, some values of k give a much higher percentage of k.2^p-1 with "small" factors than others. Conversely the "slower" values of k tend to yield a lot more primes than the "faster" ones. In fact, if your trial factoring strategy is reasonable, your average rate of discovery of primes will not depend much on the value of k - though it certainly will depend on the average value of n! k.2^p+1 behaves similarly. In fact there are some values of k for which it is _proved_ (mathematically) that there are _no_ k.2^p+1 primes, even though the lowest value of k for which this is true is still uncertain. (Or at least there was still work in progress last time I checked.) You may care to look up the "Sierpinski Problem" if you're interested in this. > > A fun project. Now if Michael would just put a stop to that pesky > server error I could submit a half dozen more primes to him... :) Yeah, I finished up my raft of blocks a couple of days ago, can't get any more & can't report results. No response to mail messages either. He may have gone on vacation. Regards Brian Beesley _________________________________________________________________________ Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers ------------------------------ Date: Sat, 23 Jun 2001 11:01:32 +0200 From: "Hoogendoorn, Sander" <[EMAIL PROTECTED]> Subject: RE: Mersenne: Proth observations Brian J. Beesley Wrote: > My strategy is: > (1) run Proth at medium priority in factoring only mode to eliminate > candidates with "small" factors; For step 1 i use Newpgen. I think this is better configurable then proth in how far or long you want to factor. Don't know which is the fastest of the two. > (2) on the same system, run PRP at low priority to check the > survivors from stage 1 for probable primes; > (3) on a different system (normally running Prime95), run Proth at > medium priority to verify the probable primes. (If you don't have a > "spare" system it would be best to do this in a seperate directory so > as to save keep changing the Proth setup!) > BTW so far _every_ probable prime I've found using PRP has been > accepted as a genuine prime by Proth, though this is certainly not > guaranteed. Same here > If you break the run down as above you will see that some values of k > yield a much smaller proportion of candidates for psuedo-prime > testing than others. Or, to put it another way, some values of k give > a much higher percentage of k.2^p-1 with "small" factors than others. For some k's you have to test more the twice as many candidates in the same range of n's Sander _________________________________________________________________________ Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers ------------------------------ Date: Mon, 25 Jun 2001 23:53:34 +0200 From: "george de fockert" <[EMAIL PROTECTED]> Subject: Re: Mersenne: Prime95 - V21.1.1 aka v21a Hi all, some timings for the interrested. standard menu default 10m 10 iterations timing. TB 800 at 6.5*133=866 v20 : 0.114 v21 prefetch=0 : 0.120 v21 prefetch=1 : 0.092 George de Fockert _________________________________________________________________________ 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 #864 ******************************
