Mersenne: free f90/C/ for Alpha
Dear all: For those of you wanting to try Mlucas 2.7x (or any other Fortran code) on Alpha under Linux, Compaq is offering free betas of their f90 compiler for Linux. The same site lists free betas of the Compaq Linux C compiler, the Compaq Portable Math Library, and says there will soon be a beta of a C++ compiler for Linux: www.unix.digital.com/linux/software.htm I don't run Linux on either of my Alphas yet (If anyone has advice on relatively painfree and hopefully $-free ways of installing Linux on an Alpha, without blowing away an existing Unix configuration - I'm all ears), but the Linux executable of Mlucas v2.6 my SPEC98 contact at Compaq provided me earlier this year (compiled using the aforementioned compiler) was as fast as the f90-for-Unix- compiled one. -Ernst _ Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
Mersenne: Error message in Ver.18
Hi, Still a bit green on all this ... I have seen an error message I am not familiar with (i.e. not illegal sum-out) But: SUM(INPUTS) ! = SUM (OUTPUTS), 669721378183728.3 = 1.130101692988369e +300 possible hardware failure...etc.I see no refernce to this in the Readme file (as opposed to illegal sumout above) Any enlightenment on this would be most appreciated!!?? All The Best, Ian McLoughlin, Chematek U.K. Tel/Fax : +44(0)1904 679906 Mobile : +44(0)7801 823421 Website: www.chematekuk.co.uk _ Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
Mersenne: File missing?
I am running Prime95 Version 18.1.1, dated 04-01-99. When I press Esc, in order to suspend execution, I get a message stating that Prime95 is unable to find a file called Prime95.hlp. This file is not in the Prime95.zip which I downloaded. What is wrong? _ Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
Mersenne: Re: Mlucas 2.7 for x86?
On Sun, 26 Sep 1999 [EMAIL PROTECTED] wrote: > I'm not too surprised at this. Since my code appears to be faster than > FFTW on most high-end CPUs, that tells me that FFTW is probably optimized > more for the x86 (very few FP registers) than mine, which is geared toward > hardware with at least 32 FPR's. Normally this means that one uses smaller > complex FFT radices (say, 4 or 8) on machines with 8-16 FPR's, but Jason > Papadopoulos tells me that FFTW uses radices as high as 32. Perhaps they > use conditional compilation to decide what radices to use depending on the > underlying hardware, and use smaller radices on x86. (Any insights, Jason?) > > If they do use radices >= 8 on x86, they are probably arranging the code > to minimize register pressure - this could be worth looking at. FFTW uses a recursive FFT, and includes code that performs a single radix-n pass for lots of n (all powers of two up to 64, and other small radices like 3,5,7,9,10,...). You tell it to build you an FFT of a certain size, and it picks the combination of radices that solve your problem in minimum time (it uses dynamic programming, finding the fastest combination for small sizes and then using them as building blocks for larger sizes). The combination is encoded in a "plan", and the FFTW executor reads this when you want to do the FFT for real. On x86, for medium-size transforms FFTW likes radix-8 a lot. It overflows the pathetic FPU stack quickly but it also cuts the problem size very quickly, and so turns out to be a net win over smaller radices. jasonp _ Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
Mersenne: Re: Mlucas 2.7 for x86?
[EMAIL PROTECTED] (Guillermo Ballester Valor) writes: >The first timing is no good as I expected. These are the result: > >F90 compiler : Microsoft Fortran Power station 4.0 > Optimizations: all optimizations enabled. > > mprime lfftw Mlucas > (sec/iter) >Exponent test M(3975659)0.359 0.901 1.604 I'm not too surprised at this. Since my code appears to be faster than FFTW on most high-end CPUs, that tells me that FFTW is probably optimized more for the x86 (very few FP registers) than mine, which is geared toward hardware with at least 32 FPR's. Normally this means that one uses smaller complex FFT radices (say, 4 or 8) on machines with 8-16 FPR's, but Jason Papadopoulos tells me that FFTW uses radices as high as 32. Perhaps they use conditional compilation to decide what radices to use depending on the underlying hardware, and use smaller radices on x86. (Any insights, Jason?) If they do use radices >= 8 on x86, they are probably arranging the code to minimize register pressure - this could be worth looking at. >THE CLOCK TIMINGS WRITTEN BY MLUCAS ARE INCORRECT!. I had to timing with >my hand-clock. It writes a lot more time than real. Note that Mlucas uses elapsed time rather than CPU time, so if other stuff is running, the printed time would be larger than CPU. But if your own elapsed-time measure disagrees, that implies there is a bug with the f90 date_and_time intrinsic in the MS compiler - try to code a super-simple program (hacked from mine, if you like - look in the source to see how the character function char_time gets used in conjunction with the above intrinsic. If you can reproduce the wrong-timing effect, send e-mail and your sample code to MS compiler support. I've had no problems with the time stuff on various Unix systems. >If the rest of the lfftw code have a similar performance, you perhaps >will reach a RPI>100%. Oh, I already do, just not on every platform - but I'm working on it. :) >I can sent you the executable Mlucas and my tested, no buggy, c-code. >lfftw.c. Sure, go ahead and send them, preferably Win-or-PK-zipped. You should make at least the C code ftp'able as well, that way others can check it out. If it's close to MacLucasUNIX on some systems, we would at least have a generic C code which allows non-power-of-2 runlengths (MLU doesn't). >Well, sorry to mail you on Sunday. I don't mind - I only check my e-mail if I have time (and on weekends, the inclination) to do so. Best regards, Ernst _ Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
Re: Mersenne: Factors Everywhere
Will Edgington writes: [Yes, I'm following up to my own message.:)] n p,pk1 ,pk2 ,pk3 Note that M(n) has no known factors. Trying this out just now, the 111 MB of data that I have for prime exponent Mersennes in the mersfmt reduces to a bit under 20 MB if this format is used for only the prime exponents with known factors. Gzip (using max compression) gets that down to 7.1 MB. Producing & gzip'ing it from the mersfmt of the data takes only a couple of minutes on my machine, so adding it to the automatic update won't slow things down enough to notice. A quick line count of ungzip'd file (about 2 seconds, from cache:) produces a count of 1,677,377 known factors of prime exponent Mersenne numbers (that aren't completely factored). Will _ Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
Re: Mersenne: Factors Everywhere
At 11:46 AM 1999/09/26 +0100, you wrote: >6) PrimeNet trial factoring has moved well into the 10 millions, >however George's factor.zip file contains data only up to 10 million. >I know there is a problem with uploading the large files concerned; >hopefully, the suggestions above will help to reduce the size of the >file, sufficiently to make it feasible to expand the exponent range >to cover (at least) the active Primenet assignments for long enough >for cheap, high-speed Internet connectivity to become widespread. > >7) I have several hundred megabytes of disk space available on my ftp >server, which has reasonable Internet access - at least 8 Mbps >connectivity to the Internet core - and would be happy to provide >means for anyone interested to upload factoring data (or anything >else, strictly relevant to Mersenne or closely-related numbers) for >the purpose of making it publicly available. I encourage you to implement this central repository. Something that would have accelerated parts of the QA process is the ability to query such an online resource for information such as the following: What is the smallest exponent larger than n that has no factor found when factored to 2^m (possibly but not necessarily gimps default depth)? What is the largest exponent smaller than n that has no factor found when factored to 2^m? What are the exponents with double checked residues between a and b? What are the exponents with double checked residues between a and b whose residues are from separate chip architectures and software (Eg, Intel & prime95 for one, Alpha & MacLucasUnix for the other)? What are the exponents with singly checked residues between a and b? (I suppose one could consider doing very short factoring tests to fill gaps when queries ask for an exponent's factor status; something like up to 2^40, and add it to the database at that time; not a requirement.) Something that might aid development of new prime search software would be: What are all the known factors larger than 2^m? What are all the known factors between 2^m and 2^n for exponents between a and b? It is not the raw data, so much as the query response, that needs human-readability. Ken _ Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
Mersenne Digest V1 #633
Mersenne Digest Sunday, September 26 1999 Volume 01 : Number 633 -- Date: Sat, 25 Sep 1999 10:11:02 +0100 From: "Brian J. Beesley" <[EMAIL PROTECTED]> Subject: Re: Mersenne: Re: and, from WAY out in left field... On 25 Sep 99, at 1:23, [EMAIL PROTECTED] wrote: > As with all distributed efforts, we all contribute what we can. It's not > a contest, except perhaps amongst us programmers, in terms of pushing each > other to continually improve our codes. There are other ways of contributing as well as simply contributing CPU cycles - valuable though that contribution is! > >Sorry, I am bitter and can't afford a 550 Pentium. > > Hopefully soon - here prices have dropped below 1000 $US for 500MHz systems- > you can get a 300-400MHz PII virtually for free if you're willing to pay > $20/month for 36 months of unlimited Internet access. You should try buying > online, e.g. at www.valueamerica.com or some such store. UK "shop window" retail prices _look_ awful - but they insist on selling you a huge monitor, "high-end" multimedia hardware (possibly including an awful scanner and a worse digital camera), a 56K modem (built-in WinModem, useless unless you're running Windoze) and a huge raft of "free" software (mostly obsolete and/or rubbish they can't offload any other way, except as landfill) as well as the bits you actually need. You can buy basic systems at quite reasonable prices here, if you look in the right place e.g. £440 (ex VAT) for a complete PII-400 system. PIII-500 systems are a couple of hundred pounds more expensive, but that's Intel pricing policy. In terms of "bangs per buck", the systems with the fastest processors are relatively poor value for money (especially as the performance of "real" programs is not linearly related to the CPU clock speed!) There is an _enormous_ improvement in speed between a Cyrix 333 and a PII-400, _much_ less between a PII-400 and a PIII-600 (or whatever the fastest chip Intel do at the moment is - I find it hard even to keep track of where the "bleeding edge" is, so fast is the turnover of products!) Bear in mind the transport costs, the complications with customs duty & the possible risks involved in dealing in foreign exchange (you don't know the exchange rate until the credit card company processes the transaction - & they can, and do, manipulate this to your disadvantage) I'm not sure that there's any real benefit in dealing direct with US suppliers for single unit purchases. Bulk purchasing may be an entirely different matter. Here in the UK, component prices seem to be reasonably competitive, especially when purchased through the many outlets which include free delivery. This is a major saving on a small order. > >How do I know that the exponent I am testing has not already run to > >conclusion.? If someone else has run your exponent to completion (unlikely) you will find out when you check in your completion dates. The PrimeNet server will mutter at you. Regards Brian Beesley _ Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers -- Date: Sat, 25 Sep 1999 16:25:43 +0300 From: Jukka Santala <[EMAIL PROTECTED]> Subject: Re: Mersenne: Front-end design Pierre Abbat wrote: > I suggest a couple of named pipes for control (the front end writes to one and > reads from the other, and mprime vice versa). Since writing to a pipe whose > reader is stuck can get you blocked when the pipe is full, and writing to a > pipe with nothing at the other end results in a SIGPIPE, mprime should not > output anything to the pipe unless told to do so, and should trap SIGPIPE and > turn off output. The current .ini structure is, I feel, sufficient for controlling the operation of the client, and preferrable. However, some signal should exist to force the client to re-read these settings after change; at least in *nixes this should be easy (Just handle HUP). As for data out of the client, I like to think that the existing save-state files would be enough, or could be made to be enough. I'm not sure how much cycles generating them frequently will burn, though, which could be a problem. Also the timing data is not easily accessible this way, but I like the approach used in the recently posted *nix GUI. And I concur with the ideas that the "extended GUI" should, if possible, be separate from the main client so as not to run a risk of messing up the results. -Donwulff _ Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers -- Date: Sat, 25 Sep 1999 09:36:01 -0400 (EDT) From: Jason Stratos Papadopoulos <[EMAIL PROTECTED]> Sub
Re: Mersenne: Front-end design
What would make sense to me is to have a single (X-based?) frontend that is able to monitor/control the action of multiple Prime95-style "services". Today, I look at my personal Primenet report to see if any of my machines are "misbehaving" - but finding a turned-off computer using this takes days. A screen with a few nice colors per machine would be *so* much nicer .-) How I would implement it: Have two processes: - 1 like the "proxy", except different: all the mprime programs send it a packet every time they start up (and occasionally when running). Location configurable (can't see how to make it auto-conf, except perhaps if the primenet server would store its location in my account info and tell the clients when they call in for an exponent or update). Always runs. - 1 display program, that either interrogates the "proxy" or the running testers directly through an RPC mechanism. Much fun. Lots of code to break. Harald A -- Harald Tveit Alvestrand, Maxware, Norway [EMAIL PROTECTED] _ Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
Re: Mersenne: Factors Everywhere
Brian J. Beesley writes: 1) I don't see any particular need to make available files in human- readable format, provided that we provide a specification for the file, and also binary executables for common platforms for converting a machine-readable file to human-readbale format. I, personally, have no way of producing executables except for Intel CPUs, and presently only for Linux (I just yesterday got a old P100 machine up running Win98 (and Prime95, of course:)). I have thought about a binary data format off and on for a while now, but mostly in terms of making updates easier by designing a format that can be updated in place (at least most of the time), which is a different problem. On the other hand, it could be that "zipping" a human-readable format file provides near-optimal compression. Most likely, and this avoids having to provide executables to read it: they're already out there. 2) Since factors are of the form 2kp+1, it is only neccessary to list p & k. This saves a significant amount of storage (compared with listing p and 2kp+1) and the proper factor is easily recovered. Unfortunately, it's only this simple when p is odd. For even p, factors can be one more than any multiple of p, not just one more than even multiples of p. And I'd really rather not have a different format for even exponents ... 3) If the data was held in variable-length records in a format similar to p,n,k1,k2,k3... where n is the number of known factors and k1, k2, k3,... are the multipliers for each of the known factors in turn, this would save much duplication compared with the current format (of factor.txt). This is also a good idea, but a few of the lines would be _very_ long, which some text editors and other programs will have problems with. I'd also suggest dropping n; including it doesn't really add anything and it can be computed quickly from the other data. Perhaps something like: n p,pk1 ,pk2 ,pk3 Note that M(n) has no known factors. 4) For values of p which fit into a (integer) CPU register and "small" values of k (up to approx. 64K), trial factoring is so fast that I doubt it would be any faster to search a file than to repeat the calculation - even if the file is already available locally. Yes, but then there's no way to be sure whether the factor is already known or not. There was a bug in an early post-GIMPS-start factorer of mine that caused it to miss _exactly_ one factor, of M(47). If I hadn't had an explicit list of factors to compare with, I would have never found the bug. Perhaps the file should contain a "flag" denoting that factors are known, but have been omitted for this reason. This might be enough, though. But note that this can already be done using the DATABASE format, if you're willing to omit all factors. Hm; so perhaps a DATABASE file with all the exponents and trial factoring extents and a second, human readable, file, as above, is a possibility. And I've long thought about a small program (& function) to do fast, binary lookups in large Mersenne data files like these (human readable or binary), akin to the common UNIX "look" program for dictionary files, but, of course, doing a numeric search rather than a dictionary search. We should still have a large master file somewhere, but this need not be uploaded frequently. I update my local copy about twice a week usually; it takes only a couple hours on my new PIII/450MHz machine and was well under a day even on my old P233MMX system. These times include automatically downloading data out there every few days to a month, as appropriate for the particular file. 5) Following on from (4), it seems to make sense to record the highest value of k tested by trial factoring, rather than the maximum number of bits. This is lacking in the DATABASE format, but my format implies this info. And, for a year or more, I've actually been treating the "distance" in k's to get to the next power of two as a "gap" in the trial factoring data and thus most of it is just above powers of two. Note also that exponents with known factors can be worked on by Prime95 again, after mersfacgmp or some other factorer pushes the extent past the next power of two above a factor. 6) PrimeNet trial factoring has moved well into the 10 millions, however George's factor.zip file contains data only up to 10 million. Yup. This also means that my factors and his for exponents above 10 million have not been compared for some time. I know there is a problem with uploading the large files concerned; hopefully, the suggestions above will help to reduce the size of the file, sufficiently to make it feasible to expand the exponent range to cover (at least) the active Primenet assignments for long enough for cheap, high-speed Internet connectivity to become widespread. Or perhaps George should simply shift to the factors of the exponent
Re: Mersenne: Graphical visualisation of computations
At 01:42 AM 9/26/1999 -0400, Lucas Wiman wrote: >> not, but, what would it show? A progress bar, maybe... anything else? There >> isn't really anything else to show. Intermediate results of the LL test >> don't themselves have a lot of meaning (even the final result, if non-zero, >> is devoid of much interpretation). There's not a lot you could plot - a >> graph of the iteration time would only serve to show when you opened >> Microsoft Word or something... > >Yes, but the point is that they may be pretty. (?) This probably wouldn't >alter anyone who already is at GIMPS, but it might attract new members. >This feature (based on George's postings about his interests in the project) >would be badly maintaned, and a support headache. I think it should be emphasized, though, that that pretty-looking SETI interface is a pig. On Win* machines, it often more than doubles the time required to complete a block of data. All of the people I know who run SETI went "Ooooh, ah!" when they saw the GUI, then promptly turned it off because it hogged so many cycles. The REAL attraction of the SETI project is the chance to be the person who helps to discover the existence of E.T. Face it, that captures the public's imagination much more, generally, than does hunting for large prime numbers. I believe the initial attraction to SETI is not the interface, but rather the chance to discover E.T. Just my $.02, Kel _ Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
Re: Mersenne: Factors Everywhere
Hi everyone, A few points about publishing known factors. 1) I don't see any particular need to make available files in human- readable format, provided that we provide a specification for the file, and also binary executables for common platforms for converting a machine-readable file to human-readbale format. On the other hand, it could be that "zipping" a human-readable format file provides near- optimal compression. 2) Since factors are of the form 2kp+1, it is only neccessary to list p & k. This saves a significant amount of storage (compared with listing p and 2kp+1) and the proper factor is easily recovered. 3) If the data was held in variable-length records in a format similar to p,n,k1,k2,k3... where n is the number of known factors and k1, k2, k3,... are the multipliers for each of the known factors in turn, this would save much duplication compared with the current format (of factor.txt). 4) For values of p which fit into a (integer) CPU register and "small" values of k (up to approx. 64K), trial factoring is so fast that I doubt it would be any faster to search a file than to repeat the calculation - even if the file is already available locally. Therefore I suggest that, in order to reduce substantially the size of the frequently-updated publicly-available known factors file, "small" values of k are omitted, and a program be provided instead to generate the data (with binary executables for common platforms). Perhaps the file should contain a "flag" denoting that factors are known, but have been omitted for this reason. We should still have a large master file somewhere, but this need not be uploaded frequently. 5) Following on from (4), it seems to make sense to record the highest value of k tested by trial factoring, rather than the maximum number of bits. 6) PrimeNet trial factoring has moved well into the 10 millions, however George's factor.zip file contains data only up to 10 million. I know there is a problem with uploading the large files concerned; hopefully, the suggestions above will help to reduce the size of the file, sufficiently to make it feasible to expand the exponent range to cover (at least) the active Primenet assignments for long enough for cheap, high-speed Internet connectivity to become widespread. 7) I have several hundred megabytes of disk space available on my ftp server, which has reasonable Internet access - at least 8 Mbps connectivity to the Internet core - and would be happy to provide means for anyone interested to upload factoring data (or anything else, strictly relevant to Mersenne or closely-related numbers) for the purpose of making it publicly available. Regards Brian Beesley _ Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
Re: Mersenne: Graphical visualisation of computations
Hi, I think you should be very careful about how much graphical information is to be represented. I have just joined GIMPS recently after using SETI@home. That program has a nice graphical interface, but many people, my self included, spent much time and effort to either disable the display, or use a text only version and various tweaking to speed the machine up. The reason for this is that it takes a great many CPU cycles to perform the display, cycles that would be better spent doing the testing. In the case of SETI@home a speed increase of around 300% was obtained by not having the display!! Don't get me wrong I would like to see some more information about what is going on, but not at the expense of loosing time. Regards, >Jukka Santala <[EMAIL PROTECTED]> wrote on Friday 24 September 1999 at 5:25 >PM: > >> Though you ask this, I find the topic rather appropriate for the list, >> especially given the angle of "HOW can we visualize the process of >> mathemathical operations. > >That brings me to the following observation: >I think few of us fully realize the _enormous_ amount of (highly >optimized) processing required each iteration to achieve something that >looks so simple: a squaring, minus 2, mod (2^p-1). >Remember, you see nothing happening! Prime just tells you: I used >so-and-so-many BILLION clock cycles on the previous iteration. When a >computer is ray-tracing (preferrably on some fancy high-end workstation) >you are immediately dazzled by the picture-perfect pixels appearing on the >screen in brilliant colours. >But your result is not for eternity. In GIMPS it is. M7xx tested. >Composite. Or: M10yy trial-factored to 2^65. No factors below 2^65. >And you know that YOU discovered that mathematical fact. >That little 64bit residue or checksum is precious. If you had a grain of >rice for the number of clock cycles needed to produce just one of those >bits, you could feed the entire (current) world population for a whole >year! Is that about right? >Whatever the correct figure, the program doesn't show you what it's doing. >Actually, it might be interesting to be able to see, say, just the last >64 bits (in hex) of the current number L[n] in the Lucas sequence. The >program displays those bits for L[p-1], right? So why not during the >sequence? >The program should IMHO at least -optionally- display a progress bar >showing graphically what it now only shows in digits: >progress on current exponent [95.2% completed]. The bar would probably >grow one pixel longer every couple of hours. >Any comments on the issue of graphical visualisation? > >Cheers, >Robert van der Peijl > >_ >Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm >Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers Mike, -- ATLAS CELESTE - Bevis Star Atlas - & "The CD-ROM" A very rare atlas found at the Godlee Observatory http://www.u-net.com/ph/mas/bevis/ Astronomy in the UKhttp://www.ph.u-net.com _ Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
