From: Lucas Wiman <[EMAIL PROTECTED]> writes (in response to someone else)
> > The last time I did timings like this - admittedly, probably over a
> > year ago, but the mers package hasn't changed much since, especially
> > in terms of performance - this is wrong. SPARC LL testing -
> > especially with MacLucasUNIX - is much closer to matching Prime95 LL
> > testing than SPARC trial factoring - with mersfacgmp, say - is to
> > matching Prime95's trial factoring, by, as I recall, a factor of about
> > 12.
>
> Though I don't have specific timings, I imagine this would be the case.
> I was referring to the Mfactor program by Peter Montgomery. I have heard
> this performs considerably better than a GMP based program (written by
> Alex Kruppa) on RISC architectures. I suppose that I could/should check
> up on this with my SPARC-owning friend.
>
> > The UltraSPARC would probably significantly outperform a similar
> > megahertz PC, if we had similarly optimized code running on each.
> > Perhaps.
>
> Again, I have no timings for this, but I would think that if you tried
> MacLucasUNIX on both a SPARC, and a PC, the SPARC would be the overall
> winner because of the massive amount of I/O that runs on LL tests. In
> factoring, I would imagine that the difference would be smaller, (using
> the same program).
UltraSPARC is a 64-bit architecture. The ARITHMETIC_INT64 option of
Mfactor.c is intended for 64-bit architectures, but requires both halves
of a 64 x 64 -> 128-bit integer product, preferably unsigned.
Alpha and MIPS (and soon-to-be Merced) provide both halves, but
UltraSPARC provides only the lower half, I believe.
You can use the ARITHMETIC_INT32 option on SPARCs, but this restricts
your search to primes below 2^60 rather than 2^63.
Peter Montgomery
_________________________________________________________________
Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm
Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
