Mersenne Digest Friday, June 23 2000 Volume 01 : Number 750 ---------------------------------------------------------------------- Date: Mon Jun 19 18:00:02 2000 From: [EMAIL PROTECTED] Subject: Re: Mersenne: Prime64? Jason Papadopoulos wrote: > Moving to IA64 will be a much bigger challenge than simply rewriting > half a meg of assembly language. That's why I'm hoping the SGI open source compilers for IA-64 are decent (see http://oss.sgi.com/projects/Pro64/ ); at least in the near-term one could then simply compile one of the HLLLL (High-level-language Lucas-Lehmer; how's that for a tortured acronym? :) codes on the IA-64 and hopefully get performance at least as good as on the Alpha 21264. For instance Mlucas is already geared toward register- rich architectures (hey, I'm a greedy guy), and I've also written some extra radix-32 FFT-pass routines that yield marginal benefit on the 21264 (fewer passes through the data appear to be offset by slowdowns due to register pressure), but which should incur little or no register pressure on the IA-64. Guillermo Ballester Valor's recently announced Ylucas code is quite similar, so we can try out both the SGI Fortran-90 and C compilers for IA-64 under Linux. > Can you rearrange a real-valued FFT > to use multiply-adds as much as possible? It could cut the operation count > in half if you do, but to my knowledge no one has yet done so. Note that the 21264 has no multiply/add instruction and can do at most one FADD and one FMUL per cycle, but even so, Mlucas on 21264 gets nearly double the performance on the 21264 as Prime95 on the PII. Thus one could legitimately hope for performance that is better still on the IA-64, even without major restructuring of the source code to take advantage of the MADD instruction (or whatever it's called on the IA-64; MADD is the MIPS mnemonic). Assume the complex twiddles phase at the start of each FFT-pass data block processing run no faster with MADD than without (and this is pessimistic.) While the rest of a typical higher-radix FFT pass is dominated by adds, being able to do 2 of these per cycle (even without throwing in an extra multiply) should produce a significant speedup. I think we can gain a good idea of the potential performance from looking at the IBM Power3 processor, which similarly can do any combination of 2 FADD/FMUL/MADD per cycle - a couple of months ago Nick Geovanis compiled Mlucas (with no hardware-specific tweaks whatsoever) on such a machine and got 40-50% better per-cycle performance than on the Alpha 21264 (although the latter still beats the Power3 in terms of runtime due its much higher clock rate.) That translates to roughly 2.5-2.7 times the per-cycle performance of Prime95 on the PII, which ain't bad at all. again, the real question is how good the SGI compiler will be, but those folks have a great track record when it comes to optimizing compilers. Does anyone know when the first IA-64 systems will start shipping for the commercial market? Does anyone here know of a way of getting time on a beta system (an actual system, not a simulator) before then? Cheers, - -Ernst _________________________________________________________________ Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers ------------------------------ Date: Mon, 19 Jun 2000 18:33:29 -0400 From: Lawrence Murray <[EMAIL PROTECTED]> Subject: Re: Mersenne: LOST NUMBERS I find it amusing that you do think a 550mhz too slow. When I started the test in september I had just upgraded my duel processor 350mhz pentium II to a state of the art duel pentium 550mhz pentium III 9 months later it's classified as inadequate. I can't wait to see what will be considered slow 9 months from now. 1gig? I wish I had this slow 2 x 550 back in 1994 when those awesome new pentium 60's came out and blew away our 486's (by the way I may be off with Year). For some of us that have 5 or 6 older computers sucking down electricity in the name of science, it is a big thing to hook them up to dial in. Since there are plenty of 10 million digit numbers to test I and it is known that it will take close to a year to test them arrangements should be made to extend the time of re-assignments of numbers that large. I have been part of gimps for almost 3 years. But its attitudes like this that make me want to save the 20-30 a month in electricity and just shut them down....But I realize that every cpu cycle does advance the cause. I may be silly but I get excited when I look in and see that the sustained throughput is over 1100 gigaflops, and that there are close to 28,000 computers working on this project. In order to keep a state of the art computer working on this project one would need to buy a new computer every 3 months. Thanks L. Murray P.S. after having those 10 million digits 9 months on my individual page it now looks naked and lonely "Brian J. Beesley" wrote: > On 18 Jun 00, at 21:25, Larry Murray wrote: > > > I thought had occurred to me with this prize that is being offered. what > > happens if you work on a number for 6 months and then it is re-assigned to > > a person with a faster computer and their computer finishes the > > computation first and it is found to be a prime. Who is entitled to the > > Prize? Does that mean if you have A slower 550mhz computer don't bother > > testing a 10 million number? If you do make sure you always check in > > because it can be taken from you? On the same subject what-if you're the > > person the number is reassigned to and you work on a number for 6 > > months to find that it was a reassignment and it was found to be > > prime...I think with the longer testing time of the 10 million digit > > numbers the time between reassignment of those numbers should be much > > longer. I personally have been running 3 ten million digit numbers on > > Pentium 550's since September of 1999 and hardly > > ever even bother with the computers that are running them I have strictly > > devoted them to the mersenne project...ANYWAY ITS SOMETHING TO THINK > > ABOUT--TAKE CARE ALL > > You have to check in occasionally to keep the assignment. This is > entirely reasonable since some people are bound to "default" without > bothering to return the assignment. > > If it's too inconvenient to connect the actual systems to allow them > to check in, you can use the PrimeNet Manual Testing page to check > assignments in manually in order to prevent them from expiring. Since > you can "extend" an assignment for up to 120 days (plus the 60 day > grace period) you should only need to do this two or three times > during the run. > > If you run assignments which aren't given to you by PrimeNet, or > continue to work on assignments which have been reallocated due to > your failure to check them in occasionally, I don't think you should > be entitled to a share of any prize. However it looks as though, > according to the EFF rules (which I haven't looked at for a while), > the first discovery reported to EFF takes precedence. > > Since the expected return on testing numbers in the 10 million digit > range is of the order of 40 cents / PIII-550 year, I doubt too many > people are participating simply because of the existence of the prize > ... ? > > Also, note that it's entirely possible that the EFF prize will be won > by someone working on non-Mersenne numbers using entirely different > software and/or hardware. > > BTW for QA reasons I am already working on a double-check of a 10 > million digit number before the first test is completed. I will make > damn sure that the "official" owner of the assignment reports the > final result, abandons or allows the assignment to expire before I > report the result myself. (And the "official" owner knew this before > I started!) > > Personally, and bearing in mind that there are a lot of much smaller > exponents which still require testing, I consider a standard PC > running a PIII-550 to be inadequate for running 10 million digit > exponents. I'm using an Athlon 650, which is about 35% faster, and I > have a system (self-)built for reliability rather than down to a > price. However, GOOD LUCK to all those who do chance their arm! > > Regards > Brian Beesley _________________________________________________________________ Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers ------------------------------ Date: Mon, 19 Jun 2000 18:20:30 -0500 From: kilfoyle <[EMAIL PROTECTED]> Subject: Re: Mersenne: LOST NUMBERS When I started on factor and LL testing I had a 8008 5.47mhz upgraded IBMPC!! regards Michael Lawrence Murray wrote: > I find it amusing that you do think a 550mhz too slow. When I started the test > in september I had just upgraded my duel processor 350mhz pentium II to a state > of the art duel pentium 550mhz pentium III 9 months later it's classified as > inadequate. I can't wait to see what will be considered slow 9 months from now. > 1gig? I wish I had this slow 2 x 550 back in 1994 when those awesome new pentium > 60's came out and blew away our 486's (by the way I may be off with Year). For > some of us that have 5 or 6 older computers sucking down electricity in the name > of science, it is a big thing to hook them up to dial in. Since there are > plenty of 10 million digit numbers to test I and it is known that it will take > close to a year to test them arrangements should be made to extend the time of > re-assignments of numbers that large. I have been part of gimps for almost 3 > years. But its attitudes like this that make me want to save the 20-30 a month > in electricity and just shut them down....But I realize that every cpu cycle > does advance the cause. I may be silly but I get excited when I look in and see > that the sustained throughput is over 1100 gigaflops, and that there are close > to 28,000 computers working on this project. In order to keep a state of the art > computer working on this project one would need to buy a new computer every 3 > months. > Thanks L. Murray > > P.S. after having those 10 million digits 9 months on my individual page it now > looks naked and lonely > > "Brian J. Beesley" wrote: > > > On 18 Jun 00, at 21:25, Larry Murray wrote: > > > > > I thought had occurred to me with this prize that is being offered. what > > > happens if you work on a number for 6 months and then it is re-assigned to > > > a person with a faster computer and their computer finishes the > > > computation first and it is found to be a prime. Who is entitled to the > > > Prize? Does that mean if you have A slower 550mhz computer don't bother > > > testing a 10 million number? If you do make sure you always check in > > > because it can be taken from you? On the same subject what-if you're the > > > person the number is reassigned to and you work on a number for 6 > > > months to find that it was a reassignment and it was found to be > > > prime...I think with the longer testing time of the 10 million digit > > > numbers the time between reassignment of those numbers should be much > > > longer. I personally have been running 3 ten million digit numbers on > > > Pentium 550's since September of 1999 and hardly > > > ever even bother with the computers that are running them I have strictly > > > devoted them to the mersenne project...ANYWAY ITS SOMETHING TO THINK > > > ABOUT--TAKE CARE ALL > > > > You have to check in occasionally to keep the assignment. This is > > entirely reasonable since some people are bound to "default" without > > bothering to return the assignment. > > > > If it's too inconvenient to connect the actual systems to allow them > > to check in, you can use the PrimeNet Manual Testing page to check > > assignments in manually in order to prevent them from expiring. Since > > you can "extend" an assignment for up to 120 days (plus the 60 day > > grace period) you should only need to do this two or three times > > during the run. > > > > If you run assignments which aren't given to you by PrimeNet, or > > continue to work on assignments which have been reallocated due to > > your failure to check them in occasionally, I don't think you should > > be entitled to a share of any prize. However it looks as though, > > according to the EFF rules (which I haven't looked at for a while), > > the first discovery reported to EFF takes precedence. > > > > Since the expected return on testing numbers in the 10 million digit > > range is of the order of 40 cents / PIII-550 year, I doubt too many > > people are participating simply because of the existence of the prize > > ... ? > > > > Also, note that it's entirely possible that the EFF prize will be won > > by someone working on non-Mersenne numbers using entirely different > > software and/or hardware. > > > > BTW for QA reasons I am already working on a double-check of a 10 > > million digit number before the first test is completed. I will make > > damn sure that the "official" owner of the assignment reports the > > final result, abandons or allows the assignment to expire before I > > report the result myself. (And the "official" owner knew this before > > I started!) > > > > Personally, and bearing in mind that there are a lot of much smaller > > exponents which still require testing, I consider a standard PC > > running a PIII-550 to be inadequate for running 10 million digit > > exponents. I'm using an Athlon 650, which is about 35% faster, and I > > have a system (self-)built for reliability rather than down to a > > price. However, GOOD LUCK to all those who do chance their arm! > > > > Regards > > Brian Beesley > > _________________________________________________________________ > 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: Mon, 19 Jun 2000 19:17:27 -0700 From: Spike Jones <[EMAIL PROTECTED]> Subject: Mersenne: (no subject) at least in the near-term one could then simply compile one of the HLLLL (High-level-language Lucas-Lehmer; how's that for a tortured acronym? :) No, because if we did that, the whole project would go to HLLLL. spike _________________________________________________________________ Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers ------------------------------ Date: Mon, 19 Jun 2000 19:29:07 -0700 From: Bob Margulies <[EMAIL PROTECTED]> Subject: Mersenne: Trouble with new DSL connection, Part 2 My new DSL connection is a pleasure to use. I have two computers networked together. Prime95, version 20.6.1 is running under Windows 98 on the master computer (the one with the DSL connection). All was well until Prime95 needed to contact the server. Then I got the message Dial-up connection not active. Will try contacting server again in 2 minutes. When I reported this to [EMAIL PROTECTED], several people responded with the suggestion that I deselect the 'Use a dial-up connection to the Internet' box in the Test/Primenet menu. When I did this the message changed to Error 2250, which appears every 60 minutes. The standard advice on 2250 is to switch from RPC to HTTP protocol. I was already using HTTP protocol, so this doesn't apply. As an alternative it suggests I set up a proxy server. In order to do this, I need to create primenet.ini and supply it with the name of the proxy server domain and the proxy port number. I can obtain the server domain from a ping, but I have no idea about the port number. I am at a loss about how to proceed. Can anyone help? _________________________________________________________________ Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers ------------------------------ Date: Tue, 20 Jun 2000 06:49:43 -0000 From: "Brian J. Beesley" <[EMAIL PROTECTED]> Subject: Re: Mersenne: LOST NUMBERS On 19 Jun 00, at 18:33, Lawrence Murray wrote: > I find it amusing that you do think a 550mhz too slow. Too slow _for 10 million digit numbers_. PIII-550 is fine for "ordinary" LL tests & is faster than any of my systems except the Athlon 650. If nothing else was available, then there would be a valid excuse - but there are now a great many systems around which are significantly faster than a PIII-550. > But its attitudes like this that make me want to save the > 20-30 a month in electricity and just shut them down.... That's not what I meant at all! > But I realize that > every cpu cycle does advance the cause. Yes. But random errors can and do occur and the probability of one occurring in any given time interval is independent of the CPU speed. Therefore one wants to keep run times reasonable. If you get one glitch during one year & you're processing an exponent in the 33 million range, all your work is wasted. If you're processing exponents in the 10 million range instead, you will complete about 10 assignments and 9 of them will be OK. The same argument applies for any error rate except zero (unattainable) and >= 1 per CPU cycle (repair or replace the system!) To make the most effective use of _any_ system you need to choose its work carefully. I'm still running DC assignments on a P100 & will continue to do so as long as I can get assignments under 5.25 million (~6 weeks run time). Similarly I'll move my pair of PII-350s from LL testing to double checking when I can no longer get assignments under 10.32 million. > In order to keep a state of the art computer working on this > project one would need to buy a new computer every 3 months. Probably every 3 weeks rather than every 3 months ;-( I'm running a number of systems, few of which were anywhere close to "state of the art" even when new; I try to maximize useful cycles per dollar rather than raw speed. Personally I think it's absurd to pay 4 times as much for a 1GHz Athlon as you would for a 700 MHz Athlon, which has a lot more than 1/4 the performance. But I do consider it worth paying extra for reliability-related features like extra cooling fans, ECC memory and UPS to protect the system from inevitable irregularities in the mains (utility) power supply. Regards Brian Beesley _________________________________________________________________ Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers ------------------------------ Date: Tue, 20 Jun 2000 17:31:33 +0200 From: "Hoogendoorn, Sander" <[EMAIL PROTECTED]> Subject: RE: Mersenne: Trouble with new DSL connection, Part 2 >>All was well until Prime95 needed to contact the server. >>Then I got the message >>Dial-up connection not active. >>Will try contacting server again in 2 minutes. >>When I reported this to [EMAIL PROTECTED], several people responded with >>the suggestion that I deselect the 'Use a dial-up connection to the >>Internet' box in the Test/Primenet menu. When I did this the message >>changed to Error 2250, which appears every 60 minutes. >>I am at a loss about how to proceed. Can anyone help? You can leave the 'Use a dial-up connection to the Internet' selected and increase the time in Options/preferences/minutes between modem retries. You could also select 'do not contact primenet server automatically' in advanced/manual communication. You'll then have to make manual communication at least once every two months _________________________________________________________________ Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers ------------------------------ Date: Tue, 20 Jun 2000 14:41:43 -0500 From: "Griffith, Shaun" <[EMAIL PROTECTED]> Subject: re: Mersenne: New Lucas-Lehmer test program. This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. - ------_=_NextPart_001_01BFDAEF.90FBDF59 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Guillermo wrote: My aim when writing the code was that it could run I a the big = variety of systems. In fact, my test version (without priority management) = runs in a old 486 pc with Borland turbo c++ under MSdos 6-20, and also = runs on Alpha 21264 . With the -Dmacro compiler flags one can choose a lot = of features of the package to adjust it to the target system and made it = as fast as possible. =20 Has anyone given any thought to having code time itself with various "compile" options, radices (radixes?), algorithms, & tweaks, and choose = the fastest configuration for the machine it is running on?=20 I remember seeing a paper a few years ago about FFT self-tuning code = that does a few iterations on each combination, then chooses the best one to = do the real work. With LL test times of several weeks, and factoring passes of hours and = days, a few minutes at the start for each new exponent might be well spent. One drawback is the possibility of comparing apples to oranges, i.e., = one combination running with a different system loading than another. Another drawback is of course is to manage the added memory taken up "redundant" code. However, with the exponents running now the code size should be negligible compared to the data. =A0=20 Any comments? - -Shaun =A0=20 =A0=20 - ------_=_NextPart_001_01BFDAEF.90FBDF59 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN"> <HTML> <HEAD> <META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; = charset=3Diso-8859-1"> <META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version = 5.5.2650.12"> <TITLE>re: Mersenne: New Lucas-Lehmer test program.</TITLE> </HEAD> <BODY> <P><FONT SIZE=3D2>Guillermo wrote:</FONT> <BR><FONT SIZE=3D2> My aim when writing the code was that it = could run I a the big variety</FONT> <BR><FONT SIZE=3D2> of systems. In fact, my test version (without = priority management) runs</FONT> <BR><FONT SIZE=3D2> in a old 486 pc with Borland turbo c++ under = MSdos 6-20, and also runs</FONT> <BR><FONT SIZE=3D2> on Alpha 21264 . With the -Dmacro compiler = flags one can choose a lot of</FONT> <BR><FONT SIZE=3D2> features of the package to adjust it to the = target system and made it as</FONT> <BR><FONT SIZE=3D2> fast as possible. </FONT> </P> <P><FONT SIZE=3D2>Has anyone given any thought to having code time = itself with various "compile" options, radices (radixes?), = algorithms, & tweaks, and choose the fastest configuration for the = machine it is running on? </FONT></P> <P><FONT SIZE=3D2>I remember seeing a paper a few years ago about FFT = self-tuning code that does a few iterations on each combination, then = chooses the best one to do the real work.</FONT></P> <P><FONT SIZE=3D2>With LL test times of several weeks, and factoring = passes of hours and days, a few minutes at the start for each new = exponent might be well spent.</FONT></P> <P><FONT SIZE=3D2>One drawback is the possibility of comparing apples = to oranges, i.e., one combination running with a different system = loading than another.</FONT></P> <P><FONT SIZE=3D2>Another drawback is of course is to manage the added = memory taken up "redundant" code. However, with the exponents = running now the code size should be negligible compared to the = data.</FONT></P> <P><FONT SIZE=3D2>=A0 </FONT> <BR><FONT SIZE=3D2>Any comments?</FONT> </P> <P><FONT SIZE=3D2>-Shaun</FONT> <BR><FONT SIZE=3D2>=A0 </FONT> <BR><FONT SIZE=3D2>=A0 </FONT> </P> </BODY> </HTML> - ------_=_NextPart_001_01BFDAEF.90FBDF59-- _________________________________________________________________ Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers ------------------------------ Date: Tue, 20 Jun 2000 22:12:04 -0400 From: George Woltman <[EMAIL PROTECTED]> Subject: Re: Mersenne: LOST NUMBERS Hi all, At 05:37 AM 6/17/00 -0400, Larry Murray wrote: >I have been running 2 10million >numbers since september of last year 33220001 & 33219313 one is 49% done >and the other is 63% done. when I went to upload the latest results it >said that these numbers are not assigned to me I would like to know why >they were taken away from me. My duel pentium 600mhz processor computer >have been working on these numbers and nothing else for 9 months and I >am not willing to loose the credit for all that work my computers have >put into this. I hope Larry will finish these exponents off. As others have pointed out he will be the first to complete the test and the person who was later assigned the exponent will end up doing a double-check. I've asked Scott to change the server to not reassign these big exponents. With tens of thousands of 10 million digit Mersenne numbers using the same FFT size, we may as well assign new exponents and guarantee Larry's situation does not occur again. Regards, George _________________________________________________________________ Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers ------------------------------ Date: Wed, 21 Jun 2000 07:53:11 -0000 From: "Brian J. Beesley" <[EMAIL PROTECTED]> Subject: re: Mersenne: New Lucas-Lehmer test program. On 20 Jun 00, at 14:41, Griffith, Shaun wrote: > > One drawback is the possibility of comparing apples to oranges, i.e., one > combination running with a different system loading than another. If the self-tuning is being done on the same system that's running the bulk of the work (which I think is the idea), this shouldn't be a problem. A real, practical problem related to this is that varying system load may make a significant difference as to the relative efficiency of two methods, so you'd have to be careful about how you did the timing. e.g. on Intel processors, whether or not MMX is in use by another active process substantially affects the performance of anything which thrashes the FPU, because the MMX & FPU register sets are common & switching between MMX mode & FPU mode is relaitively slow. > Another drawback is of course is to manage the added memory taken up > "redundant" code. However, with the exponents running now the code size > should be negligible compared to the data. On IA32 systems, how the code is aligned is also a factor. To compare accurately, you'd really need the seperate code fragments to be in their own dedicated segments. This is not the way that un*x or Win32 applications are usually coded. Another problem suggests itself - this code would take a lot more debugging, for reasons which ought to be self-evident. Also, you'd need to label each result with the method used. Regards Brian Beesley _________________________________________________________________ Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers ------------------------------ Date: Wed, 21 Jun 2000 11:39:35 -0500 From: "Griffith, Shaun" <[EMAIL PROTECTED]> Subject: RE: Mersenne: New Lucas-Lehmer test program. This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. - ------_=_NextPart_001_01BFDB9F.48E13BDD Content-Type: text/plain; charset="iso-8859-1" Brian Beesley wrote: Griffith, Shaun wrote: > > One drawback is the possibility of comparing apples to oranges, i.e., one > combination running with a different system loading than another. A real, practical problem related to this is that varying system load may make a significant difference as to the relative efficiency of two methods, so you'd have to be careful about how you did the timing. e.g. on Intel processors, whether or not MMX is in use by another active process substantially affects the performance of anything which thrashes the FPU, because the MMX & FPU register sets are common & switching between MMX mode & FPU mode is relatively slow. If something like this happens in the normal course of computation, it matters little for programs such as Prime95 and others with low priority. Most of the work is done when nothing else is processing, and I would hope that MMX and similar interruptions are not running on my machine when I'm not there to enjoy it. If it happens during the tuning phase, that would pose a problem. Perhaps tuning should be programmed to run after some interval of uninterrupted CPU access (whatever that means). If a program tried to tune itself just after it loaded, there could still be a few processes around complicating things (like users with fidgety mice?) Or an occasional "refresh tune" at some user specified time might be useful. > Another drawback is of course is to manage the added memory taken up > "redundant" code. However, with the exponents running now the code size > should be negligible compared to the data. On IA32 systems, how the code is aligned is also a factor. To compare accurately, you'd really need the separate code fragments to be in their own dedicated segments. This is not the way that un*x or Win32 applications are usually coded. Not being up on the latest HLL compilers, I would still suspect that some compiler directives/options would be available to handle alignment properly without much headache, especially if it is as important as you suggest. And "usually coded" is perhaps superfluous here, as the programs we're discussing would be "unusually coded" because of the tuning approach itself. Point taken. Another problem suggests itself - this code would take a lot more debugging, for reasons which ought to be self-evident. Also, you'd need to label each result with the method used. Which may be the ultimate reason it remains undone. However, command line options could be used to force the code through each tuning configuration. The code could be proven to work correctly (to the same degree that current code is proven, by cross-checking sample input), though with significantly more effort, and perhaps with little added benefit. The configuration chosen by the tuning process could be documented to the user with another command line switch (printing out configuration and run times). Regards, Shaun - ------_=_NextPart_001_01BFDB9F.48E13BDD Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN"> <HTML> <HEAD> <META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; = charset=3Diso-8859-1"> <META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version = 5.5.2650.12"> <TITLE>RE: Mersenne: New Lucas-Lehmer test program.</TITLE> </HEAD> <BODY> <P><FONT SIZE=3D2>Brian Beesley wrote:</FONT> <BR><FONT SIZE=3D2> Griffith, Shaun wrote:</FONT> <BR><FONT SIZE=3D2>> </FONT> <BR><FONT SIZE=3D2>> One drawback is the possibility of comparing = apples to oranges, i.e., one</FONT> <BR><FONT SIZE=3D2>> combination running with a different system = loading than another.</FONT> </P> <P><FONT SIZE=3D2> A real, practical problem related to this is = that varying </FONT> <BR><FONT SIZE=3D2> system load may make a significant difference = as to the relative </FONT> <BR><FONT SIZE=3D2> efficiency of two methods, so you'd have to = be careful about how you </FONT> <BR><FONT SIZE=3D2> did the timing.</FONT> </P> <P><FONT SIZE=3D2> e.g. on Intel processors, whether or not MMX = is in use by another </FONT> <BR><FONT SIZE=3D2> active process substantially affects the = performance of anything </FONT> <BR><FONT SIZE=3D2> which thrashes the FPU, because the MMX & = FPU register sets are </FONT> <BR><FONT SIZE=3D2> common & switching between MMX mode & = FPU mode is relatively slow.</FONT> </P> <P><FONT SIZE=3D2>If something like this happens in the normal course = of computation, it matters little for programs such as Prime95 and = others with low priority. Most of the work is done when nothing else is = processing, and I would hope that MMX and similar interruptions are not = running on my machine when I'm not there to enjoy it. If it happens = during the tuning phase, that would pose a problem.</FONT></P> <P><FONT SIZE=3D2>Perhaps tuning should be programmed to run after some = interval of uninterrupted CPU access (whatever that means). If a = program tried to tune itself just after it loaded, there could still be = a few processes around complicating things (like users with fidgety = mice?) Or an occasional "refresh tune" at some user specified = time might be useful.</FONT></P> <P><FONT SIZE=3D2>> Another drawback is of course is to manage the = added memory taken up</FONT> <BR><FONT SIZE=3D2>> "redundant" code. However, with the = exponents running now the code size</FONT> <BR><FONT SIZE=3D2>> should be negligible compared to the = data.</FONT> </P> <P><FONT SIZE=3D2> On IA32 systems, how the code is aligned is = also a factor. To compare </FONT> <BR><FONT SIZE=3D2> accurately, you'd really need the separate = code fragments to be in </FONT> <BR><FONT SIZE=3D2> their own dedicated segments. This is not the = way that un*x or Win32 </FONT> <BR><FONT SIZE=3D2> applications are usually coded.</FONT> </P> <P><FONT SIZE=3D2>Not being up on the latest HLL compilers, I would = still suspect that some compiler directives/options would be available = to handle alignment properly without much headache, especially if it is = as important as you suggest. And "usually coded" is perhaps = superfluous here, as the programs we're discussing would be = "unusually coded" because of the tuning approach itself. = Point taken.</FONT></P> <P><FONT SIZE=3D2> Another problem suggests itself - this code = would take a lot more </FONT> <BR><FONT SIZE=3D2> debugging, for reasons which ought to be = self-evident. Also, you'd </FONT> <BR><FONT SIZE=3D2> need to label each result with the method = used.</FONT> </P> <P><FONT SIZE=3D2>Which may be the ultimate reason it remains undone. = However, command line options could be used to force the code through = each tuning configuration. The code could be proven to work correctly = (to the same degree that current code is proven, by cross-checking = sample input), though with significantly more effort, and perhaps with = little added benefit. The configuration chosen by the tuning process = could be documented to the user with another command line switch = (printing out configuration and run times).</FONT></P> <P><FONT SIZE=3D2>Regards,</FONT> <BR><FONT SIZE=3D2>Shaun</FONT> </P> </BODY> </HTML> - ------_=_NextPart_001_01BFDB9F.48E13BDD-- _________________________________________________________________ Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers ------------------------------ Date: Fri, 23 Jun 2000 11:28:13 +0100 From: gordon spence <[EMAIL PROTECTED]> Subject: Mersenne: P-1 Testing Hi, I was running a double check (assigned by Entropia) and found a factor, this is the second time that this has happened. I was just wondering about a few things 1. How often does this happen? 2. Does the original tester still "lose" the LL-credit they originally received. If they do then this doesn't seem fair to me, after all when they did the LL-test we didn't have the capability to find that factor. 3. Is it worth going back and performing a P-1 test on all Mersenne candidates with no known factor 4. Or is it better just to factor them deeper towards 2^72 Just out of interest I ran P-1 testing on another couple of numbers but no factor turned up. It only took about 3 hours for each test though... [Thu Jun 22 15:19:41 2000] UID: nitro/liberator, M3200543 completed P-1, B1=40000, B2=600000, WW1: 52E3BFCC [Thu Jun 22 19:00:18 2000] UID: nitro/liberator, M4056419 completed P-1, B1=45000, B2=652500, WW1: 691E386D regards G _________________________________________________________________ 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 #750 ******************************
