View Single Post
Old 2019-05-19, 17:11   #14
kriesel's Avatar
Mar 2017
US midwest

10011100110012 Posts
Default Why don't we self test the applications, immediately before starting each primality test?

Why don't we self test the applications, immediately before starting each primality test? For the same fft length about to be used for a primality test such as a current wavefront test, and any 100Mdigit exponent or higher? Perhaps also upon resumption of an exponent?

(part of this was first posted as
I think it would be a plus if future releases of primality testing software performed a brief self test before beginning each primality test, and if found unreliable, AT THAT TIME, refused to proceed with a primality test, instead providing the user with recommendations for improving reliability. Perhaps a fast small block of PRP/Gerbicz check, even if what's being run is LL; on the same exponent/fft length, to test more closely what's about to be run.
Hardware reliability changes with time and temperature and other factors. A self test of the same fft size checks that fft transforms and multiplications can be reliably done. If the self test was a couple of blocks of PRP/GC, it could be a useful small increment of a cat 4 PRP double check.

Users might find the checks annoying or regard them as lost throughput. Running LL on 100Mdigit exponents would be disincentivized, since it would involve working also on a 100Mdigit PRP DC so that there is an fft length match. One might as well run PRP for 100Mdigit exponents, and avoid the side self test or commitment to doing a 100Mdigit DC. Increasing adoption of PRP and reducing LL for 100Mdigit exponents is a good thing.

There are some application-specific or interface-specific reasons.
There is no GIMPS PRP code for CUDA or Gerbicz check code for CUDA.
There is no provision for self test of fft lengths larger than 8192K in CUDALucas.

Top of this reference thread:
Top of reference tree:

Last fiddled with by kriesel on 2020-02-20 at 19:34
kriesel is offline