Mersenne Digest Tuesday, August 31 1999 Volume 01 : Number 620 ---------------------------------------------------------------------- Date: Sun, 29 Aug 1999 10:15:09 +1000 From: Simon Burge <[EMAIL PROTECTED]> Subject: Mersenne: Re: How about some C code? [EMAIL PROTECTED] wrote: > Ok, I've cleaned up the Mlucas 2.6 source code and I think we're > ready to take a crack at a C version. The revised source (which > also includes a fix for a bug which David Willmore brought to > my attention - don't worry, it can only cause the code to quit > unexpectedly when it starts a new exponent as part of a multi-exponent > range test - any actual test results should be fine) is at > > ftp://209.133.33.182/pub/mayer/Mlucas_2.6c.f90.gz > > [[ ... ]] > > With v2.5, Gord Palameta was > able (using an automated translator and subsequent manual work) to > get a decent C version in a remarkably short time; Brian Beuning > also created one, but we never did any head-to-head comparisons of > the two resulting codes. I'd be interested to know what sort of translator was used - all the fortran to C translators I could find were f77 and not f90... Over the last week or so, I've done a hand-translation of 2.6a (using some fancy vi macros to do most of the work), but at the moment bit_reverse_int isn't working for some reason. I know you said it may not be worth it a week or so ago, but I was bored :-) One idea I had was to use GNU's gmp library to initialise the sine/cosine tables on machines that didn't have 16 bytes reals. Gord used a pre-generated file but I like the idea of a stand-alone program that doesn't rely on any extra files. > This time, I'd like to keep some coherency to any such effort, so once > I see who offers to help, we can discuss how distribute the labor. Of course > anyone is free to go it alone, but I will ask Conrad Curry, who maintains > the GIMPS "other available source code" page to only post a link to a C > version if it gets my stamp of approval. > > Potential benefits of an Mlucas.c: > > 1) Will run on any Unix platform; no special compiler should be needed > (though we need to find the best C compiler for each platform); > > 2) Will make it easier to interface with the eventual PrimeNet for Unix; > > 3) Will make it easier to interface with Peter Montgomery's Mfactor code; > > 4) Will allow us to try neat tricks like inlining cache-bypassing stores > (if the architecture supports such an operation) which might really > help speed the code on systems with small caches. > > With that said, are there any volunteers? I'll of course be around to help > explain what-this-and-that in the F90 code means, but will be putting most > of my near-term effort into a P-1 factorer geared for large exponents. Count me in! Simon. _________________________________________________________________ Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers ------------------------------ Date: Sun, 29 Aug 1999 00:03:19 -0400 From: Gord Palameta <[EMAIL PROTECTED]> Subject: Mersenne: Re: How about some C code? [EMAIL PROTECTED] wrote: > > Ok, I've cleaned up the Mlucas 2.6 source code and I think we're > ready to take a crack at a C version. The revised source (which [...] > With v2.5, Gord Palameta was > able (using an automated translator and subsequent manual work) to > get a decent C version in a remarkably short time; Brian Beuning Well, actually the automated translator (based on f2c) produced code that was too messy to clean up, so I ended up doing the whole thing manually. Not particularly difficult, just a bit tedious transposing subscripts and making them 0-based. I can probably do the same for 2.6 within a week or so, time permitting. That would produce a version that compiles and executes the same as the Fortran original, but presumably more slowly because of aliasing in C preventing some compiler optimizations that Fortran can do. Once there's working C code, I can hand it off to the other folks on the list for optimizing or writing the interfaces that Ernst described... which will probably be the bulk of the work :-) Gord _________________________________________________________________ Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers ------------------------------ Date: Sun, 29 Aug 1999 04:06:02 EDT From: [EMAIL PROTECTED] Subject: Mersenne: Alpha time bug? Something strange is occurring with time-related utilities on my Alpha 21164. In doing my timings of Mlucas 2.6c, my trial indicated (among other things) a per-iteration time of 0.48 sec/iteration at FFT length 384K. After finishing my 100-iteration timing tests, I started a test of a Mersenne number in the 7M range. The 2000-iteration timings in the status file match the .48 second estimate. But, 24 hours (both according to the Unix ps command and on my wall clock) later, the code had completed 240000 iterations, corresponding to just 0.36 sec/iteration. While this is welcome, I'm baffled - whatever the problem is, it's affecting both the time utility and the time the program gets from the system CPU counter, but it's not affecting the actual displayed system time or things like the ps utility. The fact that the actual elapsed time is exactly 3/4 the time reported by the code (and the time utility) seems to indicate that there's some kind of 400/533 MHz clock rate mismatch going on. System details: It's a 400MHz 21164A (i.e. ev56) running Unix V4.0D. Has anyone else run into such a problem? Can someone else running the code on a 21164 see if there's a mismatch between the timings reported in the status file and the actual per-hour or per-day iterations performed? Puzzled (but not unhappy), - -Ernst _________________________________________________________________ Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers ------------------------------ Date: Sun, 29 Aug 1999 10:22:37 +0200 From: Harald Tveit Alvestrand <[EMAIL PROTECTED]> Subject: Mersenne: 512 bit RSA challenge factored See http://www.cwi.nl/~kik/persb-UK.html About 35 CPU-years, spread across 300 machines. Plus a Cray for the finishing touches. 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 ------------------------------ Date: Sun, 29 Aug 1999 15:19:40 EDT From: [EMAIL PROTECTED] Subject: Mersenne: Disregard (Was: Alpha timing bug?)t Please disregard what I said about weird timings on my Alpha - turns out that the run in question had a restart around iteration 60000, i.e. had done 180000 (not 240000) in 24 hours, precisely what I expected based on my 100-iteration code timings. I've gotta stop those wee-hours postings, or at least wait 'til morning to send them... Looks like if I want another 25% speedup from my code, I'll have to get it the old-fashioned way. - -Ernst _________________________________________________________________ Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers ------------------------------ Date: Tue, 31 Aug 1999 19:06:51 -0400 From: George Woltman <[EMAIL PROTECTED]> Subject: Mersenne: New status page Hi all, I uploaded a new status page to http://www.mersenne.org/status.htm The page now reflects version 19 timings and the status of exponents up to 79.3 million. If you were worried that GIMPS might one day run out of work to do, you'll notice there is now 48 million CPU years of work ahead of us :) Factoring will reduce this effort by about half, but double-checking is not included in that 48 million estimate. Also note that the stats at http://www.mersenne.org/top.htm now use the v19 timings as well. Thus, you will notice your P-90 CPU years has dropped. Since my P-90 no longer exists, my PII-400 has become the benchmark machine. If you average the v18 timings in the most popular FFT lengths, you'll find that my PII-400 equals 5.5 P-90s. The PrimeNet stats page is unaffected. It totals your CPU time as you contribute it using a different formula for each version of prime95. I expect a beta release of prime95 v19 to this mailing list later this week. General release will be a few weeks later. Best regards, George _________________________________________________________________ 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 #620 ******************************
