Mersenne Digest Monday, April 24 2000 Volume 01 : Number 723 ---------------------------------------------------------------------- Date: Thu, 20 Apr 2000 22:37:32 EDT From: "Nathan Russell" <[EMAIL PROTECTED]> Subject: Re: Mersenne: 65 bits (was Re: factoring) >From: Eric Hahn <[EMAIL PROTECTED]> >To: "Nathan Russell" <[EMAIL PROTECTED]> >CC: [EMAIL PROTECTED] >Subject: Re: Mersenne: 65 bits (was Re: factoring) >Date: Thu, 20 Apr 2000 16:12:12 -0700 > > >Nathan Russell wrote: > >It will only get worse for the 486 users when PrimeNet begins > >handing out exponents that will need factoring to 65 bits. Of > >course, they can use factoroveride, but that's not helpful to > >the network as a whole. > >However, the factoroverride switch is not designed for use with >the PrimeNet server. For reasons unknown, the server does not >release the exponent upon report of factoring being done when >using the switch. That's why there was a complaint a while back >on the list that somebody had several thousand factoring >assignments out. I had thought that the problem was only that Prime95 was trying to request assignments, and then was unable to insert them in the worktodo file because it was already at the maximum length. > > >For those who don't know, due to CPU design reasons that I > >don't claim to understand, factoring to 65 bits takes easily > >four or five times as long as factoring to 64 bits. In > >version 19, it was set to take place for exponents 13.38M and > >up. I believe PrimeNet will reach this point in a few months. > >While I had calculated it at 4.5 times as long (2x for the same >percentage completion, and 2.25x for the iteration time), I've >been getting ~4.2x as long. For some reason, IPS assigned me >a couple dozen exponents just above 13.38M, and what would >have normally taken me 38 hrs. for to 2^64, it's been taking >~160 hrs. to do to 2^65... Interesting. The figure I gave was an estimate based on my own experience with the factoring I am now running for QA. Nathan ________________________________________________________________________ Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com _________________________________________________________________ Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers ------------------------------ Date: Fri, 21 Apr 2000 16:24:04 EDT From: [EMAIL PROTECTED] Subject: Mersenne: Re: why sieving to > 64 bits is slow Nathan Russell wrote: > For those who don't know, due to CPU design reasons > that I don't claim to understand, factoring to 65 bits > takes easily four or five times as long as factoring > to 64 bits. In version 19, it was set to take place > for exponents 13.38M and up. I believe PrimeNet will > reach this point in a few months. The reason is quite simple: Prime95 can do speedy factoring up to 64 bits by using the 64-bit mantissa of an x86 register float to store the trial factor (and various intermediate quantities modulo the trial factor) and doing integer multiply (which is normally quite slow on x86) by way of the FPU, which can pipeline the MULs. As soon as the trial factor size exceeds this 64-bit natural wordsize, one must go to a double-word representation, hence the factor-of-four-or-so slowdown. I'm in agreement with Brian Beesley on this issue: especially now that there's the capability to do P-1, I think sieving to > 64 bits will prove to be a waste of time, since we should be able to find nearly all the factors > 64 bits that sieving would turn up more cheaply using P-1. That assumes that our priority is maximizing GIMPS throughput, rather than being able to say with certainty that such-and-such a number has no factors less than, e.g., sixty-eight bits. George, when do you expect sufficient data to be able to quantify the relative effectiveness of sieving vs. P-1 for these larger factor size ranges? - -Ernst _________________________________________________________________ Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers ------------------------------ Date: Fri Apr 21 16:31:41 2000 From: [EMAIL PROTECTED] Subject: Mersenne: Re: L2 cache I wrote: > > Come to think of it, factoring would be an excellent > > application for a 21264 without an L2 cache, but I > > don't know if they come that way (except perhaps in > > a massively parallel setting, where the problem of > > maintaining cache coherency in a multilevel cache > > hierarchy often is nearly intractable). Brian Beesley wrote: >Either the L2 cache is on the chip, a la Celeron/PIIIE, >or it's on a board - either a cartridge slot, a la PII, > or on the mainboard, a la Pentium Classic. If the L2 > cache is off chip, then clearly systems not containing > L2 cache can be manufactured. If it's on chip, > presumably you can still turn it off - though you're > going to be stuck with the manufacturing cost. For the large and variable L2 cache sizes of 21264 systems, the only reasonable way to to it is off-chip. If you look inside a 21264, you'll see the daughtercard with the CPU+monster heatsink, and the separate bank of L2 cache chips, with their own heatsink covering the whole batch (but I think only the CPU has a cooling fan- for the cache, the heatsink plus inside-case air circulation appears adequate. Assuming a nominal 1 ns CPU cycle time (i.e. 1 GHz CPU), the fact that the speed of electrical impulses in copper wiring is ~2/3 the speed of light in vacuum, or 2x10^8 m/s, if the furthest part of the L2 cache is separated from the CPU by (say) 20cm of wire, the absolute minimum number of cycles to fetch data from the cache is precisely one. If one's CPU architecture is designed to go to (say) 10GHz, and one is willing to wait up to 10 cycles for data from the L2 cache, fine- beyond that one must either move the cache on-chip or in some other way much closer to the CPU. Within the next 10 years, I fully expect we'll start seeing compact 3-D stackable-layer designs: processor(s) plus layers of high-speed memory, with a dense network of microchannels to carry coolant. Not so different, really, than what has evolved in the higher animals. (One common theme of mechanical design and natural evolution being: If it works, use it!) - -Ernst _________________________________________________________________ Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers ------------------------------ Date: Fri, 21 Apr 2000 17:40:55 EDT From: [EMAIL PROTECTED] Subject: Mersenne: Electron Winds and Prime00 I know this is mostly off topic, so I'll keep it short: All the recent stuff about HDs and what would cause Prime95 to fail first got me thinking. I know theoretically about "electron wind", the phenomenon that pushes around metal and other atoms in chips, albeit slowly. Does anyone know of a real instance of a CPU failing due to the electron wind? I remember reading that it would take 20 or so years to do so. You can imagine the hoaxes now: "Beware Prime95 - it's an electron wind virus that'll rip your CPU's wiring to shreds... in two decades..." And another thought: when'll the name be changed to Prime00? I have yet to see any software or products named with "00", while the plethora of "2000" stuff is obvious. I think that "Prime00" would be a wickedly nifty name. Stephan "Windy City" Lavavej _________________________________________________________________ Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers ------------------------------ Date: Fri, 21 Apr 2000 23:52:13 +0100 From: gordon spence <[EMAIL PROTECTED]> Subject: Mersenne: Double Checking Finds A Factor Hi All, Well it finally happened to me...., I was double checking an exponent in the 5M range, using the beta of V20 and it found a factor! I often wondered about how often that happened, anyone have any other hard data? 5008021 63 DF 7054282710141713489 10-Apr-00 07:09 gateway regards Gordon _________________________________________________________________ Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers ------------------------------ Date: Fri, 21 Apr 2000 18:55:03 -0400 From: George Woltman <[EMAIL PROTECTED]> Subject: Re: Mersenne: Re: why sieving to > 64 bits is slow Hi, At 04:24 PM 4/21/00 -0400, [EMAIL PROTECTED] wrote: >I'm in agreement with Brian Beesley on this issue: >especially now that there's the capability to do P-1, I >think sieving to > 64 bits will prove to be a waste of >time, since we should be able to find nearly all the >factors > 64 bits that sieving would turn up more >cheaply using P-1. I examined this for exponent 15,000,971 assuming 32MB of available memory. If prime95 only factors to 2^64, then the P-1 bounds chosen will be B1=180000 and B2=800000. These bounds will find only 28% of 65-bit factors. Therefore, while an adjustment to the factoring limits makes theoretical sense, the effect would be rather minimal. Regards, George _________________________________________________________________ Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers ------------------------------ Date: Sat, 22 Apr 2000 00:07:10 +0100 From: gordon spence <[EMAIL PROTECTED]> Subject: Mersenne: Primenet Proxy and Prime Blowing Up Hi All, I am getting very frustrated by the following and am searching for clues.... PC1 (P133/128mb/Win2000) is running the PrimeNet Proxy software plus V20 in double checking mode This machine is also the *Internet* proxy for my home lan. The Internet connection is a dial on demand 56k modem. All other machines on the network are running V19.2.5 in NT Service mode PC2 (2 x Celeron 533/192mb/Win2000) PC3 (PII-400/256mb/NT4) PC4 (Pii-300/320mb/NT4) PC5 (P150/32mb/NT4 Server) All are set to use the Primenet proxy to deliver results etc. Everything is fine as long as the primenet proxy service is running. It doesn't have to have an active internet connection when the clients talk to it. However if you stop the primenet proxy service then try and contact primenet from the clients, then the prime95 crashes out *every* time, both the V19.2.5 service version and the v20 console version. Any thought?? regards G _________________________________________________________________ Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers ------------------------------ Date: Sat, 22 Apr 2000 06:51:04 +0200 From: Martijn Kruithof <[EMAIL PROTECTED]> Subject: Re: Mersenne: Primenet Proxy and Prime Blowing Up gordon spence wrote: > > Hi All, > > I am getting very frustrated by the following and am searching for clues.... > > PC1 (P133/128mb/Win2000) is running the PrimeNet Proxy software plus V20 in > double checking mode > > This machine is also the *Internet* proxy for my home lan. The Internet > connection is a dial on demand 56k modem. All other machines on the network > are running V19.2.5 in NT Service mode > > PC2 (2 x Celeron 533/192mb/Win2000) > PC3 (PII-400/256mb/NT4) > PC4 (Pii-300/320mb/NT4) > PC5 (P150/32mb/NT4 Server) > > All are set to use the Primenet proxy to deliver results etc. Everything is > fine as long as the primenet proxy service is running. It doesn't have to > have an active internet connection when the clients talk to it. > > However if you stop the primenet proxy service then try and contact > primenet from the clients, then the prime95 crashes out *every* time, both > the V19.2.5 service version and the v20 console version. > > Any thought?? > > regards > > G > I Actually experienced the same thing w/o proxy service and the internet entropia server knocked out with both linux mprime and the nt service. kind regards, Martijn _________________________________________________________________ Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers ------------------------------ Date: Sat, 22 Apr 2000 12:41:54 +0200 From: "Dieter Schmitt" <[EMAIL PROTECTED]> Subject: Re: Mersenne: Double Checking Finds A Factor Hi Gordon, this 71-bit factor was found by P-1 out of 17 exponents (so far): [Sat Apr 15 01:47:40 2000] P-1 found a factor in stage #1, B1=25000, B2=275000. UID: dismit/P233MMX, M4428701 has a factor: 3035629975521900014017 It was found at stage 1 by V20 beta 4. I'd have expected finding factors at lower bits first. Greetings Dieter Schmitt From: "gordon spence" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Saturday, 22. April 2000 00:52 Subject: Mersenne: Double Checking Finds A Factor > Well it finally happened to me...., I was double checking an exponent in > the 5M range, using the beta of V20 and it found a factor! I often wondered > about how often that happened, anyone have any other hard data? > > 5008021 63 DF 7054282710141713489 10-Apr-00 07:09 gateway _________________________________________________________________ Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers ------------------------------ Date: Mon, 24 Apr 2000 10:56:16 -0700 (PDT) From: John R Pierce <[EMAIL PROTECTED]> Subject: Mersenne: further adventures of my Dell dual Xeon server If you recall, I was reporting 'error illegal sumout' problems with a new dual 600Mhz P3-Xeon Dell PowerEdge server running RH 6.1 linux. Well, I noted this weekend that RH has released a kernel upgrade that fixes 'obscure multiprocessor problems under heavy load'. I've installed this upgrade, so far I have two instances on test 3 of 18 w/o a glitch. I *was* running kernel-2.2.13-0.13smp.i686 ... Now, I'm running kernel-2.2.14-6.1.1smp.i686 and it seems OK. Of course, it will take several days of testing to be sure. - -jrp _________________________________________________________________ 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 #723 ******************************
