Mersenne Digest Friday, March 24 2000 Volume 01 : Number 710 ---------------------------------------------------------------------- Date: Wed, 22 Mar 2000 20:58:14 EST From: "Nathan Russell" <[EMAIL PROTECTED]> Subject: Mersenne: Milestone?: All assignment through 10 M claimed I found this in a recent scan of the server assignments-out page: 10000169 64 720896 5.2 23.8 64.8 17-Mar-00 21:43 w-dur mypc It appears that the army is finally beginning to cross the moat, so to speak. I don't think this should be regarded as an 'official' milestone, since it would encourage excessive caching, which is bad for GIMPS as a whole, but it is definately a point of interest. Both of my own exponents are in the 9.7 M range, and I picked them up in early February, if memory serves right. When I joined GIMPS, I had no idea of how fast it would grow. I think that compliments go to us all. Regards, Nathan Russell ______________________________________________________ Get Your Private, Free Email 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: Wed, 22 Mar 2000 22:57:17 EST From: [EMAIL PROTECTED] Subject: Mersenne: Goldbach, Mersenne, etc. <<The publishers set a deadline of March 15, 2002.>> Heh heh - maybe 2202 would be more reasonable. << All above 21 are either 0, 1 or 2 mod 3, and are therefore the sum of either 1, 2 or 3 sevens with a sufficient number of 3's thrown on top. I am sure this can (and should) be stated far more formerly, but my real question is this: Is it possible to strengthen this conjecture, say by putting a ceiling on the number of times that any one prime need be repeated? Such a statement can also be made for the odd positive integers. 1, 5 and 11 are the only exceptions that need be made, since all odds above 13 can be written as the sum of an even number above 8 and a Mersenne prime.>> I don't really understand what you're saying. You're saying that you can express a number as A*X + B*Y, where A and B are integers and X and Y are Mersenne primes (3 and 7). If I remember correctly, this is a specific case of a more general result. (Try to figure out what that might be...!) Your second paragraph is not comprehensible to me. :-O Off-topic: Next year, when I refer to events prior to 2001, I'll be able to say "You know, back in the twentieth..." Heh heh. Stephan "Video Killed the Radio Star" Lavavej _________________________________________________________________ Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers ------------------------------ Date: Thu, 23 Mar 2000 20:57:08 EST From: "Nathan Russell" <[EMAIL PROTECTED]> Subject: Re: Mersenne: (getting OT) IRC? >From: Jukka Santala <[EMAIL PROTECTED]> >Reply-To: [EMAIL PROTECTED] >To: [EMAIL PROTECTED] >Subject: Re: Mersenne: IRC? >Date: Wed, 22 Mar 2000 20:01:04 +0200 > >That's not a problem, it's the purpose of IRC... ;) Regardless, I've >(intermittently) keeping up the channel #Mersenne on DALnet IRC network I have been on there too, but there seems to be nobody on /sigh/ > > > (1) IRC (like voice telephone) is on-line and you therefore tend to > > mouth off before thinking out a logical, coherent reply; > >s/on-line/real-time. Actually, the same holds true for instant messengers >and >the way most people use e-mail. It's also very much like the evil "Real >World" >you hear legends being told about ;) In other words, it isn't just a >disadvantage, there are some advantages to that too. Agreed. >They're called channels, and mostly that depends specifically on the >channel >you join. If you get a message from a stranger to go to some channel for >example, don't join, because those kinds of channels have usually been set >up >by somebody for the bizarre reason of getting high usercount alone and have >nothing happening but other such people advertising their channels! The other thing that helps is to warn the people that are sending "earn money surfing the web" messages to stop. Cycle (leave and rejoin the chan) about five minutes later, and then send email to the abuse@ or webmaster@ address of the "earn money" company in question with the number the person gave you (usually the last part of the URL they provide). They'll often close their account. Also, >setting yourself "Invisible" from the mIRC login settings will remove you >from >the public user listings so people can't message you with advertisements >out of >the blue. However these days most IRC networks do pretty good work weeding >out >those ads. Agreed. /mode (yournick) +i works too. Nathan ______________________________________________________ Get Your Private, Free Email 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, 24 Mar 2000 17:37:10 +0100 From: "Hoogendoorn, Sander" <[EMAIL PROTECTED]> Subject: Mersenne: V20.1.1 P-1 Factoring The folowing exponents where factored by P-1, but why are the bounds so different? The first had a chance of 1.77% and the other two about 3.7% to find a factor . UID: sanderh/PC, M5542549 completed P-1, B1=70000, B2=70000, WW1: 8F7EF481 UID: sanderh/PC, M5542723 completed P-1, B1=60000, B2=750000, WW1: 8F638A77 UID: sanderh/PC, M5547583 completed P-1, B1=65000, B2=780000, WW1: 8FAE325D BTW No problems found sofar _________________________________________________________________ Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers ------------------------------ Date: Fri, 24 Mar 2000 14:44:07 -0500 From: George Woltman <[EMAIL PROTECTED]> Subject: Mersenne: V20 beta for Linux Hi all, As requested, I've ported the v20 beta to Linux. Please let me know of any problems. You can download it from ftp://entropia.com/gimps/v20/mprime.tgz or ftp://entropia.com/gimps/v20/sprime.tgz Regards, George _________________________________________________________________ Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers ------------------------------ Date: Fri, 24 Mar 2000 15:44:31 EST From: [EMAIL PROTECTED] Subject: Mersenne: (no subject) There's previously been several posts discussing the performance penalty one suffers when running multiple LL tests on a multiprocessor system with a single shared system bus. It would be interesting to see whether this penalty could be alleviated in a reasonably cost-effective fashion through use of larger L2 caches. Here's the idea: if the L2 caches are much smaller than the dataset size, the system bus will be heavily used by each process, leading to memory delays. If each processor has an L2 cache large enough to hold the full dataset (between 4 and 5MB for an LL test of an exponent ~10M), there will be essentially no memory traffic and no shared-bus penalty. Such large caches are expensive. But it seems that between these two extremes (very small and very large caches) there should be some kind of optimal compromise, where the cache size is just large enough that the resulting reduction in memory traffic allows each process to access the main memory at basically the same speed it would if there were no other jobs competing for bus bandwidth, i.e. where the bus traffic just begins to saturate. I suspect for LL tests in the ~10M range, this happy medium may be as 'small' as 1-2MB. Are PC systems with L2 caches in this size range available? If so, how much of a premium does one pay for the extra cache? Cheers, - -Ernst _________________________________________________________________ Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers ------------------------------ Date: Fri, 24 Mar 2000 14:32:03 -0700 From: "Aaron Blosser" <[EMAIL PROTECTED]> Subject: RE: Mersenne: L2 Cache size >There's previously been several posts discussing the performance penalty >one suffers when running multiple LL tests on a multiprocessor system >with a single shared system bus. It would be interesting to see >whether this >penalty could be alleviated in a reasonably cost-effective fashion through >use of larger L2 caches. I had the opportunity a while back to do some crude testing with various configurations like this... I used the NTPrime service and put it on a few different MPS systems. Each one was a 450 MHz Pentium II Xeon server with 1MB L2 cache Xeons in them. I had a Dell quad CPU server, an IBM quad, and Compaq quad. When running 4 instances of NTPrime on each, I just looked at what the rollingaverage value was after a few days of the server not doing anything else but just sitting there running NTPrime on all the CPU's. Okay, it wasn't really scientific, and I dont' remember the numbers exactly, but on the Compaq, the rollingaverage was around 985-995. The Dell and IBM had lower values, around 960-970. The memory architecture on the Compaq servers really helps out a lot when multiple CPU's are clamoring for memory at the same time... I wish I could have tested one of them by telling NT to only use one CPU (disabling SMP essentially) and seeing what the baseline rollingaverage was, so I could compare how much a single system is affected by having multiple CPU's running NTPrime at once, but I didn't get around to that. >I suspect for LL tests in the ~10M range, this happy medium may be as >'small' as 1-2MB. Are PC systems with L2 caches in this size range >available? If so, how much of a premium does one pay for the extra cache? Xeon's come in L2 cache sizes up to 2MB, but they are prohibitively expensive. Most Xeon servers come with CPU's with 1MB of L2. Beyond the Intel x86 world, I'm sure there are CPU's with much larger cache sizes...don't Alphas come with up to 4MB of L2? And dont the K6-III and Athlon support an L3 design, using slower memory of course, but dedicated to each CPU so eliminating bus contention? Of course, the K6-III doesn't do SMP, but the Athlon supports it, doesn't it? Are there any SMP motherboards out there yet for the Athlon? Aaron _________________________________________________________________ Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers ------------------------------ Date: Fri, 24 Mar 2000 15:34:20 -0600 From: "Willmore, David" <[EMAIL PROTECTED]> Subject: RE: Mersenne: (no subject) > There's previously been several posts discussing the performance penalty > one suffers when running multiple LL tests on a multiprocessor system > with a single shared system bus. It would be interesting to see whether > this > penalty could be alleviated in a reasonably cost-effective fashion through > use of larger L2 caches. > This is a fundimental problem in processor/system design. The quick answer is no. > Here's the idea: if the L2 caches are much smaller than the dataset size, > the system bus will be heavily used by each process, leading to memory > delays. If each processor has an L2 cache large enough to hold the full > dataset (between 4 and 5MB for an LL test of an exponent ~10M), there > will be essentially no memory traffic and no shared-bus penalty. Such > large caches are expensive. But it seems that between these two extremes > (very small and very large caches) there should be some kind of optimal > compromise, where the cache size is just large enough that the resulting > reduction in memory traffic allows each process to access the main memory > at basically the same speed it would if there were no other jobs competing > for > bus bandwidth, i.e. where the bus traffic just begins to saturate. > The loading on the memory bus by the other processor may only use half of the available bandwidth (for a 2 CPU system) but the latency due to bus contention will decrease performance, still. The curve of performance loss vs foreign bus utilization is not very sharp. With modern processors supporting many outstanding loads from main memory, it's not getting any sharper. > I suspect for LL tests in the ~10M range, this happy medium may be as > 'small' as 1-2MB. Are PC systems with L2 caches in this size range > available? If so, how much of a premium does one pay for the extra cache? > The cheap answer these days is faster shared bus. Next to that is switched memory fabric (throw out the shared bus idea). Only after that is increasing the caches on package or on chip. External caches are getting less and less popular. For reasons similar to what I've mentioned above. The fundimental problem of caches (and layers of them) is that smaller and 'closer' (in terms of latency) competes with larger and 'farther'. Off chip and off package is just *so* far away these days that it doesn't buy you much unless you put a ton of fast memory there. At that point, you have to worry that it's just using bandwidth that could be data from main memory. So, you put it on a dedicated bus, but now you have to ask 'would it have just been better to make the pipe to main memory wider with these pins?' *stops for breath* Okay, the quick answer if that, for PC hardware, the Intel Xenon systems are the only ones with bigger than 512K of chip caches. Those guys only run in expensive motherboards. So, the simple solution is to not run on SMP systems where you run into this problem. The cheapest way is to use uni-processor systems with a reasonable memory architecture. But, for those of us with SMP systems--I have one because it was cheap and I've always wanted one--we just have to keep in mind what kind of demands our applications put on the shared memory bus. My dual PII/333 system with a 66MHz 64bit shared bus does *not* like to run two coppies of LL testing at any one time. Once LL and one factoring is just fine, though--as factoring stayes on CPU. That's just something that I need to live with. As numbers get bigger, that dependency on main memory BW will get worse and worse as the cache becomes less and less effective. At some point, I'll probably retire the machine to some less memory BW demanding task--like building kernels or (may I die before this happens) RC5 cracking. Cheers, David _________________________________________________________________ Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers ------------------------------ Date: Fri, 24 Mar 2000 16:00:05 -0600 From: "Willmore, David" <[EMAIL PROTECTED]> Subject: RE: Mersenne: L2 Cache size > And dont the K6-III and Athlon support an L3 design, using slower memory > of > course, but dedicated to each CPU so eliminating bus contention? Of > course, > the K6-III doesn't do SMP, but the Athlon supports it, doesn't it? Are > there any SMP motherboards out there yet for the Athlon? > The K6's and the Cyrix 6x86's could do SMP just like the pentium. The only problem was that they used the OpenPIC standard and noone ever built a chipset that implemented that, so no SMP systems. The Athlon not only supports SMP, but it does it the, IMHO, Right Way(tm). They use a point to point bus between the processor and the core logic. Hence, a SMP Athlon system has no shared bus. Each processor gets a pipe to the core logic and it has however many pipes to memory/IO that it wants. This is what you have to do to scale SMP very high, anyway. I think the Intel chips force this for #CPUs>4, too. Maybe it's 2--I can't remember right now. Cheers, David _________________________________________________________________ Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers ------------------------------ Date: Fri, 24 Mar 2000 15:19:34 -0700 From: "Aaron Blosser" <[EMAIL PROTECTED]> Subject: RE: Mersenne: L2 Cache size >The Athlon not only supports SMP, but it does it the, IMHO, Right Way(tm). >They use a point to point bus between the processor and the core logic. >Hence, a SMP Athlon system has no shared bus. Each processor gets >a pipe to >the core logic and it has however many pipes to memory/IO that it wants. >This is what you have to do to scale SMP very high, anyway. I think the >Intel chips force this for #CPUs>4, too. Maybe it's 2--I can't remember >right now. The new >4 CPU systems using the Profusion architecture should handle things a lot better for x86 CPU's. I didn't get too much hands on, but at the Compaq System Engineer conference last summer, I got to fiddle with a few Proliant 8000's and 8500's just a few weeks before they were publicly announced. Too bad I didn't have NTPrime with me, but then, if someone like me gets caught with that, they probably consider it contraband. :) But they did have some impressive stuff going on them...the SQL setups were really nice, but I'm not sure how much those stress out the cache...oh...they were using 450MHz PII Xeon's with 1MB of L2. That extra MB of L2 cache, to get you to 2MB, adds a lot of cost though... I just checked on Pricewatch...my goodness, how prices have dropped since just 6 months ago. The 2MB version of the 450MHz PII Xeon is going for a mere $750 or so...while the 1MB version can be had for $425. Hmmm... The PIII Xeon's (500MHz) are about $1500 for the 2MB version, and around $1000 for the 1MB. That's about what the PII Xeon's were going for 6 months ago... I do wonder what the speeds would be like for Prime95/NTPrime on a 1MB vs. 2MB Xeon... Anyone have the chance to test that out? Aaron _________________________________________________________________ Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers ------------------------------ Date: Fri, 24 Mar 2000 22:55:07 -0000 From: "Brian J. Beesley" <[EMAIL PROTECTED]> Subject: Re: Memory bus congestion (Was: Mersenne: (no subject)) On 24 Mar 00, at 15:44, [EMAIL PROTECTED] wrote: > I suspect for LL tests in the ~10M range, this happy medium may be as > 'small' as 1-2MB. Are PC systems with L2 caches in this size range > available? If so, how much of a premium does one pay for the extra cache? Ernst, your Mlucas program has a similar "memory footprint" to Prime95. My Alpha 21164-533 has 2MB L3 cache, yet cache effects start to become noticeable around exponent 5 million, and are dominant well before exponent 10 million. I think you'd need 4 MB cache in order to be able to run a LL test on an exponent in the region of 10 million whilst containing most of the memory accesses to the cache. AMD K6-3 supported L3 cache, Socket 7 motherboards with 2MB cache were available. But the K6 never did support SMP and the K6-3 is now discontinued - AMD now run only the K6-2 as the "budget" line and the Athlon as the "performance" line. Of the Intel processors, only PPro and Xeon have ever been available with caches bigger than 512K - PPro to 1MB and Xeon in 1MB and 2MB variants. You pay a frightening premium for larger caches - about double the price for the processor for each doubling of cache size. Given the relatively small increase in performance, this premium is very hard to justify. You can build four complete Pentium III systems for the price of just one Xeon CPU with 2MB cache running at the same speed. More realistic options would appear to be to use systems using Rambus memory technology (which has several times the throughput of SDRAM, though at a significant cost penalty) and/or the Intel 840 chipset (which I understand has dual memory busses, giving each CPU simultaneously full speed access to memory locations which happen not to be being accessed by the other processor at the same time). Compaq have been building multiprocessor server systems using similar technology for some time, these do not appear to suffer from throughput throttling to any significant extent when multiple copies of Prime95/NTPrime/mprime are run on them. But they aren't cheap! Incidentally, with core/bus speed ratios as large as the are with the fastest processors available today, memory bandwidth bottlenecks are possible with uniprocessor systems too. In particular note that systems based on the Intel 820 chipset using a memory translation hub to enable affordable SDRAM to be used instead of Rambus memory will probably deliver only 100 MHz memory bandwidth even if the CPU is running at 133 MHz FSB. Such systems also appear to be _very_ particular about the memory being used - the parameters in the SPD chip must be totally correct, since the MTH prevents the BIOS from determining the correct parameters for accessing the RAM directly. The upshot is that the system believes that it has no RAM fitted, even though the memory may work perfectly well in another (non-i820) board. My advice would be not to buy an i820-based motherboard unless you're prepared to buy Rambus memory to fit in it - currently Rambus is about five times the price of SDRAM. BTW I have two dual-processor systems, both using Supermicro P6DBx motherboards (single memory bus, BX chipset). One has PII-350s fitted, the other has a pair of PIII-450s. When running LL tests, the 350 MHz system slows down about 7% when both processors are running compared with the speed with one processor idle; the 450 MHz system slows down about 15%. You get full performance on one LL test if the other system is doing something which requires CPU time but little or no memory access e.g. trial factoring, or Stage 1 of an ECM run on a small exponent. This is true for both Win NT and linux. '9x does not support SMP, so the second processor doesn't cause memory bus congestion, but you don't get benefit from its CPU cycles either! 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, 24 Mar 2000 18:38:03 -0800 From: Stefan Struiker <[EMAIL PROTECTED]> Subject: Mersenne: Responding To Several Queries About Quantum Computing: TeamG: For some of the latest of the latest on QC, see the link: http://www.wired.com/news/technology/0,1282,35121,00.html There is also the book THE FEYNMAN PROCESSOR, in paperback, by G.J. Milburn, for an overview. Regards, Stefanovic _________________________________________________________________ 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 #710 ******************************
