[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
