Mersenne Digest Wednesday, April 12 2000 Volume 01 : Number 717 ---------------------------------------------------------------------- Date: Mon, 10 Apr 2000 17:40:45 -0000 From: "Brian J. Beesley" <[EMAIL PROTECTED]> Subject: Re: Mersenne: Clockers On 9 Apr 00, at 20:51, Stefan Struiker wrote: > Working on nearly the same exponent, 9.7 million, I notice that > our PIII 500 takes only 119.5 million clocks per iteration, whereas > our 733EB requires 124.8 million to do the same. The PIII 500/100 MHz FSB system equates to a PIII 666/133 MHz FSB system, i.e. they _should_ take the same number of clocks. With a higher multiplier, you will be waiting for extra clocks to access data when it isn't in one of the caches. Even a PIII 550 in the same MB as the PIII 500 would take _some_ extra clocks, though not enough to cancel out the extra CPU speed. Basically the point is that, with a relatively lower instruction & operand fetch rate relatively to the execution unit performance, the CPU is going to spend more of its time waiting for the pipeline to furnish new instructions and/or data values to work on. The smaller L2 cache probably doesn't help, even though it is running faster. There is still a wastage of memory bandwidth whenever there is a L2 cache miss, which is going to happen more often with a smaller cache. However, this may not be too serious - 128K L2 cache Celerons perform quite well, and L2 cacheless Celerons are nowhere near as bad as you might suspect! The chipset has a big effect, too. All systems using 133 MHz FSB run the memory asynchronously to the system bus. One would suspect that the hardware required to resynchronize might have a bad effect on the throughput. The way my PIII 533B / TMC TI6NBF+ (VIA chipset) system performs, using 133 MHz FSB & memory, leads me to suspect that there's a 100 MHz bottleneck somewhere in the memory subsystem! > > The 733 has 256K full-speed on-chip cache and runs 256MB of RDRAM > (RAMBUS), 133MHz bus and was not so cheap. Wow, 256 MB RDRAM certainly _isn't_ cheap, I could buy a whole PIII 500 system with the money I'd save if I bought 256 MB SDRAM instead! Seriously, though, systems with more physical memory have bigger page tables, which can't help causing more system faults. Grossly excessive amounts of physical memory hurt performance (a bit) rather than help it. Depending on the OS you're running, how the program fits into the memory available can make a big difference too. Using Win 9x or NT WS 4.0, you can get up to 5% variation in iteration time _on the exact same hardware, on the exact same exponent, without even rebooting the system_. Starting Prime95 using my ReCache program helps the OS to load Prime95 efficiently, especially on systems with more than adequate physical memory. Win 2000 seems to manage well enough without ReCache. linux systems don't seem to be bothered, their run speed is consistent to within 1%, but adding extra memory does still cause a modest slowdown. > > An Athlon of my acquaintance does all of this in 114.6 million clocks, but > that's another story, because the Athlon is supposed to decode more > instructions per cycle, and generally ace it in the floating-point > department.. I have a Athlon 650 and yes, it flies - it's turning in performance which equates to a PIII 733 extrapolated from George's benchmarks. There are other factors than the "improved" CPU: the L1 cache is 32 KB instead of 16 KB & I have a sneaky suspicion that the LL testing code manages to run with at least the vast majority of instruction fetches being stored in L1, this reduces the cycles lost to L1 cache miss. And the internal bus is 128 bits wide instead of 64 bits, so you get more data shifted internally between CPU/L1 cache and (512 KB) L2 cache. This more than compensates for the lower L2 cache speed. > > Can anyone explain the Pentium discrepancy? Not entirely, but I believe the points I've outlined above go some way. Just out of interest, which MB are you using for the system with RDRAM in it, and what's the spec of the RDRAM itself? Regards Brian Beesley _________________________________________________________________ Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers ------------------------------ Date: Mon, 10 Apr 2000 14:45:30 -0700 From: Luke Welsh <[EMAIL PROTECTED]> Subject: Mersenne: (fwd)Lehmer conference X-External-Networks: yes Approved-By: "Victor S. Miller" <[EMAIL PROTECTED]> Date: Mon, 10 Apr 2000 14:09:53 -0400 Reply-To: Bjorn Poonen <[EMAIL PROTECTED]> Sender: Number Theory List <[EMAIL PROTECTED]> From: Bjorn Poonen <[EMAIL PROTECTED]> Subject: Lehmer conference To: [EMAIL PROTECTED] LEHMER CONFERENCE A conference on number theory honoring the Lehmers for their contributions to mathematics and to U. C. Berkeley August 24 to 26, 2000 (Thursday, Friday, Saturday) University of California, Berkeley The Lehmer mathematical family, consisting of the father Derrick Norman (1868-1938), the son Derrick Henry (1905-1991) and his wife Emma (1906--), has made an enormous contribution to mathematics, and to number theory in particular. A three-day conference covering the range of the Lehmers' mathematical interests will be held on the U. C. Berkeley campus, featuring lectures by Michael Bennett University of Illinois at Urbana-Champaign David Boyd University of British Columbia John Brillhart University of Arizona Ron Graham University of California at San Diego Jeffrey Lagarias AT&T Labs Arjen Lenstra Citibank Ken Ono Penn State University Carl Pomerance Lucent Technologies, Bell Labs John Selfridge Northern Illinois University David Singmaster South Bank University Harold Stark University of California at San Diego Hugh Williams University of Manitoba Kenneth Williams Carleton University as well as a display of all the sieves built by D. H. Lehmer over four decades, beginning with his bicycle-chain sieve of 1927, which we expect to be operational. On Friday evening, a banquet will be held in the Great Hall of the Faculty Club on the University of California campus. The meeting celebrates 100 years of the Lehmers' association with U. C. Berkeley, as D. N. Lehmer began his tenure there in 1900. It follows immediately the "Introductory Workshop" to the Fall 2000 semester on Algorithmic Number Theory at the Mathematical Sciences Research Institute in Berkeley, to be held August 14 to 23, 2000. Organizing Committee: John Brillhart, Ron Graham, Hendrik W. Lenstra Jr., Bjorn Poonen, Hugh Williams Information: http://www.math.berkeley.edu/lehmer.html _________________________________________________________________ Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers ------------------------------ Date: Tue, 11 Apr 2000 09:07:37 -0700 (PDT) From: John R Pierce <[EMAIL PROTECTED]> Subject: Mersenne: dell poweredge server well, if anyone recalls me getting error: illegal sumouts on this new Dell PowerEdge 4400 server, its apparently the ram after all. I stripped the machine back to the original 256MB it came with and the errors have vanished. Running LL tests on a 1004xxxx number, I'm seeing 0.194 seconds with a single process running and 0.220 with a second mprime process competing. Again, this is a dual P-III XEON 600MHz Coppermine, 133MHz FSB, 256MB L2 Cache, and uses dual banks of PC133MHz ECC registered SDRAM. Tests done with latest MPRIME on redhat 6.1 linux. - -jrp _________________________________________________________________ Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers ------------------------------ Date: Tue, 11 Apr 2000 18:21:22 -0400 From: George Woltman <[EMAIL PROTECTED]> Subject: Mersenne: V20 beta #4 (will the beta never end?) Hi all, The fourth beta is available. It fixes a few more bugs. See the whatsnew.txt at the end of this email. An upgrade from earlier betas is not required, but it can't hurt. You can download it from ftp://entropia.com/gimps/v20/p95setup.exe or ftp://entropia.com/gimps/v20/prime95.zip or ftp://entropia.com/gimps/v20/mprime.tgz or ftp://entropia.com/gimps/v20/sprime.tgz Regards, George 1) Another fairly uncommon ECM bug was fixed. The bug caused "Factor does not divide N!" errors. 2) A couple of minor bugs in computing the optimal P-1 bounds to use prior to a Lucas-Lehmer test were fixed. The program now does a better job at estimating the memory required in P-1 stage 2. Finally, although P-1 stage 2 working set size is unchanged, the program allocates less memory in stage 2. 3) Prime95 no longer searches for a smaller factor when trial factoring discovers a factor. The reasons are two-fold. 1) Version 19 had a bug where stopping and restarting the program bypassed the search for smaller factors. Thus, my database may already be missing smaller factors. 2) As we factor larger exponents to a deeper depth it may no longer be a quick job to determine if there are smaller factors. Note, that version 20 will still look for smaller factors if you are looking for factors below 2^60 with the FactorOverride option in undoc.txt. 4) The undocumented AMPM feature controls how times are formatted in the Options/CPU dialog box. _________________________________________________________________ Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers ------------------------------ Date: Tue, 11 Apr 2000 22:57:51 +0000 From: "Steinar H. Gunderson" <[EMAIL PROTECTED]> Subject: Mersenne: Re: V20 beta #4 (will the beta never end?) On Tue, Apr 11, 2000 at 06:21:22PM -0400, George Woltman wrote: >The fourth beta is available. It fixes a few more bugs. For a feature request: Could you please handle some signals with the following (mprime-specific) meanings? SIGUSR1 - Set time to `day time' SIGUSR2 - Set time to `night time' This will: - - Make it possible to have more advanced scripts, like having different rules for different days. - - Make it possible for a knowing sysadmin to reduce the RAM needed by mprime, if he/she thinks it's needed (without killing mprime). - - Make it possible for me to set `nighttime' when I go to bed, because I go to bed at the weirdest times ;-) ...all this without changing mprime further, and it shouldn't be too difficult to implement either (just remember an `external control only' option, for bypassing the time checks entirely). /* 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: Wed, 12 Apr 2000 16:41:03 -0700 From: Gerry Snyder <[EMAIL PROTECTED]> Subject: Mersenne: Clustering of Mersenne numbers with small factors A while ago I asked how easy it is to find factors, since I thought that might be more satisfying than finding non-zero LL residues. I was encouraged by the responses, and switched my P166 to factoring. It went through 31 candidates before finding one with a factor, and then found another just three tries later. I realize that candidates with very small factors are already gone, and that others have grabbed intervening numbers, but I must say that I was stunned and very pleased to see another so soon. This stuff is good fun!!! Finding factors is very satisfying, but of course I have most of my horsepower doing LL. Gerry, who just cracked the top 900 most productive, but will drop very soon before storming back (my goal is to make it into the top 500) - -- mailto:[EMAIL PROTECTED] _________________________________________________________________ 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 #717 ******************************
