mersenneforum.org  

Go Back   mersenneforum.org > Great Internet Mersenne Prime Search > Software

Reply
 
Thread Tools
Old 2012-02-01, 20:32   #1
Jean Penné
 
Jean Penné's Avatar
 
May 2004
FRANCE

22616 Posts
Default LLR development version 3.8.7 is available!

Hi All,

I uploaded today the development version 3.8.7 of LLR program.
You can find it now in my development directory :

http://jpenne.free.fr/Development/

The 32bit Windows and Linux compressed binaries are available as usual.
I uploaded also the complete source in a compressed file ; it may be used to
build the Mac-Intel executable and also (I hope) the 64bit binaries.

In this new version, the base b can now be an arbitrary large integer
(however restricted to 64 bits for fixed b formats). This is especially
useful while testing Generalized Fermat numbers.

This new version can be built on 64bit platforms, but then, the prefactoring
code is no more available. This affects only the Gaussian-Mersenne norm and
Wagstaff tests, for which the prefactoring must be done using a 32bit program.

Please, consult the Readme file for more details, and let me know if problems are encountered...

Best Regards,
Jean
Jean Penné is offline   Reply With Quote
Old 2012-02-02, 09:59   #2
Thomas11
 
Thomas11's Avatar
 
Feb 2003

190110 Posts
Default

I just built the 64bit version on a Linux system and it runs about 10-12% faster than the 32bit binary of version 3.8.6.

Well done, Jean!
Thomas11 is offline   Reply With Quote
Old 2012-02-05, 19:19   #3
paulunderwood
 
paulunderwood's Avatar
 
Sep 2002
Database er0rr

32×349 Posts
Default

I compiled llr64, simply by going into the appropriate directoy and running "make", and noticed the same sort of speed ups with it as Thomas did.

However on one of my multi-core boxes running Debian on a usb stick, I got segmentation faults. It was a problem with libc giving errors 4 and 6:

Quote:
4

EACCES -- Permission denied. Attempt to write to a read-only file, or remove a non-empty directory, or open a directory as if it were a file, etc. In essence, it's a DOS way of saying "You can't do that, but I'm too stupid to know why."
Quote:
6

EBADF -- Bad file descriptor: an invalid file handle passed to a library function.
I set the save file time to 2000 minutes and the problem has gone away, so far

Last fiddled with by paulunderwood on 2012-02-05 at 19:54
paulunderwood is offline   Reply With Quote
Old 2012-02-10, 19:55   #4
Thomas11
 
Thomas11's Avatar
 
Feb 2003

1,901 Posts
Default

There may be a possible memory leak for the 64bit Linux binary (perhaps also for the 32bit version):

I was running 4 instances on a quadcore machine. After about one week I noticed that each of them had eaten about 1GB of the 4GB total memory, and the machine was in an endless swapping loop.
The numbers I'm testing (Generalized Woodalls, base=160-200, n=100-150k) typically require only about 10-12MB. At least this is the number the "top" utility shows me for a "freshly started" LLR.

Now I restarted all four instances and will watch them closely.
Perhaps somebody else should check this behavior too (e.g. also for the 32bit binary).

Last fiddled with by Thomas11 on 2012-02-10 at 19:56
Thomas11 is offline   Reply With Quote
Old 2012-02-10, 20:33   #5
rogue
 
rogue's Avatar
 
"Mark"
Apr 2003
Between here and the

127658 Posts
Default

Quote:
Originally Posted by Thomas11 View Post
There may be a possible memory leak for the 64bit Linux binary (perhaps also for the 32bit version):

I was running 4 instances on a quadcore machine. After about one week I noticed that each of them had eaten about 1GB of the 4GB total memory, and the machine was in an endless swapping loop.
The numbers I'm testing (Generalized Woodalls, base=160-200, n=100-150k) typically require only about 10-12MB. At least this is the number the "top" utility shows me for a "freshly started" LLR.

Now I restarted all four instances and will watch them closely.
Perhaps somebody else should check this behavior too (e.g. also for the 32bit binary).
Consider running pfgw64 for a short time. If the memory leak is in gwnum, then it will leak as well. If the leak is in llr, then pfgw64 wouldn't gobble as much memory.
rogue is offline   Reply With Quote
Old 2012-02-10, 21:25   #6
Thomas11
 
Thomas11's Avatar
 
Feb 2003

1,901 Posts
Default

