mersenneforum.org prime95 for amd64 on GNU/Linux OR alternative?
 Register FAQ Search Today's Posts Mark Forums Read

 2008-02-26, 12:26 #1 colo   Feb 2008 2 Posts 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
 2008-02-26, 14:46 #2 Prime95 P90 years forever!     Aug 2002 Yeehaw, FL 11110010111112 Posts
 2008-02-26, 17:23 #3 ewmayer ∂2ω=0     Sep 2002 República de California 22·37·79 Posts 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
 2008-02-28, 13:19 #4 colo   Feb 2008 2 Posts 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... :) Last fiddled with by colo on 2008-02-28 at 13:57

 Similar Threads Thread Thread Starter Forum Replies Last Post airsquirrels Software 3 2016-01-17 14:38 frolyar Software 4 2015-07-27 14:10 fes016 Software 1 2007-10-29 01:50 Upperlimit Hardware 0 2006-11-27 16:14 stealthaxe Software 1 2003-05-16 17:55

All times are UTC. The time now is 23:16.

Tue Jan 25 23:16:57 UTC 2022 up 186 days, 17:45, 0 users, load averages: 1.24, 1.24, 1.30