20040802, 21:04  #1 
11100011001_{2} Posts 
New LLR's
The new LLR's are available!
Let's see how they go. 
20040802, 21:37  #2 
2×503 Posts 
bugs
LLR2, and LLRP4 both crashed on larger exponents when updating iterations, but I was able to debug them both this time! I'm still testing this but it looks good, since the example runs would always crash, and now they do not.
I will make this available later today, if all goes well testing the other functionality of LLR/P4/2. I noticed that the source is not available for these yet...? 
20040802, 23:48  #3 
10205_{8} Posts 
It works!
All is fine now!!
I have tested all the error examples I could find posted, and LLR2, and LLRP4 DO NOT crash anymore! I tested the old LLR, in the same directory, and crashed. On error, I debuged by inserting a breakpoint, and then disabled it. It was giving a "missing symbol error", for debug I believe." The compiler used to create LLR, does not include these. (Or so this is what I have read.) My compiler does, and so If anyone experiences problems with the new LLR's I have executables, or in zip form. 
20040803, 07:23  #4  
Banned
"Luigi"
Aug 2002
Team Italia
2·7^{4} Posts 
Quote:
Luigi 

20040803, 08:23  #5 
Nov 2003
111000100110_{2} Posts 
Thanks for the info, I had no idea that the new LLR is out!
I guess I have to check other sites and try by myself but maybe you have some answers: 1) Is it faster for the same k/n pairs than before? 2) Is there any speedup for k's larger than before, say k>1000 3) Is the decision on optimal fft length improved? Now, for every k I tested there are ranges of n where it takes the client 5070% longer to complete the test after making an initial wrong guess about the fft len to use. For me, this is the biggest problem with the current version. And not to forget: 4) Is there a new version of LLRnet using new LLR? 
20040803, 08:43  #6  
Feb 2003
2^{2}×3^{2}×53 Posts 
Quote:
3) The FFT length guess is improved in both versions. The nonSSE2 version is in principle a modified LLR2 with an improved stop/restart behaviour and a new (empirical) formula for guessing the FFT length. The formula works optimal for k<32, but on larger k it tends to overestimate the FFT length. There shouldn't be too much "switching to next fftlen..." any more. I don't know how Jean does the guess in LLR/P4, but it seems to work very well. 4) I haven't seen a new LLRnet yet. But I guess that RieselSieve is still working on it ...  Thomas Last fiddled with by Thomas11 on 20040803 at 08:45 

20040803, 15:52  #7 
P90 years forever!
Aug 2002
Yeehaw, FL
7×1,051 Posts 
Please note that the new faster LLR for the P4 and other SSE2 machines is really a beta version. It could well have bugs as there has been massive changes to the internal FFTs. I've run some QA as have others, but there could well be some undiscovered bugs.
As to questions raised: The larger the k value the more speed improvement you should see. LLR2 used Percival's IBDWT which cost log2(k) bits in each FFT word. I found an improvement which costs only log2(k)/2 bits in each FFT word. If k is really large, the FFTs now handle that during carry propagation rather than as a separate slow step after the multiplication. The FFT size guessing is now done by the gwnum library, which I hope Jean has not bypassed. Last fiddled with by Prime95 on 20040803 at 15:58 
20040804, 09:33  #8 
Nov 2003
2×1,811 Posts 
Thanks for your replies.
I did some tests and the new LLR4 is much faster for small k's. Also, there was no loss due to bad fft len guesses, actually new fft len's are shorter than before! All times measured on P4 Xeon 2.4 GHz. 1a) 7/990497 using LLRnet command line client (note a huge loss due to poor fft len guesses) [Wed Jul 21 09:32:59 2004] Using IBDWT : Mersenne fftlen = 49152, Proth fftlen = 114688, Used fftlen = 57344 fftlen seems to be too small, using next fftlen... Using IBDWT : Mersenne fftlen = 49152, Proth fftlen = 114688, Used fftlen = 65536 [Wed Jul 21 09:54:40 2004] fftlen seems to be too small, using next fftlen... Using IBDWT : Mersenne fftlen = 49152, Proth fftlen = 114688, Used fftlen = 81920 [Wed Jul 21 10:48:04 2004] 7*2^9904971 is not prime. Res64: 74656FFF39A98F6B Time : 3204.176 sec. 1b) 7/1000017 using LLR4 Using IBDWT : Mersenne fftlen = 57344, Proth fftlen = 114688, Used fftlen = 57344 7*2^10000171 is not prime. Res64: 47F70700569F8CC3 Time : 2004.547 sec. 2a) 21/505957 LLRnet Using IBDWT : Mersenne fftlen = 28672, Proth fftlen = 57344, Used fftlen = 40960 21*2^5059571 is not prime. Res64: F0E0453F93088221 Time : 682.713 sec. 2b) 21/510051 LLR4 Using IBDWT : Mersenne fftlen = 28672, Proth fftlen = 57344, Used fftlen = 28672 21*2^5100511 is not prime. Res64: 3BDFB30DB7C067E7 Time : 452.360 sec. 3) 800532/800532 (Woodall candidate) LLR4 Using IBDWT : Mersenne fftlen = 40960, Proth fftlen = 81920, Used fftlen = 81920 800532*2^8005321 is not prime. Res64: 7A6FEBE8ECC89802 Time : 2700.511 sec. The fft len is a small disappointment but on 3.2GHz Xeon Woodalls of this size required about 2800s using old LLR. Note that these are all dual machines and the load on the second cpu was similar in all respective cases but not identical, for more precise measurements one has to use a singlecpu machine. 
20040819, 09:04  #9 
2×11×241 Posts 
New LLR P42
The new LLR P42, of 8/15/04 also crashed on all my machines until I debugged it.
If anyone wishes to use my modified LLR's, email me at: divineprime@yahoo.com I will see if Anderson will host the files as well. 
20040824, 22:41  #10 
Sep 2002
106_{16} Posts 
When I work on large k's it crashes on the stop and restart. Not a major problem!
Joss 
20040824, 23:08  #11 
3×17×37 Posts 
llr
Joss, Are you using windows?
Try mine then. I deleted two extra forms, that were nonfunctional. One of them was a double of the main form, which may create an ambiguity in that sense. I say this because calling the appId(process) has a strange behaviour, that it needs to be called twice, otherwise it will only come up, every other time. Hence I belive, VB is calling "Main" "Dummy", "Main"... There were two additional debug files, that were missing, ie THIS_FILE etc. They are properly referenced now. Please. Last fiddled with by TTn on 20040824 at 23:09 