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 :

[url]http://jpenne.free.fr/Development/[/url]

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

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!

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]

[QUOTE]6

EBADF -- Bad file descriptor: an invalid file handle passed to a library function. [/QUOTE]

I set the save file time to 2000 minutes and the problem has gone away, so far :smile:

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).

[QUOTE=Thomas11;288939]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).[/QUOTE]

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.

[QUOTE=rogue;288943]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.[/QUOTE]

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.

[QUOTE=Thomas11;288947]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.[/QUOTE]

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.

[QUOTE=rogue;288951]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.[/QUOTE]

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.

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.
[url]http://www.mersenneforum.org/showpost.php?p=287475&postcount=125[/url]

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.

I've built a 64 bit Windows version which can be downloaded [url=http://www.asgoodasitgoetz.com/distribution/cllr387dev-win-x64.7z]here[/url].

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% [b]reduction[/b] in speed on an i7-920. See the [url=http://www.primegrid.com/forum_thread.php?id=4016&nowrap=true#49359]LLR development version 3.8.7 is available![/url] thread on PrimeGrid for more information.