Bill Rea writes:
>At 256K FFT I was seeing 0.11 secs/iter with
>Mlucas against 0.15 secs/iter for MLU, at 512K FFT the figures were
>0.25 secs/iter and 0.29 secs/iter respectively.
...and don't forget the added benefits due to Mlucas being able to
test significantly larger exponents at the same FFT length, as well
as having intermediate runlengths between powers of two. 0.11 seconds
at 256K is impressive - that's faster than on my 400MHz Alpha 21164
(0.16 sec) and Prime95 on a 400MHz PII (0.13sec), though, to be fair,
both of the latter systems have a smaller (512KB) L2 cache.
>Mlucas runs significantly faster if you can compile and run it
>on a 64-bit Solaris 7 system.
This is the first I've heard of this - roughly how much of a speedup
do you see?
>I would like to upgrade the E450 to Solaris 7 and see what Mayer's
>code can do in 64-bit mode, but the owners won't let me :-(
Luddites. :)
Brian Beesley writes:
>Bear in mind that Mlucas is still a bit "experimental". One problem
>has come to light - if you're using the PrimeNet Manual Testing page
>to submit results, you _must_ remove the space preceding the M at the
>beginning of the result line, else PrimeNet won't accept the result.
>Actually it says it has got the result but doesn't remove the
>assignment from the current assignments report or add it to the
>completed assignments report unless the leading space is removed.
>(This seems to be a program bug, I see the extra space in the source
>code so I'd assume the problem afflicts Mlucas 2.7y on all platforms.
>Certainly the binary executable I built for Alpha systems running
>linux is also afflicted.)
Actually, I had good reason to insert the leading space - many Fortran
compilers (especially older ones) interpret the leading character of a
literal output string as a linefeed character (a holdover from the days
of line printers) and will print gibberish if it's nonblank. I quote
from Metcalf & Reid, "Fortran 90/95 Explained," p.212:
"Fortran's formatted output statements were originally designed for
line-printers, with their concept of lines and pages of output. On such
a device, the first character of each output record must be of default
kind. It is not printed but interpreted as a _carriage control character_.
If it is a blank, no action is taken, and it is good practice to insert
a blank as the first character of each record..."
It seems this is something that is better dealt with on the server end -
seems a bit silly for PrimeNet to get discombobulated by an extra blank
space here and there. Scott, any chance you could apply a patch to solve
this problem in the near future? (In between diaper-changing, of course :)
For those of you who own/administrate Alphas, SGIs and SPARCs (or know
someone who does), please get the word out - it would be nice to start
increasing the percentage of non-x86 GIMPS clients, especially now that
there's Mersenne testing code roughly as fast as Prime95 for all these
systems.
The one thing we still need to make it easy to administer multiple
machines (e.g. a lab full of them) is a PrimeNet interface. Scott
suggested to me that the easiest way to do this is to start with the
Mprime (Prime95) for Linux interface routines. Does any want to look
at those, and see if they can get something working for at least one
of the above Unix/Linux clients? If I don't hear from anyone I suppose
I'll have to do it myself, but I honestly prefer to work on the under-
lying "engine" - every day I spend on other things is a day I don't
have to work, e.g. on the Mlucas P-1 factoring code.
Also, I've had no responses to my query about the Absoft f90 compiler
for the Macintosh - is the Mac portion of GIMPS dead, or is the name
"MacLucas" leading all the Mac users to believe that MLU is the only
code that will run on their hardware?
Happy hunting,
Ernst
ftp://209.133.33.182/pub/mayer/home.html
_________________________________________________________________
Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm
Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
