LLR Version 3.8.6 is available!
 

Hi All,

The new version 3.8.6 of LLR is now available on my personal site :

[url]http://jpenne.free.fr/index2.html[/url]

This version is identical to development Version 3.8.5, but uses Version 26.6 of George Woltman's gwnum library.

Please see Readme.txt file for details.

Best Regards,
Jean

P.S. : I still need help to build the Mac Intel binary...

I had to poke the Makefile a little to get it to build on Mac Intel:
[LIST][*]I only have /Developer/SDKs/MacOSX10.5.sdk not .4u.sdk so changed .4u to .5 throughout[*]multutil.o is no longer present in gwnum.a so the code to pull it out explicitly isn't needed[/LIST]
I have run
[code]
./llr -a3 -oVerbose=4 -d -q"3*2^234760-1"
[/code]
successfully (67.3 sec on not-very-idle i7 iMac)

Jean,

if it easy for you, please add a switch like:

[CODE]FBase=<number> : The base for the Fermat PRP test (default is 3)[/CODE]

except for the Lucas test, maybe called "LBase". I am only interested in varying P and having Q=1. Of course I am interested in the jacobi symbol of (P^2-4*Q,N) being -1, which does not take long to determine with pari-gp :wink:

I am currently using a pfgw64 script, but it runs like treacle

Paul :smile:

[QUOTE=paulunderwood;263698]Jean,

if it easy for you, please add a switch like:

[CODE]FBase=<number> : The base for the Fermat PRP test (default is 3)[/CODE]

except for the Lucas test, maybe called "LBase". I am only interested in varying P and having Q=1. Of course I am interested in the jacobi symbol of (P^2-4*Q,N) being -1, which does not take long to determine with pari-gp :wink:

I am currently using a pfgw64 script, but it runs like treacle

Paul :smile:[/QUOTE]


This option does exist, but is not shown in the Readme file, sorry...

It is : PBase=<number>
Note it is only the initial P value, not necessarily the relevant one, that will be computed by the genLucasBaseP() function, starting from this value, and having Q=1 as you requested.

Regards,
Jean

Just out of curiosity I tried to compile the latest source (3.8.6) for Linux 64 bit, but I'm getting the following error:

[CODE]make: *** No rule to make target `factor64p.o', needed by `llr'. Stop.[/CODE]

Is there something missing in the ZIP file, or do need to run some additional "preparational" commands elsewhere in the source tree?

BTW.: I get the same error for the older 3.8.4 sources.

Kind regards,

Thomas

[QUOTE=Thomas11;274876]Just out of curiosity I tried to compile the latest source (3.8.6) for Linux 64 bit, but I'm getting the following error:

[CODE]make: *** No rule to make target `factor64p.o', needed by `llr'. Stop.[/CODE]

Is there something missing in the ZIP file, or do need to run some additional "preparational" commands elsewhere in the source tree?

BTW.: I get the same error for the older 3.8.4 sources.[/QUOTE]

Simple. LLR cannot be built as a 64-bit app (yet) because a factor routine it relies on is written in 32-bit asm.

[QUOTE=rogue;274878]Simple. LLR cannot be built as a 64-bit app (yet) because a factor routine it relies on is written in 32-bit asm.[/QUOTE]

Ahh, I see. Thanks!
I always wondered why there are only 32-bit binaries while the source tree contains those 64-bit directories and build targets...

[QUOTE=Thomas11;274893]Ahh, I see. Thanks!
I always wondered why there are only 32-bit binaries while the source tree contains those 64-bit directories and build targets...[/QUOTE]

If you have a 64-bit OS, then use pfgw (if the projects you work on allow it). It will be faster than 32-bit llr in most cases, and in some cases much faster than llr.

[QUOTE=rogue;274905]If you have a 64-bit OS, then use pfgw (if the projects you work on allow it). It will be faster than 32-bit llr in most cases, and in some cases much faster than llr.[/QUOTE]

Thanks for that hint. I will give it a try.

