LLR Version 3.8.15 released

[Jean Penné]

Hi,

Thanks to Iain Bethune, Mac Intel 32bit and 64bit applications are now available.
Regards,
Jean

[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

[Jean Penné]

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

[Jean Penné]

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

[stream]

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:

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:

1. 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.
2. 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

[paulunderwood]

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?

[Batalov]

They always were.

[paulunderwood]

Thanks for the info

[rogue]

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.

[pepi37]

Just cosmetic change: can somebody add to windows version that prime is highlighted ( like in linux version) in next release.

[Jean Penné]

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