Mlucas v19 available

[tdulcet]

Originally Posted by ewmayer

Ah, forgot to note - those incorrect reference residues for the huge-FFT self-test are low-priority, I've added them to my v20 to-do list.

OK, thanks.

Originally Posted by ewmayer

I plan to release 19.1 in next few days, first need to play with your recently-enhanced build&tune script so I can add suitable text about that to the README page. More feedback soon.

Great, I will look forward to that. I cannot seem to update my attachment on post #83, so I attached a version 3 of the new install script for Linux to this post with some minor fixes. It will now correctly generate the combinations of CPU cores/threads to test (step #1) on systems where the number of CPU cores is not a power of two (mainly VMs). It will also handle the case where the FFT lengths in each mlucas.cfg file from step #2 are not all the same, for example if one or more of the files is missing one or more FFT lengths. I am not sure if this case is possible without their being a bug in Mlucas, but the script should now handle it. Everything else from post #83 still applies, except the exit command to remove is now on line 400.

Originally Posted by ewmayer

-march=native is a good suggestion, alas it did not cure the illegal-instruction issue with that one .c file in my KNL build. However, it should allow me to simplify the manual-build instructions on the README page, for the same reason you note above. This is the first such GCC bug I've hit in my KNL builds of various Mlucas releases, so since very few people have a KNL and even fewer of them run Mlucas on it, one hopes this sort of issue continue to be a rare glitch over coming GCC releases.

With the new install script for Mlucas v19.1, users will be able to run export CC=clang before the script to build Mlucas with Clang instead of the default GCC, which would be another possible workaround, if anyone else has issues with GCC.

@ewmayer BTW, I just saw your thread over on the Linux forum from a couple years ago and I thought I should note that the install script will automatically create a script and cron job do that by default. Early versions of the script put the commands to run both Mlucas and the PrimeNet script entirely in a cron job, similar to what is described in that thread, but on systems with many CPU cores, the cron job was too long, so as of a few months ago, it will put the commands in a separate obj/Mlucas.sh script, which is then automatically run from the cron job. (The attached version is of course for testing and will not do this unless you remove the exit command as described in post #83.)

[ewmayer]

A ha ha, I'm such an idiot - let's again look at your example '-s h' self-test error message:

Originally Posted by tdulcet

Res mod 2^35 - 1 = 7270151463
Res mod 2^36 - 1 = 68679090081
*** Res35m1 Error ***
current = 7270151463
should be = 29128713056
*** Res36m1 Error ***
current = 68679090081
should be = 7270151463
--
Return with code ERR_INCORRECT_RES64
Error detected - this radix set will not be used.
WARNING: 0 of 10 radix-sets at FFT length 65536 K passed - skipping it. PLEASE CHECK YOUR BUILD OPTIONS.

Notice that the 'current' (= from self-test) Res35m1 value matches the 'should be' (= pretabulated reference value) Res36m1 one? Let's have a look at the pretabulated reference residues for this FFT length in Mlucas.c:

{ 65536,1166083297u, { {0xA0FE3066C834E360ull, 29128713056ull, 7270151463ull}, ...

65536K FFT, reference test exponent 1166083297, followed by 3 ref-residue triplets, corresponding to the test residue modulo 2^64 (low 64 bits of full residue = Res64, in hex), 2^35-1 and 2^36-1. The triplets are for -iters 100,1000,10000, I have copied only the 100-iter one above.

The residues modulo 2^35-1 and 2^36-1 are a.k.a. the Selfridge-Hurwitz residues, after the 2 worthies who used them for their Fermat-number primality-testing work in the 1960s, on mainframe hardware which supported a 36-bit integer type. They also included the residue modulo 2^36, but as that is just the low 36 bits of the GIMPS-used Res64, it's redundant. But until a couple years ago, Mlucas would print all 4 residues like so - let's again use the above case to illustrate, since we can trivially extract the Res36 from the Res64:

Res64: 0xA0FE3066C834E360
Res mod 2^36     = 29128713056
Res mod 2^35 - 1 = 7270151463
Res mod 2^36 - 1 = 68679090081

Now it's clear what must've happened - a few years back when I tabulated those '-s h' entries, I must've done all the needed runs, assembled the resulting 4-line entries as above, then batch-edited them. Should've deleted the Res mod 2^36 line and used the remaining 3, but must've instead kept the first 2 decimal residues and deleted the the mod 2^36 - 1 one in a bunch of cases.

The good news is that that makes it easy to see which tabulated entries are fubar in this manner - just extract the low 9 hexits of the Res64 for each triplet, print in decimal, see if that matches the first of the 2 following 36-bit decimal entries in the triplet, if so, it's fubar.

Per that, for the 100-iter triplets, all but last 3 need redo - but those 3, for FFT lengths 212992,229376,245760 - should be OK. Further, none of the 1000-iter reference triplets show the above 'whoops', so those should all be OK.

But I see I never got around to filling in the 10000-iter table entries for these large FFT lengths, so since the 100 and 1000-iter are pretty fast to recompute compared to those, gonna redo them all.