So far I used pfgw only for "pathological" cases, e.g. very large k values (like for Roberts Smith's [URL="http://www.mersenneforum.org/showthread.php?t=9755"]Very Prime Sequences (VPS)[/URL], also known as Payam sequences), which cannot be treated by LLR.

[QUOTE=rogue;274905]If you have a 64-bit OS, then use pfgw (if the projects you work on allow it). It will be faster than 32-bit llr in most cases, and in some cases much faster than llr.[/QUOTE]

Meanwhile I did some tests using 64-bit pfgw vs. 32-bit LLR (running both on a 64-bit Core2 Linux machine).
And indeed I found that pfgw performs slightly better, e.g. for base>2 tests it seems to be about 7% faster than LLR.

So, again, thanks for your advise!

[QUOTE=Thomas11;275792]Meanwhile I did some tests using 64-bit pfgw vs. 32-bit LLR (running both on a 64-bit Core2 Linux machine).
And indeed I found that pfgw performs slightly better, e.g. for base>2 tests it seems to be about 7% faster than LLR.[/QUOTE]

The speed increase appears to be dependent upon the values of k and b and the CPU the software is run on. Some combinations will see more than a 30% increase in speed. Even for base 2, pfgw64 is faster than LLR on my laptop.

Is there any chance of implementing the "Wagstaff" form (2^p+1)/3? It would only require a tweaked modular reduction -- or is there a 64 bit LLR on its way? :smile:

[QUOTE=rogue;275804]The speed increase appears to be dependent upon the values of k and b and the CPU the software is run on. Some combinations will see more than a 30% increase in speed. Even for base 2, pfgw64 is faster than LLR on my laptop.[/QUOTE]

I am finding the opposite. My version of LLR is currently outperforming PFGW on the numbers I am testing, but I am using base 10 and not base 2.

[QUOTE=SaneMur;276310]I am finding the opposite. My version of LLR is currently outperforming PFGW on the numbers I am testing, but I am using base 10 and not base 2.[/QUOTE]

Are you referring the 64-bit pfgw or 32-bit pfgw?

In some rare occations (for non-base-2 tests) I found that pfgw switches somewhat earlier to a higher FFT length, while LLR stays at the lower FFT length.

I thought that both are using the same routines from gwnums (e.g. gwinfo() ) for determining the proper FFT lengths. But maybe I'm missing something and the algorithms used by both programs are not directly comparable...

[QUOTE=rogue;276311]Are you referring the 64-bit pfgw or 32-bit pfgw?[/QUOTE]

I was using the 64-bit version of pfgw.

[QUOTE=Thomas11;276331]In some rare occations (for non-base-2 tests) I found that pfgw switches somewhat earlier to a higher FFT length, while LLR stays at the lower FFT length.

I thought that both are using the same routines from gwnums (e.g. gwinfo() ) for determining the proper FFT lengths. But maybe I'm missing something and the algorithms used by both programs are not directly comparable...[/QUOTE]

I actually found a prime that the current version of LLR cannot solve. It gets roundoff errors on every machine I try, but PFGW is able to prove it is prime.

The "development version" of LLR, however, can solve it, after resizing the FFT after the first attempt does not work.

llrAVX
 

From [URL="http://www.primegrid.com/forum_thread.php?id=3912&nowrap=true#46393"]here[/URL].

[quote]
[B][URL="http://www.primegrid.com/show_user.php?userid=52890"]Gary Craig[/URL][/B], a member of [B][URL="http://www.primegrid.com/team_display.php?teamid=2280"]Aggie The Pew[/URL][/B], was successful in compiling an AVX version of LLR using [B]gwnum v27.2[/B] ([URL]ftp://mersenne.org/gimps/source272.zip[/URL]) and [B][URL="http://jpenne.free.fr/Development/llr386devsrc.zip"]LLR v3.8.6dev[/URL][/B]. We've been testing it for the past week with success. Depending on the LLR project, speed improvements range from 20% to 50%.

[COLOR=red][B]Currently, this can only be run using an app_info file and only available for [U]Linux 64[/U] and [U]MacIntel[/U] (untested) (we'll gladly accept other builds).[/B][/COLOR] A CPU only app_info file is included in the download that will allow you to participate in the following LLR projects:
[LIST][*]321 Prime Search[*]Cullen Prime Search[*]Prime Sierpinski Problem[*]Proth Prime Search[*]Seventeen or Bust[*]Sophie Germain Prime Search[*]The Riesel Problem[*]Woodall Prime Search[/LIST]Before using app_info, please be sure to have all previous work completed and returned. Otherwise, all work will be lost. If someone would like to provide step by step instructions, I'll be happy to include them in this post. Additionally, if anyone wishes to create a full project app_info file (including GPU), that can be included in the package as well. Ronald has app_info files on his [B][URL="http://primegrid.pytalhost.net/"]site[/URL][/B] which can be modified to use with llrAVX.

Download llrAVX with app_info here: [B][URL="http://www.primegrid.com/download/llr3.8.6dev_avx.7z"]llr3.8.6dev_avx.7z[/URL][/B]

This has been tested on Sandy Bridge but should also work on Bulldozer.
[/quote]

I just completed a succesfull Sierpinski base 58 test with a 38 % speed bost, using Prime95 version 27.2 compared to LLR version 3.8.5, both versions running on Windows 7 64bit on a Sandy Bridge K2500 2.8 GHz, no overclocking done. Both LLR with older thoroughly tested version of GWnum library aswell as Prime95 v. 27.2, produced the same residual, only Prime95 used 6 minutes and 16.75 seconds while LLR used 10 minues and 9.455 seconds. This succesfull testing aswell as primegrid reports of no problem using the new AVX FFTs, has convinced me to use Prime95, to complete the remainder of my S58 tests.

Thanks for the hard work George. If anyone explodes and gets annoyed of me mentioning my equipment, please feel free to edit that part out. No offence if you do :smile:

Take care

Kenneth

People over there [url=http://www.primegrid.com/forum_thread.php?id=3933]are reporting problems[/url] with the AVX build on AMD Bulldozer-based processors. Any such problems over here with 27.2?

I think the main issue is people running this new version without comparing residues from previous stable client but I am not the one who will be doing double checks so I don't care.

This problem has nothing to do with DC...
I compiled llr386 and llr386dev against the gwnum27.2 and get problems also with my Core2-cpu's. [quote]After seeing some invalid SGS-results in the stats for my [url=http://www.primegrid.com/results.php?hostid=115188&offset=0&show_names=0&state=4&appid=2]host 115188[/url], i started one on the bash and got the message: [quote]./[b]sllr3.8.6-linux32_avx[/b] -d -q"30448908048555*2^666666-1"
Starting Lucas Lehmer Riesel prime test of 30448908048555*2^666666-1
Using zero-padded Core2 type-1 FFT length 72K, Pass1=96, Pass2=768
Iter: 6/45, ERROR: ROUND OFF (1) > 0.4
Continuing from last save file.
Disregard last error. Result is reproducible and thus not a hardware problem.
For added safety, redoing iteration using a slower, more reliable method.
Continuing from last save file.
Iter: 6/45, ERROR: ROUND OFF (1) > 0.4
Continuing from last save file.
Unrecoverable error, Restarting with next larger FFT length...
Starting Lucas Lehmer Riesel prime test of 30448908048555*2^666666-1
Using zero-padded Core2 type-3 FFT length 80K, Pass1=320, Pass2=256
Iter: 5/45, ERROR: ROUND OFF (1) > 0.4
Continuing from last save file.
Iter: 3/45, ERROR: ROUND OFF (1) > 0.4
Continuing from last save file.
Iter: 4/45, ERROR: ROUND OFF (1) > 0.4
Continuing from last save file.
Disregard last error. Result is reproducible and thus not a hardware problem.
For added safety, redoing iteration using a slower, more reliable method.
Continuing from last save file.
[b]Fatal error at setup : Number sent to gwsetup is too large for the FFTs to handle.[/b]
[/quote]

I get the same message also with: [quote]./[b]sllr3.8.6[u]dev[/u]-linux32_avx[/b] -d -q"30448908048555*2^666666-1"
Starting Lucas Lehmer Riesel prime test of 30448908048555*2^666666-1
Using zero-padded Core2 type-1 FFT length 72K, Pass1=96, Pass2=768
Iter: 6/45, ERROR: ROUND OFF (1) > 0.4
Continuing from last save file.
Disregard last error. Result is reproducible and thus not a hardware problem.
For added safety, redoing iteration using a slower, more reliable method.
Continuing from last save file.
Iter: 6/45, ERROR: ROUND OFF (1) > 0.4
Continuing from last save file.
Unrecoverable error, Restarting with next larger FFT length...
Starting Lucas Lehmer Riesel prime test of 30448908048555*2^666666-1
Using zero-padded Core2 type-3 FFT length 80K, Pass1=320, Pass2=256
Iter: 6/45, ERROR: ROUND OFF (1) > 0.4
Continuing from last save file.
Unrecoverable error, Restarting with next larger FFT length...
Starting Lucas Lehmer Riesel prime test of 30448908048555*2^666666-1
Using zero-padded Core2 type-1 FFT length 84K, Pass1=112, Pass2=768
Iter: 6/45, ERROR: ROUND OFF (1) > 0.4
Continuing from last save file.
Unrecoverable error, Restarting with next larger FFT length...
Starting Lucas Lehmer Riesel prime test of 30448908048555*2^666666-1
Using zero-padded Core2 type-3 FFT length 96K, Pass1=128, Pass2=768
Iter: 6/45, ERROR: ROUND OFF (1) > 0.4
Continuing from last save file.
Unrecoverable error, Restarting with next larger FFT length...
Starting Lucas Lehmer Riesel prime test of 30448908048555*2^666666-1
Using zero-padded Core2 type-3 FFT length 112K, Pass1=448, Pass2=256
Iter: 5/45, ERROR: ROUND OFF (1) > 0.4
Continuing from last save file.
Iter: 5/45, ERROR: ROUND OFF (1) > 0.4
Continuing from last save file.
Unrecoverable error, Restarting with next larger FFT length...
[b]Fatal error at setup : Number sent to gwsetup is too large for the FFTs to handle.[/b][/quote]

...and: [quote]./[b]sllr3.8.6[u]dev[/u]-linux64_avx[/b] -d -q"30448908048555*2^666666-1"
Starting Lucas Lehmer Riesel prime test of 30448908048555*2^666666-1
Using zero-padded Core2 type-1 FFT length 72K, Pass1=96, Pass2=768
Iter: 6/45, ERROR: ROUND OFF (1) > 0.4
Continuing from last save file.
Disregard last error. Result is reproducible and thus not a hardware problem.
For added safety, redoing iteration using a slower, more reliable method.
Continuing from last save file.
Iter: 6/45, ERROR: ROUND OFF (1) > 0.4
Continuing from last save file.
Unrecoverable error, Restarting with next larger FFT length...
Starting Lucas Lehmer Riesel prime test of 30448908048555*2^666666-1
Using zero-padded Core2 type-3 FFT length 80K, Pass1=320, Pass2=256
Iter: 6/45, ERROR: ROUND OFF (1) > 0.4
Continuing from last save file.
Unrecoverable error, Restarting with next larger FFT length...
Starting Lucas Lehmer Riesel prime test of 30448908048555*2^666666-1
Using zero-padded Core2 type-1 FFT length 84K, Pass1=112, Pass2=768
Iter: 6/45, ERROR: ROUND OFF (1) > 0.4
Continuing from last save file.
Unrecoverable error, Restarting with next larger FFT length...
Starting Lucas Lehmer Riesel prime test of 30448908048555*2^666666-1
Using zero-padded Core2 type-3 FFT length 96K, Pass1=128, Pass2=768
Iter: 6/45, ERROR: ROUND OFF (1) > 0.4
Continuing from last save file.
Unrecoverable error, Restarting with next larger FFT length...
Starting Lucas Lehmer Riesel prime test of 30448908048555*2^666666-1
Using zero-padded Core2 type-3 FFT length 112K, Pass1=448, Pass2=256
Iter: 5/45, ERROR: ROUND OFF (1) > 0.4
Continuing from last save file.
Iter: 5/45, ERROR: ROUND OFF (1) > 0.4
Continuing from last save file.
Unrecoverable error, Restarting with next larger FFT length...
[b]Fatal error at setup : Number sent to gwsetup is too large for the FFTs to handle.[/b]
[/quote]



[add]
I made a retest with the PG-app v6.10: [quote]./[b]primegrid_sllr_3.8.6_i686-pc-linux-gnu[/b] -d -q"30448908048555*2^666666-1"
Starting Lucas Lehmer Riesel prime test of 30448908048555*2^666666-1
Using zero-padded Core2 type-1 FFT length 72K, Pass1=96, Pass2=768
V1 = 5 ; Computing U0...done.Starting Lucas-Lehmer loop...
30448908048555*2^666666-1, iteration : 10000 / 666666 [1.50%]. Time per iteration : 1.292 ms.
448908048555*2^666666-1, iteration : 30000 / 666666 [4.50%]. Time per iteration : 1.245 ms.
^C
Caught signal. Terminating.[/quote][/quote]

[QUOTE=Ken_g6;286248]People over there [url=http://www.primegrid.com/forum_thread.php?id=3933]are reporting problems[/url] with the AVX build on AMD Bulldozer-based processors. Any such problems over here with 27.2?[/QUOTE]

I'm not surprised. Version 27.1 did not work on Bulldozer.

We used [URL="http://ftp//mersenne.org/gimps/source272.zip"]http://ftp//mersenne.org/gimps/source272.zip[/URL] as source and use only the gwnum-folder.
After adding [QUOTE]OBJS = cpuid.o gwnum.o gwthread.o gwutil.o gwdbldbl.o giants.o ecmstag1.o [B]gwtables.o[/B][/QUOTE] ...to the gwnum-makefile, we could compile llr- and sllr-apps with AVX-support.

[QUOTE=Ken_g6;286248]People over there [URL="http://www.primegrid.com/forum_thread.php?id=3933"]are reporting problems[/URL] with the AVX build on AMD Bulldozer-based processors. Any such problems over here with 27.2?[/QUOTE]

27.2 on Bulldozer doesn't work for me.

I just have a strange crash while testing R207

[code]
Base factorized as : 3^2*23
Base prime factor(s) taken : 23
Resuming N+1 prime test of 22394*207^17425-1 at bit 2 [0.00%]
Using AVX Core2 type-3 FFT length 18K, Pass1=384, Pass2=48, a = 3
[/code]LLR (cmd line version) crash (tried 2 times). once the line removed, it continued to crrunch happilly( i tested the 'offending' value with pfgw)
I tested it in pfgw, and it worked.
Win 7 home premium, using a i5-2500k at stock speed
more precision : only the llr avx console version seem to crash. gui-non avx do not crash. regular 3.8.6 doesn't either.
blame it on the llravx build found on primegrid.

[QUOTE=firejuggler;292370]Win 7 home premium, using a i5-2500k at stock speed
more precision : only the llr avx console version seem to crash. gui-non avx do not crash. regular 3.8.6 doesn't either.
blame it on the llravx build found on primegrid.[/QUOTE]

Regular 3.8.6 and also 3.8.7 has no AVX-support. You need at least gwnum27.2 for AVX on an Intel cpu.
Win 7 without SP1 has no AVX-support. Linux supports AVX since kernel 2.6.30, released 2009-06-09...

[QUOTE=rroonnaalldd;292507]Regular 3.8.6 and also 3.8.7 has no AVX-support. You need at least gwnum27.2 for AVX on an Intel cpu.
Win 7 without SP1 has no AVX-support. Linux supports AVX since kernel 2.6.30, released 2009-06-09...[/QUOTE]

If anyone is running llr + gwnum v27, please stop. gwnum v27 (and v27.2 specifically) has some bugs that cause incorrect results. Until Jean releases llr + gwnum v27.4, I strongly recommend that you run with his official release.