Quote:
Originally Posted by kriesel
"Serge Batalov also verified it using Ernst Mayer's MLucas software on two Intel Xeon 18core Amazon EC2 servers in 3.5 days." https://www.mersenne.org/primes/?press=M74207281
Not first and second half of iterations, but duplicate full runs?
I'd expect the nparallel approach to work well with prime95/mprime since it is very common.

Yes, Serge's (and more recently, Anders') dual verify runs at different FFT lengths were both endtoend.
Here is the current Mlucas file format:
o 1 byte for test type, numerically, i.e. 256 possible values, mapped to an internal table;
o 1 byte for modulus type, currently only Mersennes and Fermats supported;
o 8 bytes for iteration count of the residue stored in the file;
o ceiling(p/8) bytes for the residue R  i.e. maximally bytecompact, endianandFFTlengthofrunindependent;
o 8 bytes for Res64 = R (mod 2^64), which should match the leading 8 fullresidue bytes in the above bytewise form);
o 5 bytes for R (mod 2^351);
o 5 bytes for R (mod 2^361) [these last 2 a.k.a. the SelfridgeHurwitz residues, based on those guy's Fermatnumber work, using a 36bithardwareinteger machine; SH also used R (mod 2^36), but that is just the low 36 bits of GIMPS' Res64];
After reading R, I directly compute the two SH residues and compare to the above filestored checksums; this gives me an md5/sha1style integrity check of the whole residue R, which the Res64 does not.
For v18, I am adding several new fields:
o 3 bytes for FFTlengthinKdoubles which the code was using at time of savefile write. This is so that if the code switches to a largerthandefault FFT length midrun based on ROE behavior for the exponent in question, it will immediately resume using the larger FFT length on restartfrominterrupt, rather than resuming using the smaller default FFT length as the current release does.
o 8 bytes for circularshift to apply to the (unshifted) residue read from the file. I include the shiftcountatiterationofsavefilewrite because [a] the code will choose a random shift count at runstart time (i.e. since this is not specified by the Primenet server, it cannot be read from the worktodo file), and [b] it saves the need for taking an initialshift value s from the savefile and computing s * 2^iter (mod p). I remove the shift from R prior to the savefile write, so in fact there's really no need to store s to the file (i.e. I could resumefrominterrupt using an entirely different random shift value, applied to R after reading it from the savefile), but for aesthetic reasons I like the idea of doing the whole run based on a single initial value of s, rather than asmanyvaluesofsastherewereruninterrupts.