Mersenne Digest Tuesday, September 21 1999 Volume 01 : Number 629 ---------------------------------------------------------------------- Date: Sun, 19 Sep 1999 21:36:01 -0400 From: Jeff Woods <[EMAIL PROTECTED]> Subject: Re: Mersenne: M(M(127)) and other M(M(p)) At 08:51 PM 9/19/99 -0400, you wrote: >prime, unless we find a factor. Interestingly enough, when we find the next >Mersenne prime, searching for a factor of M(M(p)) might allow us to find an >even bigger prime. If for example, 6*M(p)+1 divides M(M(p)), then it must >be prime! Which one must be prime? 6*M(p)+1, or M(M(p))? And why? Enquiring minds, and all.... Thanks! >Wait, that might just be the reason to search! Will only searched up to >k=4 for M(M(6972593)), but if 2*k*M(p)+1 divides M(M(p)), then you've just >beaten the world record! Non-Mersenne's might once again grace the top >10 list! An interesting concept -- what sort of time factor would it take to prove such a thing with an average computer? _________________________________________________________________ Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers ------------------------------ Date: Sun, 19 Sep 1999 21:33:53 -0400 From: "Chris Nash" <[EMAIL PROTECTED]> Subject: Re: Mersenne: M(M(127)) and other M(M(p)) > even bigger prime. If for example, 6*M(p)+1 divides M(M(p)), then it must > be prime! Before anybody gets overexcited at the last posting... It is TRUE that if 2k.M(p)+1 divides M(M(p)), M(p) is prime, and k<2M(p)+2, then 2k.M(p)+1 is prime. However, unless I'm mistaken, non-divisibility does not prove compositeness. You could walk past a prime (in fact, you'd expect to walk past several) and you'd never know... Chris _________________________________________________________________ Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers ------------------------------ Date: Sun, 19 Sep 1999 22:27:59 -0400 (EDT) From: Darxus <[EMAIL PROTECTED]> Subject: Mersenne: GIMPS client output Iteration: 164000 / 8410531 [1%]. Clocks: 115665753 = 0.496 sec. Might be nice to display the percentage out to an accuracy that changes every hundred iterations. Hmm, looks like that's an integer of the percentage, not rounded. Guess it doesn't matter. For the one I'm working on it looks like 3 decimal places would be needed to see a change every 100 iterations. __________________________________________________________________ PGP fingerprint = 03 5B 9B A0 16 33 91 2F A5 77 BC EE 43 71 98 D4 [EMAIL PROTECTED] / http://www.op.net/~darxus Join the Great Internet Mersenne Prime Search http://www.mersenne.org/prime.htm _________________________________________________________________ Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers ------------------------------ Date: Sun, 19 Sep 1999 22:59:37 -0400 From: "Rick Pali" <[EMAIL PROTECTED]> Subject: RE: Mersenne: GIMPS client output From: Darxus > Iteration: 164000 / 8410531 [1%]. Clocks: 115665753 = 0.496 sec. > > Might be nice to display the percentage out to an accuracy that > changes every hundred iterations. If you're using version 19, add "PercentPrecision=3" to the prime.ini file. If you want more than three decimal places, change the number...I believe it'll go up to six. I believe that four should be sufficient as even M33219281 changes every three or four hundred iterations with three places displayed. Rick. - -+--- [EMAIL PROTECTED] http://www.alienshore.com/ _________________________________________________________________ Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers ------------------------------ Date: Sun, 19 Sep 1999 23:05:39 -0400 (EDT) From: Lucas Wiman <[EMAIL PROTECTED]> Subject: Re: Mersenne: GIMPS client output > Might be nice to display the percentage out to an accuracy that changes > every hundred iterations. Hmm, looks like that's an integer of the > percentage, not rounded. Guess it doesn't matter. For the one I'm > working on it looks like 3 decimal places would be needed to see a change > every 100 iterations. This is changed in V19 (currently in Beta). I believe (George correct me if I'm wrong) that you can specify it up to 6 decimal places. - -Lucas _________________________________________________________________ Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers ------------------------------ Date: Sun, 19 Sep 1999 23:24:41 -0400 From: "Chris Nash" <[EMAIL PROTECTED]> Subject: Re: Mersenne: M(M(127)) and other M(M(p)) Hi Jeff > >prime, unless we find a factor. Interestingly enough, when we find the next > >Mersenne prime, searching for a factor of M(M(p)) might allow us to find an > >even bigger prime. If for example, 6*M(p)+1 divides M(M(p)), then it must > >be prime! > Which one must be prime? 6*M(p)+1, or M(M(p))? > And why? Enquiring minds, and all.... Thanks! Just to clarify... and make sure my own thinking isn't muddled on this issue. Let q be a factor of M(p), p a prime. We know all factors of M(p) are of the form 2kp+1. So all factors of q must be of that form too. It follows then that if q<(2p+1)^2, q is necessarily prime. On the surface it looks like a great shortcut in primality testing, taking as long as it would take to test a number the size of p to test a number that could be as large as 4p^2. In practice though you'd have to be very lucky to find such a q, and failure does not necessarily prove compositeness. Perhaps though there's a lucky prime or two to be discovered because of it :) Chris _________________________________________________________________ Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers ------------------------------ Date: Sun, 19 Sep 1999 21:22:04 -0700 From: Eric Hahn <[EMAIL PROTECTED]> Subject: Re: Mersenne: GIMPS client output >Iteration: 164000 / 8410531 [1%]. Clocks: 115665753 = 0.496 sec. > >Might be nice to display the percentage out to an accuracy that changes >every hundred iterations. Hmm, looks like that's an integer of the >percentage, not rounded. Guess it doesn't matter. For the one I'm >working on it looks like 3 decimal places would be needed to see a >change every 100 iterations. v19 allows this by manually adding 'PercentPrecision=' to the PRIME.INI file (Prime95 must be stopped and exited before editing, and then restarted). The valid range after the '=' is 0 to 6, therefore you can have it say: Iteration: 164000/8410531 [1.949936%]. Per iteration time: 0.496... Iteration: 164100/8410531 [1.951125%]. Per iteration time: 0.496... Mind you, even at the limit of v19 (79.3M), setting it to a value of 4, and having screen outputs at every 100 iterations, will still cause the value to increase (although by 0.0001%) Eric Hahn P.S. At the 79.3M range, you'll probably not want to set it at 100 iterations... Per iteration time on 266MHz PII with 64MB RAM is 58.781 seconds!!! (Yes, it's true, but I'm also just checking to see if anybody's awake :)) _________________________________________________________________ Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers ------------------------------ Date: Mon, 20 Sep 1999 01:06:15 -0400 From: "Rick Pali" <[EMAIL PROTECTED]> Subject: RE: Mersenne: GIMPS client output From: Eric Hahn > P.S. At the 79.3M range, you'll probably not want to set it > at 100 iterations... Per iteration time on 266MHz PII with > 64MB RAM is 58.781 seconds!!! The only question that comes to mind is if you had to plough through factoring before you got to the LL test...but then I realise that you still wouldn't be done if that were true. I signed up for an exponent in the 33mil range and the factoring alone took 13 days on a P3-500. I'd originally does it for testing purposes, but after that I've just got to let it continue. :-) In a year's time, I'd love to see some numbers on how many signed up for tem million digit numbers and later quit for smaller exponents... Rick. - -+--- [EMAIL PROTECTED] http://www.alienshore.com/ _________________________________________________________________ Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers ------------------------------ Date: Mon, 20 Sep 1999 12:33:20 +0200 From: "Shot" <[EMAIL PROTECTED]> Subject: Mersenne: Expected completion date Hi. I just finished my first LL test. I know I shouldn't broadcast this to the list, but I couldn't resist; so, here goes... M8180017 is NOT prime!!! ;) Now, back to reality... At 8178600th iteration I checked the status window, and it showed that Prime95 will be working on this for the next 5 hrs 25 mins... So I took my calculator, and asked him: (8180017-8178600)*0.430=? He said something about his aching buttons, but finally answered: 609,31 So, it seemed like 10 mins 10 secs later I will be given the naked truth about M8180017. That's like 5 hrs 14 mins 50 secs earlier than Prime95 thought... But when I restarted Prime95, it showed the right end-time (10 mins). So, my guess is, this calculations are based on some data saved when Prime95 closes - could those data be saved every time the status window is opened? That would lead to the right calculations, right? Thanks for your time, - -- Shot PS: On second thought - maybe it was because Prime95 was told it will be running 18 hrs/day, and it was 24 hrs/day? __ c"? Shot - [EMAIL PROTECTED] hobbies: Star Wars, Pterry, GIMPS, ASCII `-' [EMAIL PROTECTED] join the GIMPS @ http://www.mersenne.org Science Explained (by Kids): Cyanide is so poisonous that one drop of it on a dogs tongue will kill the strongest man. _________________________________________________________________ Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers ------------------------------ Date: Mon, 20 Sep 1999 13:15:20 +0200 From: Alexander Kruppa <[EMAIL PROTECTED]> Subject: Re: Mersenne: M(M(127)) and other M(M(p)) Hi, I just tried a quick run of Georges new P-1 code on M(M(17)), and lo! [cut] At prime 499549. Time thusfar 1707.604 sec. (341520836670 clocks) Stage 1 complete. 365804 transforms. Time: 1717.294 sec. (343458751180 clocks) Stage 1 GCD complete. Time: 19.737 sec. (3947333454 clocks) M131071 has a factor: 14899621191992882743 That wan't hard. But one thing puzzles me: P-1 = 2*3*61*6229*131071*49861943 The factor was found after stage 1 with a limit of 500000 - how can it find a factor which is 1 mod (49861943) ? Another magic trick by George? Ciao, Alex. > I checked Chris Caldwell's pages on this, and Curt Noll's trial-factored > M(M(127)) to 5.10^50, surprisingly low considering the size of M(127) > itself, I noticed many other M(M(p)) as listed in > http://www.garlic.com/~wedgingt/MMPstats.txt have only been tested to very > low limits indeed. > > I wondered why there wasn't more work done on these - though I understand > it's very hard to motivate people when Guy's law of small numbers no doubt > applies, but everything M(M(61)) and above is currently unknown. It would be > nice to see a few more results there. > > Chris _________________________________________________________________ Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers ------------------------------ Date: Mon, 20 Sep 1999 14:11:43 +0200 From: Alexander Kruppa <[EMAIL PROTECTED]> Subject: Re: Mersenne: M(M(127)) and other M(M(p)) Alexander Kruppa wrote: > > Hi, > > M131071 has a factor: 14899621191992882743 > > That wan't hard. But one thing puzzles me: > > P-1 = 2*3*61*6229*131071*49861943 > > The factor was found after stage 1 with a limit of 500000 - how can it > find a factor which is 1 mod (49861943) ? Another magic trick by George? No, it's because you're stupid! This new factor is really two old factors in disguise: 231733529 * 64296354767 = 14899621191992882743 and that explains nicely why they were found with B1=500000: 231733529 = 2*2*2*13*17*131071+1 64296354767 = 2*7*37*947*131071+1 I should try to remember keeping my lowm.txt file updated. Ciao, Alex. _________________________________________________________________ Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers ------------------------------ Date: Mon, 20 Sep 1999 08:20:43 -0400 From: Tom Goulet <[EMAIL PROTECTED]> Subject: Re: Mersenne: complaint - --Q68bSM7Ycu6FN28Q Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Greetings again, Thank you for your responses and stuff. I am de-confused. I understand the relationship between the gimps and entropia.com, pretty mu= ch. After upgrading to the latest mprime, the segfault problems are gone. (segfault due to less than 16MBs of RAM, and segfault after goign to Option= s/ CPU in the preferences don't happen anymore.) Yes, I was worried about being polite when I wrote my e-mail, because I was annoyed and wasn't sure how I was going to sound. =20 Thanks for the SysV init script, I was trying to write one of those, but I don't know how :) That's how I ended up running two or three copies of mprime in the first place. (Start worked, stop didn't.) Now try this, make a temporary directory, copy all your ordinary mprime fil= es into it. Do something like this: =2E/mprime & ./mprime & ./mprime & wait...ten seconds then run something likes this: killall mprime (making sure that you don't kill the one you want to keep running) I find that my p###### file is gone! TomG - --Q68bSM7Ycu6FN28Q Content-Type: application/pgp-signature - -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.0 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE35iabeft5KNi607wRAvvQAJ95T34ZLNTi49s3xeHRGIyJ0pFgNQCg3Ccz zKt6/ospBZJO+zq3yuMkkg8= =r+wg - -----END PGP SIGNATURE----- - --Q68bSM7Ycu6FN28Q-- _________________________________________________________________ Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers ------------------------------ Date: Mon, 20 Sep 1999 09:52:18 -0400 (EDT) From: Lucas Wiman <[EMAIL PROTECTED]> Subject: Re: Mersenne: Factor of 2^(2^31-1)-1 found ($) > >All (and especially Chris), > > > >Yesterday (and the day before), I went to the Illinois number theory > conference. > >There (2nd talk of yesterday) J. P. Selfridge announced that he would > >give away $1000 US for any factor found of a number which ought to be > >prime (he provided a list). On that list was 2^(2^31-1)-1. > > Please post the list of candidates, to the mailing list. > > > Ken F_m for m=14,20,22,24,31 M(M(p)) for p=31,61,127 M(B(p)) for p=31,61,127 F_m for m=2^k+k k>=6 B(p)=(2^p+1)/3 - -Lucas _________________________________________________________________ Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers ------------------------------ Date: Mon, 20 Sep 1999 10:10:49 -0400 From: George Woltman <[EMAIL PROTECTED]> Subject: Re: Mersenne: Expected completion date Hi, At 12:33 PM 9/20/99 +0200, Shot wrote: >At 8178600th iteration I checked the status window, and it showed >that Prime95 will be working on this for the next 5 hrs 25 mins... > >So, it seemed like 10 mins 10 secs later I will be given the naked >truth about M8180017. That's like 5 hrs 14 mins 50 secs earlier than >Prime95 thought... Prime95 updates this information on a program restart (as you found out) and every 65536 iterations. I've fixed it to update this every 128 iterations. The 18 vs. 24 hours a day info will cause the estimate to be off by 25% as prime95 assumes the 6 off hours are distributed uniformly throughout the day. Keep those bug reports coming, George _________________________________________________________________ Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers ------------------------------ Date: Mon, 20 Sep 1999 09:11:20 -0700 From: Eric Hahn <[EMAIL PROTECTED]> Subject: RE: Mersenne: GIMPS client output Rick, Glad to see *somebody's* awake!! <grin> >From: Eric Hahn > >> P.S. At the 79.3M range, you'll probably not want to set it >> at 100 iterations... Per iteration time on 266MHz PII with >> 64MB RAM is 58.781 seconds!!! > >The only question that comes to mind is if you had to plough >through factoring before you got to the LL test...but then I >realise that you still wouldn't be done if that were true. You're right! Even on a P3-500, it'd take 7-8 months to plough through all the factors to 2^72. I intentionally told it that it had been factored thru 2^73 to prevent it from doing such. This was for a test I was running... >I signed up for an exponent in the 33mil range and the factoring >alone took 13 days on a P3-500. I'd originally does it for testing >purposes, but after that I've just got to let it continue. :-) I've got 2 machines working on 10M digit exponents. One will work until completion, while the other will be forced to trial-factor only (a feature not offered in v19 which I've mentioned to George). >In a year's time, I'd love to see some numbers on how many signed >up for tem million digit numbers and later quit for smaller >exponents... Well, let's see... You got yours assigned Sept. 5 at 3:38 UTC. 14 exponents assigned, 3 factored, 11 still in progress... and counting... Interesting to note, however, that 2 of the exponents factored and 1 still in progess had factors listed on Alex Kruppa's site: http://www.informatik.tu-muenchen.de/~kruppa/M33M/index.html before 10M digit exponents were assigned by IPS. Which ones?? 33,219,341 and 33,219,469 and 33,219,707 (33,219,341 was assigned by IPS to Alex, BTW <g>) Eric Hahn _________________________________________________________________ Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers ------------------------------ Date: Tue, 21 Sep 1999 01:58:24 -0500 From: Warut Roonguthai <[EMAIL PROTECTED]> Subject: Mersenne: Important info on M(M(p)) from Wilfrid Keller - ---------- Forwarded message ---------- Date: Mon, 20 Sep 1999 19:55:53 +0200 (DFT) From: Wilfrid Keller <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] September 20, 1999 Dear Warut, Dear Colleagues: Concerning the subject of Mersenne numbers M(q) = 2^q - 1, where q = 2^p - 1 itself is a Mersenne prime, I am sorry I hadn't seen your relevant web page before. As the factor of M(M(13)) that I had found in 1976 might suggest, I have shown interest in this particular kind of Mersenne numbers since many, many years. Re- garding the factor of M(M(31)) just rediscovered by Lucas Wiman, I regret to inform you that it was already "published" in 1983. Unfortunately, Guy Haworth's notes (please see the references be- low) were released only "privately", but were in fact widely cir- culated. The second prime factor of M(M(31)), found by Tony Forbes, was also known to me for some years (again, see below). Let me take this opportunity to communicate to you the complete records of my search for factors of numbers M(M(p)), particular- ly including the attained limits, which may help to avoid further duplication. Also, please note that M(M(127)) was shown to have no factor 2h x M(127) + 1 for h < 6.8 x 10^8. If you should find it of interest to forward my data to some per- tinent mailing list (NMBRTHRY or so), please feel free to do so. And if you have any questions related to this topic, I would be glad to respond. With my best wishes to all of you, Wilfrid Keller [PS: This note is by no means intended to earn the money allegedly offered for a proof that M(M(31)) is not a prime. Anyway, the reward would have been for discovering a factor, and not for giving a reference where to look it up, I suppose.] Known prime factors 2h*M(p) + 1 of "iterated" Mersenne numbers M(M(p)) as of November 1996 p h Discoverer References 13 20644229 Keller Haworth [1983], Ribenboim [1988] 17 884 Robinson Robinson [1957] 17 245273 Keller Haworth [1983] 19 60 Robinson Robinson [1957] 19 5480769 Keller Found Aug 20, 1994 (unpublished) 31 68745 Keller Haworth [1983] 31 20269004 Keller Found Aug 28, 1994 (unpublished) References - ---------- Raphael M. Robinson, Some factorizations of numbers of the form 2^n +/- 1, MTAC (Math. Comp.) 11 (1957), 265-268. Guy Haworth, Mersenne Numbers, Reading, Berkshire, 1983 (privately published notes), and subsequent updates. quoted as reference #203 in Daniel Shanks, Solved and Unsolved Problems in Number Theory, 3rd ed., Chelsea, New York 1985, and as reference #223 in John Brillhart, D.H. Lehmer, J.L. Selfridge, Bryant Tuckerman, and S.S. Wagstaff, Jr., Factorizations of b = 2, 3, 5, 6, 7, 10, 11, 12 up to high powers, 2nd ed., American Mathematical Society, Providence, Rhode Island, 1988. Paulo Ribenboim, The Book of Prime Number Records, Springer, New York 1988, p. 80. Search limits h < L(p) for factors of "iterated" Mersenne numbers M(M(p)) as of November 1996 p L(p) 13 6.7 x 10^8 17 3.3 x 10^8 19 4.0 x 10^8 31 3.1 x 10^8 61 7.5 x 10^8 89 5.3 x 10^8 107 5.2 x 10^8 127 6.8 x 10^8 521 3.6 x 10^5 607 3.4 x 10^5 _________________________________________________________________ Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers ------------------------------ Date: Mon, 20 Sep 1999 22:09:11 +0300 From: Jukka Santala <[EMAIL PROTECTED]> Subject: Mersenne: Prime95 v19 oops... Something I forgot from earlier playing, the manual factoring savefiles on Prime95 v19 at least don't work out too well especially on dual-CPU machines... Since these savefiles will always be named "p0000000" regardless of the -A parameter and exponent to test ;) It isn't the first time I've suddenly found both CPU's crunching away on the same factoring assignment... Oh well. -Donwulff _________________________________________________________________ Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers ------------------------------ Date: Mon, 20 Sep 1999 23:43:21 +0200 From: "Steinar H. Gunderson" <[EMAIL PROTECTED]> Subject: Re: Mersenne: Timing(?) errors On Mon, Sep 20, 1999 at 09:49:51AM -0500, Willmore, David wrote: >Not really much you can do. The way windows hands out memory almost >guarentees TLB and L2 cache thrashing. Yeah, but some of the same problems are present when it comes to Linux... Perhaps I should go back to ReCache... Perhaps as a cron job? `Flush the darn caches every hour -- this ain't no fileserver' :-) >Unless the code can look up the physical address where it's data >is stored and ensure the correct alignment, there's not much that can be >done--in a controled fashon. I didn't think the alignment was a problem? And would looking up the real, physical address be any easier in Linux? (The code could run with root access, if neccessary...) But perhaps you don't know anything about Linux at all, and I'm just throwing out questions in the wild... Guess a cc to [EMAIL PROTECTED] is in order. (Thanks to all you replyers, BTW.) >Good weekend? If you asked if I had a good weekend, the answer was yes, I had. Thank you very much :-) (Now only one more week, and we'll have a week's vacation. Sometimes, going to school is not that stupid...) /* 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: Mon, 20 Sep 1999 17:45:17 -0500 From: "Willmore, David" <[EMAIL PROTECTED]> Subject: RE: Mersenne: Timing(?) errors > On Mon, Sep 20, 1999 at 09:49:51AM -0500, Willmore, David wrote: > >Not really much you can do. The way windows hands out memory almost > >guarentees TLB and L2 cache thrashing. > > Yeah, but some of the same problems are present when it comes to Linux... > Perhaps I should go back to ReCache... Perhaps as a cron job? `Flush the > darn caches every hour -- this ain't no fileserver' :-) > Since it's a cache reading problem there's no real way to 'flush' it. Normally, that means to write back dirty data to whatever backing store exists, not 'invalidate everything'. Even if you did, it would't solve the problem. > >Unless the code can look up the physical address where it's data > >is stored and ensure the correct alignment, there's not much that can be > >done--in a controled fashon. > > I didn't think the alignment was a problem? > Anyone correct me here, but this sounds like an L2 cache alias thrashing the cache kind of problem. Let me see if I can explain it. Okay, quickly as I can, here's how caches work. A cache is composed of 'lines'. In the Intel arch, a line is normally 32b. This is the minimum size of data reads and writes on the main memory side of the cache. A 256K cache would be composed of 8K lines of 32b each. Call the cache C[x] where x is the number of the line. If this is a 'direct mapped' cache, each C[x] can store the contents of one main memory line(32b in this case). A table called the 'tag' is used to store *which* place the data came from. Let's call this T[x]. Here's how a simple 256K direct mapped cache works. The address 'a' coming out of the processor is broken down into two sections. Call them T_loc(x) and L(x). T_loc is the tag location and L is the line--for a particular 'x' or locaiton in main memory. In this case, T_loc(x) = x/256K/32 and L(x)=(x mod 256K/32). To check if something is in the cache, we calculate T_loc(x) to find what index into the tag array at which to look. If the contents T[L(x)] = T_loc(x) then the line L(x) in the cache C[x] contains our data (at location L(x)). The nice property of this is that division by powers of two is free. Basically there is *no* calculation involved here, just runing wires about this is a Good Thing(tm) as it's very quick. The bad side is that x and x+256K both have the same L(x) and are not part of the same line. When the circuitry detects this, it means that your data is not in the cache and the cache line, if dirty--written to, but not updated in main memory--must be written back and then the new line read in. This process takes a lot of time and is exactly what the cache is there to avoid. If you repeatedly access data in a manner which causes the cache to load/unload lines like this, you 'thrash' the cache--you beat it up. Associative caches--like the L2 of a PII/PIII or Celeron--is '4 way set associative'. This means that C[x] and T[x] are two dimensional. This makes things nicer. For an access, you need to look in T[L(x),z] = T_loc(x) where z is in {0,1,2,3}. If it's in any of them, you lookup your data in the appropriate 'set' of C[]. If not, then you have missed the cache and must unload a line/load the new one. Since you have four places to put the line, you can access four locations in memory which have the same location in the cache and *not* thrash the cache. This is good. Of course, if you access a *fifth* location in that set, you start thrashing. What does this have to do with the Prime95 and mprime? Well, depending on where the OS allocates your data storage, you may have or not have thrashing problems. There is no clean way to ensure this as a user. Linux has some cache 'coloring' considerations built into the memory allocator. Each line in the cache gets as many colors as it has sets and the memory manager tries not to give you pages of the same color if they are in the same cache 'line'. Of course, if you ask for more memory than the L2 is big, it has no choice. Once you ask for something that big, it just falls down to chance on how the pages will be allocated. > And would looking up the real, physical address be any easier in Linux? > (The code could run with root access, if neccessary...) But perhaps you > don't know anything about Linux at all, and I'm just throwing out > questions > in the wild... Guess a cc to [EMAIL PROTECTED] is in order. (Thanks to all > you replyers, BTW.) > Yes, it would probably be easier in Linux, but it might not do you any good. Cheers, David _________________________________________________________________ Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers ------------------------------ Date: Tue, 21 Sep 1999 01:13:04 +0100 From: Tony Forbes <[EMAIL PROTECTED]> Subject: Re: Mersenne: Important info on M(M(p)) from Wilfrid Keller >From: Wilfrid Keller <[EMAIL PROTECTED]> >I had found in 1976 might suggest, I have shown interest in this >particular kind of Mersenne numbers since many, many years. Re- >garding the factor of M(M(31)) just rediscovered by Lucas Wiman, >I regret to inform you that it was already "published" in 1983. >Unfortunately, Guy Haworth's notes (please see the references be- >low) were released only "privately", but were in fact widely cir- >culated. The second prime factor of M(M(31)), found by Tony >Forbes, was also known to me for some years (again, see below). I must admit that at the time I found it, I suspected this second factor of M(M(31)) might not be new; it seemed too easy. >Search limits h < L(p) for factors of >"iterated" Mersenne numbers M(M(p)) as of November 1996 > > p L(p) > > 127 6.8 x 10^8 I was working on M(M(127)) about 2 years ago. I completed ranges of h (for possible divisors 2*h*M(127)+1) 0 - 129729600000 360360000000 - 390390000000 390390000000 - 420420000000 450450000000 - 480480000000 and was part way through ranges 129729600000 - 240240000000 240240000000 - 360360000000 420420000000 - 450450000000 480480000000 - 540540000000 when I found out than Curt Noll had started an attack on M(M(127)) with superior hardware. I imagine that by now he has carried the search much further. - -- Tony _________________________________________________________________ Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers ------------------------------ Date: Mon, 20 Sep 1999 18:24:36 -0700 From: Eric Hahn <[EMAIL PROTECTED]> Subject: Mersenne: Interesting PrimeNet Error Ah, here's something interesting... I was working on a machine which was running Prime95 (v18, BTW, and in a visible window), when it decided to contact PrimeNet. No Problem! It sent the text messages about trial-factoring until: [...] Sending text message to server: M10461667 has a factor: 7841028322998353783 Sending expected completion date for M10461667: Sep 21 1998 ERROR 11: Exponent already tested. [...] Yes, the expected completion date message was expected as the machine was still testing (for smaller factors), and was sitting at 1275205555*2^32 (Pass 5 of 16) at the time it did this... I just found it interesting that PrimeNet would produce an error like this. What would happen if Prime95 should happen to find a smaller factor? Would it be accepted? Hmmmm..... Eric Hahn _________________________________________________________________ Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers ------------------------------ Date: Mon, 20 Sep 1999 22:23:15 -0400 (EDT) From: Lucas Wiman <[EMAIL PROTECTED]> Subject: Re: Mersenne: Important info on M(M(p)) from Wilfrid Keller [...] > when I found out than Curt Noll had started an attack on M(M(127)) with > superior hardware. I imagine that by now he has carried the search much > further. This is further evidence for why GIMPS is such a good idea! (as if we needed more) If Curt Noll and you have been working together, your computer time would not have been wasted, nor would (presumably) much of his. This is the beauty of distributed computing projects, but this illistrates how *key* centrilization is. Now, I think that it might be a nifty (tm) idea if GIMPS/primenet were to start looking for factors of double Mersenne numbers. If I understand correctly, much of the code is already written (changes to the P-1 code, and the normal factoring code), and I'm sure that such things could interest mathematicians more than finding the next Mersenne prime. With the (possibly buggy) announcement of prize money from J. L. Selfridge, I'm sure that interest should increase very quickly... - -Lucas _________________________________________________________________ Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers ------------------------------ Date: Mon, 20 Sep 1999 21:10:52 -0700 From: Eric Hahn <[EMAIL PROTECTED]> Subject: Mersenne: Iteration Times (was: GIMPS client output) Okay, okay... obviously a lot of people were awake <sigh> (you can stop flooding me with emails!!) In a previous message I wrote: >P.S. At the 79.3M range, you'll probably not want to set it >at 100 iterations... Per iteration time on 266MHz PII with >64MB RAM is 58.781 seconds!!! (Yes, it's true, but I'm also >just checking to see if anybody's awake :)) I went back to the exponent in question and ran another test. There are a couple of notes here: 1) This originally was done for a particular test in QA. 2) George didn't have the new timings up at the time. 3) I thought it was high myself, but what did I know? What I found was: 1) I obviously had something running in the background I was not aware of. 2) The actual time dropped to 4.231 sec/iter 3) Amazingly, there didn't appear to be much HDD paging happening except went you hit 'STOP'! BTW, for those of you who don't know (or actually asked), these exponents use 4096K FFT runlengths, and 16M save files... Eric Hahn _________________________________________________________________ Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers ------------------------------ Date: Tue, 21 Sep 1999 17:33:24 +0200 From: "Steinar H. Gunderson" <[EMAIL PROTECTED]> Subject: Mersenne: Re: Timing(?) errors On Mon, Sep 20, 1999 at 05:45:17PM -0500, Willmore, David wrote: >Since it's a cache reading problem there's no real way to 'flush' it. >Normally, that means to write back dirty data to whatever backing store >exists, not 'invalidate everything'. Even if you did, it would't solve the >problem. How does swap space come into this? Linux isn't forced to swap the data in exactly where it used to be, is it? >[removed excellent explanation on what's going on] Thanks. :-) >Yes, it would probably be easier in Linux, but it might not do you any good. Perhaps I could do a manual restart if it was a problem? (I can thing of several crazy ways to do this... Perhaps fill the all the buffers with some random number, and find them in /proc/kcore? ;-) ) /* 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: Tue, 21 Sep 1999 09:47:30 -0700 (PDT) From: James Escamilla <[EMAIL PROTECTED]> Subject: Re: Mersenne: Iteration Times (was: GIMPS client output) Wouldn't the run time at 4.231 be about 10 years? - --- Eric Hahn <[EMAIL PROTECTED]> wrote: > > Okay, okay... obviously a lot of people were awake > <sigh> > (you can stop flooding me with emails!!) > > In a previous message I wrote: > > >P.S. At the 79.3M range, you'll probably not want > to set it > >at 100 iterations... Per iteration time on 266MHz > PII with > >64MB RAM is 58.781 seconds!!! (Yes, it's true, but > I'm also > >just checking to see if anybody's awake :)) > > I went back to the exponent in question and ran > another test. > > There are a couple of notes here: > 1) This originally was done for a particular test > in QA. > 2) George didn't have the new timings up at the > time. > 3) I thought it was high myself, but what did I > know? > > What I found was: > 1) I obviously had something running in the > background > I was not aware of. > 2) The actual time dropped to 4.231 sec/iter > 3) Amazingly, there didn't appear to be much HDD > paging > happening except went you hit 'STOP'! > > BTW, for those of you who don't know (or actually > asked), > these exponents use 4096K FFT runlengths, and 16M > save > files... > > Eric Hahn > > > _________________________________________________________________ > Unsubscribe & list info -- > http://www.scruz.net/~luke/signup.htm > Mersenne Prime FAQ -- > http://www.tasam.com/~lrwiman/FAQ-mers > __________________________________________________ Do You Yahoo!? Bid and sell for free at http://auctions.yahoo.com _________________________________________________________________ Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers ------------------------------ Date: Tue, 21 Sep 1999 14:03:54 -0500 From: "Willmore, David" <[EMAIL PROTECTED]> Subject: RE: Mersenne: Re: Timing(?) errors > On Mon, Sep 20, 1999 at 05:45:17PM -0500, Willmore, David wrote: > >Since it's a cache reading problem there's no real way to 'flush' it. > >Normally, that means to write back dirty data to whatever backing store > >exists, not 'invalidate everything'. Even if you did, it would't solve > the > >problem. > > How does swap space come into this? Linux isn't forced to swap the data > in exactly where it used to be, is it? > Correct, it does not. Normally, though, when you're swapping, proper L2 cache coloring is the least of your performance problems. > >Yes, it would probably be easier in Linux, but it might not do you any > good. > > Perhaps I could do a manual restart if it was a problem? (I can thing of > several crazy ways to do this... Perhaps fill the all the buffers with > some random number, and find them in /proc/kcore? ;-) ) > A syscall that walked the page tables to find the translation for an address would probably the easiest. Cheers, David _________________________________________________________________ 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 #629 ******************************