Quote:
Originally Posted by rogue View Post
Consider running pfgw64 for a short time. If the memory leak is in gwnum, then it will leak as well. If the leak is in llr, then pfgw64 wouldn't gobble as much memory.
I'm using pfgw64 (version 3.5.6.64BIT.20111017 / gwnum 26.6) for about two months now on a second (identical) machine for testing Payam numbers, and there is no indication for a memory leak.

The newly started 64bit LLR instances are already leaking again:
While the memory usage stays constant during a test, it roughly doubled once the second test started from the input file. So it seems that it does not free the memory after completing a test.

Last fiddled with by Thomas11 on 2012-02-10 at 21:26
Thomas11 is offline   Reply With Quote
Old 2012-02-10, 22:05   #7
rogue
 
rogue's Avatar
 
"Mark"
Apr 2003
Between here and the

562110 Posts
Default

Quote:
Originally Posted by Thomas11 View Post
I'm using pfgw64 (version 3.5.6.64BIT.20111017 / gwnum 26.6) for about two months now on a second (identical) machine for testing Payam numbers, and there is no indication for a memory leak.

The newly started 64bit LLR instances are already leaking again:
While the memory usage stays constant during a test, it roughly doubled once the second test started from the input file. So it seems that it does not free the memory after completing a test.
I haven't released pfgw with gwnum v27.2. It is possible that the problem is with gwnum v27.2 or llr, but there is no way for you to tell right now.
rogue is offline   Reply With Quote
Old 2012-02-10, 22:16   #8
Thomas11
 
Thomas11's Avatar
 
Feb 2003

1,901 Posts
Default

Quote:
Originally Posted by rogue View Post
I haven't released pfgw with gwnum v27.2. It is possible that the problem is with gwnum v27.2 or llr, but there is no way for you to tell right now.
The source code of LLR 3.8.7 still uses gwnum 26.5.
There are other people around who (successfully?) replaced the gwnums by version 27.2, but I just compiled the source without any modifications.
Thomas11 is offline   Reply With Quote
Old 2012-02-10, 22:25   #9
Dubslow
Basketry That Evening!
 
Dubslow's Avatar
 
"Bunslow the Bold"
Jun 2011
40<A<43 -89<O<-88

11100001101012 Posts
Default

I've had issues with MPrime 26.6 with P-1 Stage 2 memory not being freed after Stage 2 completes, but it certainly doesn't gobble up extra memory like you're saying.
http://www.mersenneforum.org/showpos...&postcount=125
Dubslow is offline   Reply With Quote
Old 2012-02-10, 22:28   #10
Thomas11
 
Thomas11's Avatar
 
Feb 2003

1,901 Posts
Default

Meanwhile I tested the 32bit Linux binary provided by Jean Penne, and it leaks too...

I've run the same tests for LLR 3.8.6 and there is no indication for a memory leak.

Last fiddled with by Thomas11 on 2012-02-10 at 22:47
Thomas11 is offline   Reply With Quote
Old 2012-02-11, 00:24   #11
AG5BPilot
 
AG5BPilot's Avatar
 
Dec 2011
New York, U.S.A.

97 Posts
Default

I've built a 64 bit Windows version which can be downloaded here.

As others have reported on Linux, I'm seeing a 10 to 12% speed improvement on my C2Q Q6600. However, one person noticed a 10% reduction in speed on an i7-920. See the LLR development version 3.8.7 is available! thread on PrimeGrid for more information.
AG5BPilot is offline   Reply With Quote
Reply

Thread Tools


Similar Threads
Thread Thread Starter Forum Replies Last Post
LLR Development Version 3.8.9 released. Jean Penné Software 6 2012-05-09 23:44
LLR 3.8.6 Development version Jean Penné Software 0 2011-06-16 20:05
LLR 3.8.5 Development version Jean Penné Software 6 2011-04-28 06:21
PowerPC development platform nuggetprime Hardware 2 2011-01-06 18:37
LLR 3.8.4 development version is available! Jean Penné Software 4 2010-11-14 17:32

All times are UTC. The time now is 04:17.

Sun Apr 5 04:17:06 UTC 2020 up 11 days, 1:50, 1 user, load averages: 1.16, 1.45, 1.45

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

This forum has received and complied with 0 (zero) government requests for information.

Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.2 or any later version published by the Free Software Foundation.
A copy of the license is included in the FAQ.