Faster LL tests, less error checking?

[Prime95]

Would GIMPS be better off with LL tests that ran 2% faster but lost the error checking done every iteration?

Version 25 runs an imperfect error check every LL iteration. I've discovered a way to speed up version 26 by 1-2% (closer to 2%) but this error check is no longer cheap and easy.

Prime95 would still do the roundoff error check every 128th iteration.

Comments??

[axn]

Originally Posted by Prime95

Comments??

If the FFT-boundary tests get stricter checking, it may be worth it.

[Merfighters]

1. Yes, faster is better. : This is good for new computers.
2. No, faster LL isn't worth the lost error checking. : This is good for old computers, that has more errors.
3. Make it a user option. : It would be the best, so I voted this. How about checking the computer speed and errors to select the one that's best?
4. No opinion, instead reprogram the server to assign me the 48th Mersenne prime. : LOL, that's an awesome joke!

[only_human]

Originally Posted by Prime95

Would GIMPS be better off with LL tests that ran 2% faster but lost the error checking done every iteration?

Version 25 runs an imperfect error check every LL iteration. I've discovered a way to speed up version 26 by 1-2% (closer to 2%) but this error check is no longer cheap and easy.

Prime95 would still do the roundoff error check every 128th iteration.

Comments??

I was wondering if removing the imperfect iteration error check adds flexibility or freedom for more improvements later too.

Also what are the consequences? If errors got caught at the 128th iteration rounding check then it is just a minor delay of error detection for faster throughput -- but if it increases undetected errors that is a different consideration.

[S485122]

During ordinary LL tests, be they first or double-check, a balance should be made between speed an accuracy. At the moment there a bit more than 4 % bad results. A lot of them have no error code. Would the proportion of bad tests with no error code increase if you remove the error checking at each iteration ? What is the penalty in speed if you keep the "imperfect" error checking with the speedier test ? What penalty in speed would you have with a better error checking...

Since you have (one of) the fastest FFT routines is improving speed really necessary if reliability decreases ?

In view of the magnitude of the project I vote for reliability over speed...

I suppose that the error checking in the torture test would not be removed since it is of a different nature (checking the computed results versus known results ?

Jacob

[ATH]

I vote for more speed if there is still roundoff checking every 128th iteration.

Do you have any statistics how often that error check finds errors? Is that all the "Suspect LL"?

Any statistics on the server how often suspect LL turn out to be correct and how often its bad?

[ET_]

George, you have always found the right way to optimize "our" code, so I guess you have some ideas on the subject.

Is faster better? It depends on reliability, and you are the one who can evaluate how reliable the faster results would be.

BTW, you said

"Version 25 runs an imperfect error check every LL iteration"

That means that you spotted something needing correction. But then you added:

"I've discovered a way to speed up version 26 by 1-2% (closer to 2%) but this error check is no longer cheap and easy.

Prime95 would still do the roundoff error check every 128th iteration."

Are you going to leave in place only the roundoff check after every 128th iteration? Is that enough to recover a bad result? Only you can tell...

Or. even better, only stats geeks who can check error codes from the server can tell:

- How many "bad results" turned correct after a triple check?
- How many "bad results" are affected by the glitch in the check routine?
- How many of them would be trapped by the check on 128th iteration?
- What would be the impact on residual checking every n iterations?

Luigi

[retina]

The poll needs another option.

5. Just do whatever makes the project progress faster.

If a 2% speed-up can, on average, adequately compensate for some extra errors not being detected then just do it.

[Mini-Geek]

Originally Posted by ET_

BTW, you said

"Version 25 runs an imperfect error check every LL iteration"

That means that you spotted something needing correction. But then you added:

"I've discovered a way to speed up version 26 by 1-2% (closer to 2%) but this error check is no longer cheap and easy.

Prime95 would still do the roundoff error check every 128th iteration."

Are you going to leave in place only the roundoff check after every 128th iteration? Is that enough to recover a bad result? Only you can tell...

Or he meant that there was nothing needing correction, but the error check uses an algorithm that's "imperfect" in that it won't find all errors, but only some.

Originally Posted by retina

The poll needs another option.

5. Just do whatever makes the project progress faster.

If a 2% speed-up can, on average, adequately compensate for some extra errors not being detected then just do it.

Yes, I would vote for this.

[only_human]

Originally Posted by retina

The poll needs another option.

5. Just do whatever makes the project progress faster.

If a 2% speed-up can, on average, adequately compensate for some extra errors not being detected then just do it.

This is my choice too.

There is also the a purely emotional consideration too however that deserves a bit of consideration before moving on; since LL tests take a decent amount of time on a user's machine it might be a bit of a buzz-kill to be dwelling on the test not being as valid as possible even if overall statistics favored running running faster tests that are slightly less accurate.

Here is another thread that discussed LL error checking although it was mostly discussing the rounding test:
http://www.mersenneforum.org/showthr...679#post207679

The gist of the thread is that the nature of the errors and the steps taken with shifted residues make LL double checks very effective and false negative results virtually impossible.

ewmayer opines that regular PC hardware error rates are more likely than floating point rounding errors.

My last thought is that if the iteration test is not perfect and all the other tests are adequate, then the iteration test is not necessary.

I now quote jasonp's message in that thread:

Originally Posted by jasonp

The nature of the arithmetic used in the LL test is such that if one number out of millions is wrong in a given iteration, that error is propagated to the entire number in the next iteration. So if you even get one error in the course of an LL test, nothing beyond that point will be the same. So your hardware error would have to be in the same place at the same time to also fool a doublecheck run, which is sufficiently unlikely in a weeks-long test that nobody assumes it will happen.

The other danger in a long run like that is actual incorrect rounding, which would affect even perfectly working hardware. We use balanced representation, i.e. represent multiple-precision numbers as an array of positive or negative words. Multiplication results with this scheme are actually centered about zero on average, and the parameters chosen actually allow the possibility of a multiplication result not being able to fit in a 53-bit floating point mantissa. So if enough of the words in a multiple precision number had the same sign, the convolution would fail, even with no rounding error.

To combat this possibility, double check runs compute the Lucas-Lehmer test with the initial residue multiplied by a random power of two. This still allows the original residue to be recovered, but changes all the intermediate results used to compute it, and so a freakish roundoff error failure is not expected to repeat exactly. If instead the double check incurs its own freakish roundoff error, this is also okay; you can keep doing doublechecks until two runs with different initial shifts until you get a pair of them where freakish roundoff error does not occur.

So, bottom line, no archaeology on previous results is needed.

[Mini-Geek]

Originally Posted by only_human

There is also the a purely emotional consideration too however that deserves a bit of consideration before moving on; since LL tests take a decent amount of time on a user's machine it might be a bit of a buzz-kill to be dwelling on the test not being as valid as possible even if overall statistics favored running running faster tests that are slightly less accurate.

Hence there being the "No, faster LL isn't worth the lost error checking." and "Make it a user option." options. If you think it would be bad (bad for GIMPS through weaker interest due to an LL having a higher chance to go wrong through no fault of their own...or just you don't like it) to have LLs be that much more unstable, even if it helps the overall speed of the project, vote for one of those.