mersenneforum.org

mersenneforum.org (https://www.mersenneforum.org/index.php)
-   Software (https://www.mersenneforum.org/forumdisplay.php?f=10)
-   -   prime95 for amd64 on GNU/Linux OR alternative? (https://www.mersenneforum.org/showthread.php?t=10026)

colo 2008-02-26 12:26

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 [url]www.mersenne.org[/url] ). 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 [url]http://www.hogranch.com/mayer/README.html[/url]

I uploaded a slightly modified source archive (providing a makefile, wa wa wee wa!) to [url]http://johannes.truschnigg.info/upload/Mlucas_src.tar.bz2[/url]
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[/code]

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[/code]

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

Prime95 2008-02-26 14:46

Try [url]http://www.mersenneforum.org/showthread.php?t=9779[/url]

ewmayer 2008-02-26 17:23

Hi, Colo:

I am the author of the 2nd program you mention. Depending on the compiler you are using, you may have to turn down the optimization level on several routines, specifically these:

qfloat.c
util.c

in order to get a working build. The above code is not timing-critical, so using e.g. -O0 [try that first] or -O1 instead of -O2 or -O3 should not hurt overall performance. Since Mlucas usually uses a one-line compile [i.e. there's no makefile], the easiest way to tweak the build in the necessary manner is to do e.g.

gcc -O3 *.c
gcc -O0 util.c qfloat.c
gcc -o Mlucas.exe *.o -lm

Let me know if that works. Be aware that the performance will likely suck relative to Prime95 - no x86-specific assembly code in the current release version of Mlucas, e.g. no SSE2 optimizations. I am working hard on the latter [a.k.a. "what I did over the winter holidays, and nearly every evening and weekend since"] and getting pretty close [i.e. a few months away] from a beta for people to test, but that will be ready ... when it's ready.

Cheers,
-Ernst

colo 2008-02-28 13:19

Hello all,

first of all, thanks for your kind and prompt replies - this really is a nice place on the web :)
Using the prime95 build provided, I could track down some problems whilst running the Blend-test, therefore I think my memory-subsystem might be somewhat unstable (initially, compiling large C++ sources failed on the machine in question).
I'm fiddling with some memory-related settings in my BIOS now, and as soon as I'm able to run 2 processes of the now-multithreaded (nice work by the way, kudos! :)) mprime for 24 consecutive hours without errors, I'll look into Mlucas once more, to answer Ernst's questions.

Have a fine time, cheers!
- colo

Edit:
On a somewhat related note, is there a way to have mprime exit when an error is detected while stress-testing? Because if something goes awry during computing, I'd like to be notified asap to tune the memory settings once again, and restart the testing procedure - which is cumbersome if you have to manually check all X minutes... :)


All times are UTC. The time now is 13:44.

Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2022, Jelsoft Enterprises Ltd.