Mersenne Digest Tuesday, August 10 1999 Volume 01 : Number 612 ---------------------------------------------------------------------- Date: Sat, 7 Aug 1999 22:23:58 +0200 From: Preda Mihailescu <[EMAIL PROTECTED]> Subject: RE: Mersenne: Multiple residues - enhancing double-checking > > Yes, they can and do. In the field of computational number theory, several > participants in the Cunningham project have been active much longer than my > decade. Sam Wagstaff has been co-ordinating it longer than that. To be > honest, I don't know when he started. Perhaps Peter Mon tgomery (another > long-time participant) can inform us, as I know he's also on the Mersenne > list. > I have been working on a PhD to prove primes for ten years of sundays, Paul :-) Preda > In other fields, it's not unusual to commit to a decade or more. Consider > the deep space missions such as Voyager, or the astronomers who monitor a > particular class of objects for most of their working lives. I know some > amateurs who have been observing particular variable stars since the 1960's; > George Alcock has been searching for comets and novae since the late > fifties. > > > Paul > _________________________________________________________________ > Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm > Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers _________________________________________________________________ Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers ------------------------------ Date: Sun, 8 Aug 1999 02:01:50 +0200 From: "Shot" <[EMAIL PROTECTED]> Subject: Mersenne: Some basic questions Hi. Recently I read in a Polish computer magazine about your search and I decided to join. ("Gazeta Komputer", Tuesday supplement to "Gazeta Wyborcza" dated August 3rd - info for fellow Poles.) I installed prime95.exe and have some basic questions (excuse my igorance and my English, please): 1. My computer is based on Intel's 333 MHz Celeron, with 64 MB DIMM RAM, working on EPoX P2-112A motherboard (VIA ApolloPro chipset). PrimeNet sent to me (as I understand it) M8180017, which is now (as I understand it) being tested by my comp using Lucas-Lehmer test. The status windows shows that my work should be completed around September 26th. Am I right in assuming that then it will be known whether M8180017 is a prime or not? And, if it isn't a prime, it won't be know until then, right? 2. As I understand the status page, there are smaller untested would- be primes (about 20.000 below M7820000). Is there any way that I can test some of them (they would be tested a lot faster than M8180017, right?), or are they reserved for people with slower computers? 3. My single iteration's time is 0.430 s. Is this about right for my machine and M8180xxx number? 4. As I understand (from reading list's archives, around summer '96), earlier people were assigned ranges of numbers to check, and it took about 6 months to check primes inside a range (range == a thousand of numbers, containing some primes?). Now, as the project reached such big numbers as M8180xxx, the assigment is rather one number per connection, right? Does the "Test=8180017,63" in my worktodo.ini file mean that I got M8180017 and nothing more (if projected end date is accurate, it's enough ;)? What does the number 63 mean? Thanks in advance, - -- Shot __ c"? Shot - [EMAIL PROTECTED] hobbies: Star Wars, Pterry, GIMPS, ASCII `-' [EMAIL PROTECTED] join the GIMPS @ http://www.mersenne.org In a car rental brochure in Tokyo: When passenger of foot heave in sight, tootle the horn. Trumpet him melodiously at first, but if he still obstacles your passage then tootle him with vigor. _________________________________________________________________ Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers ------------------------------ Date: Sun, 8 Aug 1999 03:32:30 +2 From: "Oscar Fuentes" <[EMAIL PROTECTED]> Subject: Re: Mersenne: Some basic questions From: "Shot" <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] Date sent: Sun, 8 Aug 1999 02:01:50 +0200 Subject: Mersenne: Some basic questions Hello > status windows shows that my work should be completed around > September 26th. Am I right in assuming that then it will be known > whether M8180017 is a prime or not? And, if it isn't a prime, it > won't be know until then, right? Yes to both. Prime95 writes results to screen and to file RESULTS.TXT, wich is located in the same directory. > 2. As I understand the status page, there are smaller untested would- > be primes (about 20.000 below M7820000). Is there any way that I can > test some of them (they would be tested a lot faster than M8180017, > right?), or are they reserved for people with slower computers? This exponents are being tested by other members, but not necessarily with slower machines. Simply they got them first. > 3. My single iteration's time is 0.430 s. Is this about right for my > machine and M8180xxx number? It seems to be a right number. If you like, see http://www2.tripnet.se/~nlg/mersenne/benchmk.htm Don't worry if you encounter a few % difference with similar machines. > 4. As I understand (from reading list's archives, around summer '96), > earlier people were assigned ranges of numbers to check, and it took > about 6 months to check primes inside a range (range == a thousand of > numbers, containing some primes?). Now, as the project reached such > big numbers as M8180xxx, the assigment is rather one number per > connection, right? Does the "Test=8180017,63" in my worktodo.ini file > mean that I got M8180017 and nothing more (if projected end date is > accurate, it's enough ;)? What does the number 63 mean? In the not so early days of GIMPS, George Woltman assigned work by e-mail. For commodity, this assignments consisted of ranges, like you deduced. Now, with the automation, is possible to assign one exponent per machine. Anyway, in Prime95 menu's Test -> Primenet it is a parameter called 'Days of work to get'. Prime95 will reserve work for at less this number of days, so when you end with the current exponent, Prime95 begins with other whitout wait for a connection with Primenet. By default, this parameter is set to 30 days. You should not change this, unless you connect with the internet with less frecuency. A Mersenne candidate it is trial factored prior to a LLTest. Obviously, if a factor is found the number is not prime and you save the LLTest. The number 63 means that this mersenne number has been trial factored up to 2^63. When Prime95 gets an assignment, calculates if is worthwhile to factorise even further prior to do a LLTest. I encourage you to read the GIMPS and mail list faq's to learn more. Saludos Oscar Fuentes _________________________________________________________________ Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers ------------------------------ Date: Sat, 7 Aug 1999 21:27:16 -0600 From: "Aaron Blosser" <[EMAIL PROTECTED]> Subject: Mersenne: Checking exponents for LOOOONNG times > Paul Leyland (whom I'll meet for the second time later this month) writes: > > > > From: Brian J. Beesley [mailto:[EMAIL PROTECTED]] > > > > > A couple of points here: > > > (1) Can anyone honestly commit to a project for a whole decade? > > Yes, they can and do. > Ten years for one computation seems a long time. Yes, I have been > contributing to the Cunningham project for a long time, using machines > at multiple institutions, but we can hardly commit for ten years. > Jobs change today, at least in the USA. > A home machine may be stolen or damaged by fire or floods. > My family wouldn't know what to do if I died. Ten years is indeed a long time. Most home computers don't last half as long as that. Fortunately, with ZIP drives being more popular, it'll be easier to pack up your save file on one machine and transfer it to your new PC every 3-5 years. :-) I've only been with GIMPS for about 3 years, give or take a few months. I imagine that 10 years from now, I'll probably still be running programs in CPU idle time, but who can really say for sure, that far in advance? > For the very long LL computations, it is reasonable for two sites > A and B to start the computation, and do a checkpoint perhaps > every 1000 iterations. When A reaches its 7000-th iteration > (or other multiple of 1000), it sends the checkpoint file to a > central site Every 1000 iterations? That's a bit much. I'd say, for something like that, every 1 million iterations would do for exponents we work on now. For the really large exponents we're getting ready for in the future, every 5-10 million iterations seems like a good checkpoint, considering the size of those residues. > A tetrabyte is huge today but > may be common in 15 years. In the 1970's much data was on > seven-track tapes. I recall each held 1.9 M 60-bit words (14 Mb) > Today the NFS data for M619 is being processed on a filesystem with 16 Gb, > a 1100-fold increase over 25 years. True, terabytes are huge, but you're right, they are becoming more commonplace. Price has everything to do with that. It's the old rule that we can always fill the drive space we have available. When I tinkered with Apple ]['s with the wimpy 160K floppy (320K if you notched and flipped them!), that was alot of space. Getting a 20MB drive for my XT was very exciting and I didn't know, at first, what to do with all that space. Shelling out $600 for my first 120MB drive was a big expense for a teenager, but the thought of being the first of my friends to have over 100MB was too much. And on and on. Businesses are like this also. When more drive space becomes available, as if by magic, managers suddenly find new things they can store on all that space. Where I work now, I have well over a terabyte (among half a dozen servers) and at first, we didn't use more than 10% of it all. Sure enough, we're finding more and more ways to fill it. "Hey, let's inventory every machine!" Sounds good. Oh yeah, every machine stores about 500K worth of info, and oh yeah, there's about 120,000 machines. Or, hey, let's find every corporate database we have and build one huge data warehouse with all of it. Great...there's another 100GB of data. Consequently, there's always some new innovation in drive storage, allowing more data into smaller areas. Seen those new 36GB IDE drives? 3.5", 1/2 height, from IBM. Cost as much as my first 120MB drive did, but holds 300 times more data, a third the size, and I'd estimate uses 1/4 to 1/5 the power. Oh yeah, it's also probably 10-15 times faster. 10 years from now, holding 3.5 TB will probably be comparable to having a 20GB drive today. A bit on the high end, but certainly well within reach of even a normal computer household. As for moving all that data around, well, we've got gigabit ethernet breaking into all manner of places. Right now, it's mostly used for SAN's and other dedicated traffic functions, like clustering. But now that GB Ethernet switches and hubs are becoming affordable, you're seeing businesses switch to those. Where I work, they've been putting in high speed backbone connections for a while now but I imagine it won't be long before GB ethernet reaches out to each desktop. After all, GB ethernet is now an option in Compaq servers :-) Aaron _________________________________________________________________ Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers ------------------------------ Date: Sun, 8 Aug 1999 18:57:55 +0200 From: "Shot" <[EMAIL PROTECTED]> Subject: Mersenne: More basic questions Hi. I would like to thank for the fast responses to my previous question. The drawback (for you) - here go another questions: 1. I'm probably leaving my computer for a week; I would like to have Prime95 running all this time at its full speed. How can I set it to the highest priority, or is it automatically using ALL available CPU cycles? I don't use any screen saver, and I don't use any power maganement (except for my monitor). 2. Is overclocking of my Celeron 333 a good idea? I probably can't do it just now (EPoX P2-112A motherboard isn't made for such purposes), but I could upgrade it in about 2-3 months' time. 3. How are the expected completion date and the chance that "my" exponent is a prime computed? 4. How come there are 8180017 iterations for M8180017? Shouldn't there be (p - 2) iterations for Mp (since we know L(1) and don't need to know L(p))? Or am I missing somethig? Or do I just cavil at it, and it is useful to know which Mp am I checking for a first glance at Prime95 output (most probably)? 5. (To fellow Poles) Is there any ACTUAL mirror in Poland? How many Poles participate in GIMPS? Again, thanks in advance, - -- Shot __ c"? Shot - [EMAIL PROTECTED] hobbies: Star Wars, Pterry, GIMPS, ASCII `-' [EMAIL PROTECTED] join the GIMPS @ http://www.mersenne.org A sign on the lion cage at a zoo in the Czech Republic: No smoothen the lion. _________________________________________________________________ Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers ------------------------------ Date: Sun, 8 Aug 1999 15:34:44 -0400 (EDT) From: Lucas Wiman <[EMAIL PROTECTED]> Subject: Re: Mersenne: More basic questions > 2. Is overclocking of my Celeron 333 a good idea? I probably can't do > it just now (EPoX P2-112A motherboard isn't made for such purposes), > but I could upgrade it in about 2-3 months' time. No. This can often lead to errors, and newer CPU's are on the edge of sanity when it comes to heat anyway. I've heard that a Celeron can burn it self out completely in a few minutes without a heat sink. > 3. How are the expected completion date and the chance that "my" > exponent is a prime computed? The chance that your number is prime is computed using a conjecture of Wagstaff which states that: * The number of Mersenne primes less than or equal to x is about (e^gamma/log 2) * log log x. (Here gamma is Euler's constant). * The expected number of Mersenne primes 2^p-1 with p between x and 2x is about e^gamma. * The probability that 2^p-1 is prime is about (e^gamma log ap )/(p log 2) where a=2 if p=3 (mod 4) and a=6 if p=1 (mod 4). gamma is Euler's constant, ~.577, it is computed as (sum from 1 to n of 1/v)-ln(n)) > 4. How come there are 8180017 iterations for M8180017? Shouldn't > there be (p - 2) iterations for Mp (since we know L(1) and don't need > to know L(p))? Or am I missing somethig? Or do I just cavil at it, > and it is useful to know which Mp am I checking for a first glance at > Prime95 output (most probably)? L(n) is defined as (2+sqrt(3))^n+(2-sqrt(3))^n. S(n)=L(2^n), hence L(1)=S(0)=4. Just because we know what L(1) is doesn't mean it should be discounted, it is still included in the count. We are trying to find if S(p-1) mod Mp=0, if S(0)=4 then there are p iterations. - -Lucas _________________________________________________________________ Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers ------------------------------ Date: Sun, 8 Aug 1999 23:03:36 +0000 (GMT) From: Henrik Olsen <[EMAIL PROTECTED]> Subject: Re: Mersenne: redhat 6 - segfault On Fri, 6 Aug 1999, Tom Goulet wrote: > Hi all! > > My apologies if this isn't the list for pesky technical problems regarding > the GIMPS client. > > I grabbed the one specified for Red Hat 6.0, the filename (after gunzipping) > is mprime-18.1-redhat6. I try to run it...Segmentation fault (core dumped) > > This happened with the other mprime.tar.gz package as well. Is this a > known issue? Could my redhat installation be missing something that > the client needs? (I have a lot of stuff not-installed.) > > In other news, I installed the client on slackware and it worked fine. :) > (the mprime.tar.gz one) > > Any help? I've had a lot of problems with mixed glibc 2.0 and 2.1 compiled programs segfaulting immediately on start, it seemed to be a problem with proigrams compiled for 2.0, and run on a 2.1 system. (Yes, I really mean old binaries die on a new system) - -- Henrik Olsen, Dawn Solutions I/S URL=http://www.iaeste.dk/~henrik/ (Gulliver visits some places.) Lilliputian: We're small. Brobdingnagian: We're big. Horse: We can talk. (Gulliver goes home.) Gulliver: Humanity sucks. I hate people. Gulliver's Travels by Jonathan Swift; Book-A-Minute version _________________________________________________________________ Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers ------------------------------ Date: Mon, 09 Aug 1999 11:48:56 +1200 (NZST) From: Bill Rea <[EMAIL PROTECTED]> Subject: Mersenne: new accounts Gordon Bower wrote:- >Kinda depressing when you look at how little we are gaining from the new >accounts that have come into the effort the past couple months.... though >it may well be there are machines that have not yet reported their first >result and are dragging down the averages a bit. I joined in July and have several UltraSPARCs at work, well over a 1000 hours of CPU time so far. But no results yet and I'm not expecting any for at least another month or possibly more. When I joined I didn't have any idea what the differences between a Pentium and an UltraSPARC would be in this work. The Intel code is very highly optimised. From the figures given on the manual checkout page and my results to date a 270MHz UltraSPARC runs like a 120MHz Pentium. But that's only becuase I've tweaked the compiler options will help from people on this list. Initially it was performing more like a 90Mhz Pentium. I had over a 1000 hours at the lower speed before recompiling. The results will come, but not as fast as I first thought. I may have to ask for extentions of time on some exponents, but they'll get done. Bill Rea, Information Technology Services, University of Canterbury \_ E-Mail b dot rea at its dot canterbury dot ac dot nz </ New Phone 64-3-364-2331, Fax 64-3-364-2332 /) Zealand Unix Systems Administrator (/' _________________________________________________________________ Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers ------------------------------ Date: Sun, 8 Aug 1999 21:07:39 -0400 (EDT) From: Lucas Wiman <[EMAIL PROTECTED]> Subject: Re: Mersenne: new accounts > The Intel code is very highly optimised. From the figures given on > the manual checkout page and my results to date a 270MHz UltraSPARC > runs like a 120MHz Pentium. But that's only becuase I've tweaked the > compiler options will help from people on this list. Initially it > was performing more like a 90Mhz Pentium. I had over a 1000 hours > at the lower speed before recompiling. You could do factoring, the margin between factoring on a PC and an UltraSPARC should be much slimmer than LL tests. > When I joined I didn't have any idea what the differences between a > Pentium and an UltraSPARC would be in this work. The UltraSPARC would probably significantly outperform a similar megahertz PC, if we had similarly optimized code running on each. I know my friend's SPARC (running at 233 mhz, bus 233 mhz) sure does outperform my PII (running at 233 mhz, bus 66 mhz) on most things. - -Lucas _________________________________________________________________ Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers ------------------------------ Date: Sun, 8 Aug 1999 20:27:43 -0700 From: Will Edgington <[EMAIL PROTECTED]> Subject: Re: Mersenne: new accounts Lucas Wiman writes: You could do factoring, the margin between factoring on a PC and an UltraSPARC should be much slimmer than LL tests. The last time I did timings like this - admittedly, probably over a year ago, but the mers package hasn't changed much since, especially in terms of performance - this is wrong. SPARC LL testing - especially with MacLucasUNIX - is much closer to matching Prime95 LL testing than SPARC trial factoring - with mersfacgmp, say - is to matching Prime95's trial factoring, by, as I recall, a factor of about 12. Could someone out there do some new tests and send me the info? I no longer have access to any SPARCs for Mersenne stuffs. Mersfacgmp can probably be helped significantly by adjusting the size of the sieve array and how many small primes are used to check the primality of the trial factors, however; would anyone like to try some experiments? I would add detailed info the the comments in the mers Makefile so noone has to repeat the testing. The UltraSPARC would probably significantly outperform a similar megahertz PC, if we had similarly optimized code running on each. Perhaps. I know my friend's SPARC (running at 233 mhz, bus 233 mhz) sure does outperform my PII (running at 233 mhz, bus 66 mhz) on most things. I have certainly seen this for most things involving large amounts of I/O; again, not recently. But the advantage seems to disappear or even reverse to the PC's favor once cost is taken into account. Will http://www.garlic.com/~wedgingt/mersenne.html mers.tar.gz ` _________________________________________________________________ Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers ------------------------------ Date: Mon, 9 Aug 1999 00:23:37 -0400 (EDT) From: Lucas Wiman <[EMAIL PROTECTED]> Subject: Re: Mersenne: new accounts > The last time I did timings like this - admittedly, probably over a > year ago, but the mers package hasn't changed much since, especially > in terms of performance - this is wrong. SPARC LL testing - > especially with MacLucasUNIX - is much closer to matching Prime95 LL > testing than SPARC trial factoring - with mersfacgmp, say - is to > matching Prime95's trial factoring, by, as I recall, a factor of about > 12. Though I don't have specific timings, I imagine this would be the case. I was referring to the Mfactor program by Peter Montgomery. I have heard this performs considerably better than a GMP based program (written by Alex Kruppa) on RISC architectures. I suppose that I could/should check up on this with my SPARC-owning friend. > The UltraSPARC would probably significantly outperform a similar > megahertz PC, if we had similarly optimized code running on each. > Perhaps. Again, I have no timings for this, but I would think that if you tried MacLucasUNIX on both a SPARC, and a PC, the SPARC would be the overall winner because of the massive amount of I/O that runs on LL tests. In factoring, I would imagine that the difference would be smaller, (using the same program). - -Lucas _________________________________________________________________ Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers ------------------------------ Date: Mon, 9 Aug 1999 17:11:58 +0200 (MET DST) From: [EMAIL PROTECTED] Subject: Mersenne: UltraSPARC and Mfactor (was: new accounts) From: Lucas Wiman <[EMAIL PROTECTED]> writes (in response to someone else) > > The last time I did timings like this - admittedly, probably over a > > year ago, but the mers package hasn't changed much since, especially > > in terms of performance - this is wrong. SPARC LL testing - > > especially with MacLucasUNIX - is much closer to matching Prime95 LL > > testing than SPARC trial factoring - with mersfacgmp, say - is to > > matching Prime95's trial factoring, by, as I recall, a factor of about > > 12. > > Though I don't have specific timings, I imagine this would be the case. > I was referring to the Mfactor program by Peter Montgomery. I have heard > this performs considerably better than a GMP based program (written by > Alex Kruppa) on RISC architectures. I suppose that I could/should check > up on this with my SPARC-owning friend. > > > The UltraSPARC would probably significantly outperform a similar > > megahertz PC, if we had similarly optimized code running on each. > > Perhaps. > > Again, I have no timings for this, but I would think that if you tried > MacLucasUNIX on both a SPARC, and a PC, the SPARC would be the overall > winner because of the massive amount of I/O that runs on LL tests. In > factoring, I would imagine that the difference would be smaller, (using > the same program). UltraSPARC is a 64-bit architecture. The ARITHMETIC_INT64 option of Mfactor.c is intended for 64-bit architectures, but requires both halves of a 64 x 64 -> 128-bit integer product, preferably unsigned. Alpha and MIPS (and soon-to-be Merced) provide both halves, but UltraSPARC provides only the lower half, I believe. You can use the ARITHMETIC_INT32 option on SPARCs, but this restricts your search to primes below 2^60 rather than 2^63. Peter Montgomery _________________________________________________________________ Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers ------------------------------ Date: Mon, 9 Aug 1999 09:57:25 -0700 From: Will Edgington <[EMAIL PROTECTED]> Subject: Re: Mersenne: new accounts Lucas Wiman writes: Though I don't have specific timings, I imagine this would be the case. I was referring to the Mfactor program by Peter Montgomery. Oh. And I see he's already replied; from that info, I would guess that Mfactor is only slightly faster than mersfacgmp on SPARCs (and mersfacgmp can, using libgmp, factor arbitrarily far). But actual numbers would be helpful. Volunteers? Feel free to send numbers only to me, if you like. I already have some numbers for MacLucasUNIX on Macs in private email that I need to put on my web pages somewhere. Or does someone already maintain a page with timings for non-Intel CPUs? I don't recall seeing one. I have heard this performs considerably better than a GMP based program (written by Alex Kruppa) on RISC architectures. I suppose that I could/should check up on this with my SPARC-owning friend. That would be helpful, yes. Again, I have no timings for this, but I would think that if you tried MacLucasUNIX on both a SPARC, and a PC, the SPARC would be the overall winner because of the massive amount of I/O that runs on LL tests. The only large amounts of I/O are the checkpoint files. Unless you're doing them too often, they will be a small fraction of the run time. Further, MacLucasUNIX, mersenne1, mersenne2, and fftlucas know about the Intel CPU's larger floating point variables, which gives the PCs an edge. See setup.h in the mers package for details. In factoring, I would imagine that the difference would be smaller, (using the same program). This, I don't even have a real guess about; the last time I did factoring on SPARCs, they were SPARC 2's (75 MHz?), which are much slower than Ultra's. Will http://www.garlic.com/~wedgingt/mersenne.html mers.tar.gz mers.tgz _________________________________________________________________ Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers ------------------------------ Date: Mon, 09 Aug 1999 19:25:33 +0200 From: Sturle Sunde <[EMAIL PROTECTED]> Subject: Re: Mersenne: new accounts > But actual numbers would be helpful. Volunteers? Feel free to send > numbers only to me, if you like. I already have some numbers for > MacLucasUNIX on Macs in private email that I need to put on my web > pages somewhere. Or does someone already maintain a page with timings > for non-Intel CPUs? I don't recall seeing one. How do you want us to do the timings? Will factoring any number from 1 to 2^50 do, is 2^55 to 2^56 better, or how about 2^64 to 2^64 + 2^56? What is the best way to time MacLucasUNIX for i.e. 5000 iterations, and be sure to get CPU-time, not wall-time? I guess you want the numbers for different FFT sizes? What other information do you need? I think you are going to get more, more compareable and more useful benchmarks if you descripe exactly what to benchmark and how to do it. - -- Sturle URL: http://www.stud.ifi.uio.no/~sturles/ Er det m}ndag i dag? ~~~~~~ MMF: http://www.alladvantage.com/go.asp?refid=BUP399 - St. URLe _________________________________________________________________ Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers ------------------------------ Date: Mon, 09 Aug 1999 13:25:06 -0400 From: Yvan Dutil <[EMAIL PROTECTED]> Subject: Re: Mersenne: Moore's Law and Primenet >Kinda depressing when you look at how little we are gaining from the new >accounts that have come into the effort the past couple months.... though >it may well be there are machines that have not yet reported their first >result and are dragging down the averages a bit. Dont forget! This is summer, this mean many participant may be in vacation and have there computer close. I bet we go up in september. Yvan Dutil _________________________________________________________________ Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers ------------------------------ Date: Tue, 10 Aug 1999 16:25:05 +0200 From: "Shot" <[EMAIL PROTECTED]> Subject: Mersenne: The list's archives Hi. I would like to know where I can find the list's recent archives. I followed the links from GIMPS' page, to http://www.scruznet.com/~luke/archives/digest/ page. All I found there were the digests dated 8 July 1996 (file v01_0001.txt) to 7 June 1998 (file v01_0375.txt) - these were packed into 01_001.zip to 01_015.zip files. There are also unpacked files v01_0351.txt to v01_408.txt, which is about (I couldn't check exactly, so I guess) mid-August '98. The problem is I digged through these 1-375 editions (it took me about five days, skipping some topics uninteresting to a GIMPS newbie like myself), and I'm now downloading those 376-408 issues (it would be much easier if they also were packed). But what should I do when I read them all? Are there any more past digests (packed, preferably)? I just don't want to post questions that were answered recently, because I know how annoying this is (from reading those digest, for example). Best wishes - -- Shot __ c"? Shot - [EMAIL PROTECTED] hobbies: Star Wars, Pterry, GIMPS, ASCII `-' [EMAIL PROTECTED] join the GIMPS @ http://www.mersenne.org On a box of a clockwork toy in Hong Kong: Guaranteed to work throughout its useful life. _________________________________________________________________ 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 #612 ******************************
