View Single Post
Old 2008-02-26, 12:26   #1
colo
 
Feb 2008

2 Posts
Default prime95 for amd64 on GNU/Linux OR alternative?

Hello there,

I don't know if this is the right subform to post this thread to, so if you feel it needs moving, please do so.

I'm running an ~amd64-box without any legacy 32bit-support at all. Due to recently developed stability issues, I'd like to run test suites for different hardware components on my machine (Core 2 Quad, 8GB RAM), one of those being prime95 ( available at www.mersenne.org ). The site does provide binaries for IA32 and also a source archive, however, I can't get the latter to compile (or rather link) correctly on my machine. There are some precompiled object files included in the archive which are 32bit only, in turn shooting ld in the foot.

So what I'd need is either
a) a prime95 build that indeed is compiled for x86_64 in binary form OR
b) a way to have the archive build on pure 64bit OR
c) an alternative program that does a job about as good as prime95 to mathematically verify the correctness of my processors' computational results.

I'd be delighted if someone knowledgable could step up and guide me to a fitting solution to my problem :)

Update:
Meanwhile, I discovered Mlucas, a program designed to find mersenne prime numbers on "uncommon" arches - it's available at http://www.hogranch.com/mayer/README.html

I uploaded a slightly modified source archive (providing a makefile, wa wa wee wa!) to http://johannes.truschnigg.info/uplo...as_src.tar.bz2
Executing the resulting binary, however, gives rather strange errors on my machine, which I do not understand to interpret, along the lines of
Code:
100 iterations of M2550001 with FFT length 131072
Res64: 0000000000000000. AvgMaxErr = 0.000000000. Program: E2.8x
  ***   Res64 Error   ***
 current   = 0000000000000000
 should be = CB6030D5790E2460
Clocks = 00:00:04.980
Two other fellows who tried compiling the source tarball did not get any further than to a forced exit with
Code:
INFO: using 64-bit-double form of rounding constant
INFO: Using subroutine form of MUL_LOHI
ERROR 12 in qfloat.c
I copied the CFLAGS from the last recorded build comments on GNU/Linux-amd6 (and also noticed that my binaries failed to run with lesser optimization than -O3; is this expected?).

Could any kind person please try to reproduce any of the problems listed above?
If anyone familiar with Mlucas is able to explain what is blowing up why, I'd really be thankful (I'm going to bug the developer if everything stays silent).

Thanks in advance, cheers!
- colo
colo is offline   Reply With Quote