mersenneforum.org LLR Version 3.8.15 released
 Register FAQ Search Today's Posts Mark Forums Read

 2015-05-06, 19:57 #12 Jean Penné     May 2004 FRANCE 571 Posts Mac Intel applications are available. Hi, Thanks to Iain Bethune, Mac Intel 32bit and 64bit applications are now available. Regards, Jean
 2015-05-07, 19:58 #13 Jean Penné     May 2004 FRANCE 571 Posts Upgrading the version display Hi, At the request of Iain and PrimeGrid project, I upgraded the -v feature on current LLR Version ; now, ./llr -v or cllr -v give this output : LLR Program - Version 3.8.15, using Gwnum Library Version 28.7 I uploaded the updated source, Win32 console, Linux 32bit and 64bit applications accordingly. Mac Intel , and perhaps the Win64 console application, need to be rebuilt ; Windows GUI applications are not concerned, and so, not modified. Regards, Jean
2015-05-09, 07:43   #14
Jean Penné

May 2004
FRANCE

571 Posts

Quote:
 Originally Posted by Jean Penné Hi, At the request of Iain and PrimeGrid project, I upgraded the -v feature on current LLR Version ; now, ./llr -v or cllr -v give this output : LLR Program - Version 3.8.15, using Gwnum Library Version 28.7 I uploaded the updated source, Win32 console, Linux 32bit and 64bit applications accordingly. Mac Intel , and perhaps the Win64 console application, need to be rebuilt ; Windows GUI applications are not concerned, and so, not modified. Regards, Jean
Thanks to Iain, Mac Intel applications are now updated on this release.
Regards,
Jean

2015-05-09, 20:56   #15
Jean Penné

May 2004
FRANCE

571 Posts

Quote:
 Originally Posted by Jean Penné Thanks to Iain, Mac Intel applications are now updated on this release. Regards, Jean
Thank to Rebirther, the Win64 Console and GUI applications are now also updated in this release.
Regards,
Jean

 2015-05-11, 19:53 #16 stream   May 2015 1002 Posts Jean, thank you for update. Unfortunately, I afraid that we're moving in wrong direction. The change which you've suggested and implemented may work for PrimeGrid, but I'd rather call it not a solution, but a workaround. I'll post a summary of the problem once again here. I would be very appreciated to hear opinions of other developers, how this situation is handled in their programs. The problem which affected PrimeGrid seems to be in LLR for ages. It's in the logic how LLR behaves with ErrorCheck=1 option (so why PG does not using ErrorCheck). First time it was described in this post. The scenario is following. 1) LLR have following piece of code: Code: if (error_count > MAX_ERROR_COUNT) {\ OutputBoth (ERRMSG9);\ care = TRUE;\ }\ where MAX_ERROR_COUNT=5. 2) When a "repeatable" roundoff error (>0.4) occurs (i.e. this is not a hardware fault, but an unlucky FFT size), after fixing the error itself with few "careful" iterations, an error_count is incremented, and nothing else is done. 3) It's possible that very long (SoB) unlucky candidate will generate more then 5 RoundOff errors. According to the condition above, a "care" flag is set, and, as far as I understand, ALL operations from now on will be done using "careful" functions. This leads to deadly effects - according to the original post, "The result was that LLR was going to take 11.3 days instead of 2.7 days.". This is completely unacceptable for PrimeGrid due to return timeouts, possible complains about credits, etc. This leads to a question: how this situation (multiple "soft" RoundOffs per candidate) are handled in other programs? I see two trivial solutions which will be compatible with PG: No need to handle this case at all. The code above must be completely removed. Why this magic number of 5 errors appeared at all? Since this is not a hardware problem, let's continue to crunch and recover (if necessary) in usual way. Restart with FFT_Increment. Details of implementation could be discussed (should it restart on first error? 2? 3? 5?). This is good because it'll be no future errors and restarts, and acceptable for PG because FFT_Increment is really not so time-consuming (from original post - "It took an hour or two longer than with the original FFT size" - with 2.7 days total). Any comments are appreciated. Roman
 2015-05-17, 03:36 #17 paulunderwood     Sep 2002 Database er0rr 2·3·599 Posts LLR timings / FFT sizes for different k Code: Starting Lucas Lehmer Riesel prime test of 733*2^1001099-1 Using FMA3 FFT length 64K, Pass1=256, Pass2=256 733*2^1001099-1 is not prime. LLR Res64: 394E30CF7BB572C3 Time : 167.814 sec. Starting Lucas Lehmer Riesel prime test of 9959*2^1000040-1 Using FMA3 FFT length 80K, Pass1=320, Pass2=256 9959*2^1000040-1 is not prime. LLR Res64: 0AF38FB979C9314F Time : 214.790 sec. Are smaller FFT sizes chosen for small k?
 2015-05-17, 03:39 #18 Batalov     "Serge" Mar 2008 Phi(4,2^7658614+1)/2 32·17·61 Posts They always were.
 2015-05-17, 03:45 #19 paulunderwood     Sep 2002 Database er0rr 2·3·599 Posts Thanks for the info
 2015-05-25, 00:40 #20 rogue     "Mark" Apr 2003 Between here and the 6,247 Posts A change was made to LLR 3.8.15 that does not work with PRPNet. I'm testing a change with the client to address the problem. Please do not use LLR 3.8.15 with PRPNet until PRPnet is updated.
 2015-06-03, 19:52 #21 pepi37     Dec 2011 After milion nines:) 25778 Posts Just cosmetic change: can somebody add to windows version that prime is highlighted ( like in linux version) in next release.
2015-06-04, 06:28   #22
Jean Penné

May 2004
FRANCE

571 Posts
Special character(s)?

Quote:
 Originally Posted by pepi37 Just cosmetic change: can somebody add to windows version that prime is highlighted ( like in linux version) in next release.
I will add this in the next release, but need help to know what special character(s) most be sent to the console,
the magic : OutputStr("\033[7m"); works on Linux, but does not work on Windows...

Regards,
Jean

 Similar Threads Thread Thread Starter Forum Replies Last Post Jean Penné Software 30 2018-08-13 20:00 Jean Penné Software 11 2017-02-23 08:52 Jean Penné Software 37 2014-01-29 16:32 Jean Penné Software 37 2013-10-31 08:45 opyrt Prime Sierpinski Project 11 2010-11-18 18:24

All times are UTC. The time now is 03:37.

Sun Mar 7 03:37:12 UTC 2021 up 93 days, 23:48, 0 users, load averages: 1.68, 1.81, 1.67