mersenneforum.org

mersenneforum.org (https://www.mersenneforum.org/index.php)
-   Mlucas (https://www.mersenneforum.org/forumdisplay.php?f=118)
-   -   Mlucas v19 available (https://www.mersenneforum.org/showthread.php?t=24990)

tdulcet 2020-05-20 12:40

Install Script for Linux
 
I wrote a script to download, setup, build and run Mlucas on Linux. It supports x86 Intel and AMD and ARM CPUs: [URL]https://github.com/tdulcet/Distributed-Computing-Scripts#mlucas[/URL]

If the required dependencies (Make and the GNU C compiler) are already installed, it should work on any Linux distribution. Otherwise, it will install the required dependencies on Ubuntu and Debian/Raspbian. Pull requests are welcome!

By creating a Makefile and using Make's jobs ([C]-j[/C]) feature with one job for each CPU thread, this script will build Mlucas significantly faster than if you manually ran the gcc commands in the [URL="https://www.mersenneforum.org/mayer/README.html#download"]Mlucas README[/URL]. For example, if your CPU has four CPU threads, it will build approximately four times faster. This script follows the recommended instructions on the Mlucas README for each architecture and CPU, which should provide the best performance for most users. It also saves the Makefile so users can easily change the gcc parameters and rerun [C]make[/C].

There is a log of the script running on Travis CI [URL="https://travis-ci.org/github/tdulcet/Distributed-Computing-Scripts/jobs/688790504"]here[/URL]. Note that there are over 20,000 lines of output, most of which are warnings from gcc. There are also separate scripts to download, setup and run [URL="https://www.mersenneforum.org/showthread.php?p=491112#post491112"]Prime95[/URL] and [URL="https://www.mersenneforum.org/showthread.php?p=490167#post490167"]CUDALucas[/URL] on Linux.

ewmayer 2020-05-21 19:02

@tdulcet - thanks for this! Yes, parallel-buildability is the one clear advantage automake has over my beloved command-line mode.

I think a good way to proceed is to let other Mlucas-building GIMPSers try your script out, if feedback is positive I'll be happy to add a link to it, along with suitable text and credit-to-you, on the README page. Sound good?

tdulcet 2020-05-22 02:00

@ewmayer Sounds great. Thanks! Feedback is always welcome.

ewmayer 2020-06-07 20:40

[QUOTE=tdulcet;546167]@ewmayer Sounds great. Thanks! Feedback is always welcome.[/QUOTE]

FYI, I added a note re. your script under "News" at the Mlucas readme page - hopefully that will encourage a few more people to try it out and provide feedback.

bayanne 2020-07-05 11:05

Curiosity has got the better of me.
Will the new ARM cpu being designed to run Mac OS11 be able to run Mlucas, or is it far too early to know ...

Thanks

ewmayer 2020-07-05 23:35

[QUOTE=bayanne;549813]Curiosity has got the better of me.
Will the new ARM cpu being designed to run Mac OS11 be able to run Mlucas, or is it far too early to know ...

Thanks[/QUOTE]

I intend to port my ARM inline-asm routines to the forthcoming "Apple cores", yes.

ewmayer 2020-07-08 23:36

1 Attachment(s)
Couple significant announcements, of the I-have-good-news-and-bad-news variety.

o First, the bad: I have found and fixed a pair of critical bugs affecting FFT lengths of form 3*2[sup]k[/sup]. This means current GIMPS double-checks at FFT length 3M (3072K) and recently-reached-by-the-GIMPS-first-time-test-wavefront 6M (6144K). The bug is specific to 256-bit SIMD builds, meaning x86 avx and avx2-targeting builds. Assuming a multithreaded build, only FFT radix sets of form 192,[powers of 2] are affected, but radix-192 is the most common leading radix appearing in the runtime-based mlucas.cfg tuning file for GIMPS-relevant FFT lengths of the above form, in my experience. ARM builds are not affected, but I rebuilt those binaries as a matter of course, to make sure my bugfix didn't inadvertently break anything there.

o Now the good news: Thanks to Loïc Le Loarer, we have a vastly improved version of the primenet.py assignment-management script for users to try out. This uses Primenet v5 API calls to do cool stuff like register one's computer and monitor progress of one's various runs across multiple devices, as shown in the attachment below.

Check out the Mlucas readme page for details and updated links!

kriesel 2020-07-09 03:41

[QUOTE=ewmayer;550081]I have found and fixed a pair of critical bugs affecting FFT lengths of form 3*2[sup]k[/sup]. This means current GIMPS double-checks at FFT length 3M (3072K) and recently-reached-by-the-GIMPS-first-time-test-wavefront 6M (6144K). The bug is specific to 256-bit SIMD builds, meaning x86 avx and avx2-targeting builds. Assuming a multithreaded build, only FFT radix sets of form 192,[powers of 2] are affected, but radix-192 is the most common leading radix appearing in the runtime-based mlucas.cfg tuning file for GIMPS-relevant FFT lengths of the above form, in my experience. ARM builds are not affected, but I rebuilt those binaries as a matter of course, to make sure my bugfix didn't inadvertently break anything there.[/QUOTE]
This raises some questions.
100Mdigit exponents use 18M ffts.
For example, complex FFT radices 36 16 16 32 32
which is 3[SUP]2[/SUP] 2[SUP]k[/SUP].
Are they affected too? Have they been checked for whether they're affected?
How many versions back do the relevant bugs go?
But it would not affect SSE2 builds, correct?

ewmayer 2020-07-09 05:29

[QUOTE=kriesel;550088]This raises some questions.
100Mdigit exponents use 18M ffts.
For example, complex FFT radices 36 16 16 32 32
which is 3[SUP]2[/SUP] 2[SUP]k[/SUP].
Are they affected too? Have they been checked for whether they're affected?
How many versions back do the relevant bugs go?
But it would not affect SSE2 builds, correct?[/QUOTE]

The patch-related notes on the readme detail all this - your example is FFT length 9*2^k, not the 3*2^k possibly affected by the bug. The bug is actually quite easy to look for based on certain key params in the carry-related sourcefiles, now that I know to double-check those prior to release.

Bug is only related to new code introduced in v19, and if your run at whatever FFT length and radices doesn't crash for expos < 98% the max permitted for the given FFT length (look for the p[ = ...]/pmax_rec on startup, it's unaffected by the bug.

henryzz 2020-07-09 11:59

Are any exponents potentially affected tested and double checked with mlucas?

tdulcet 2020-07-09 14:10

New PrimeNet script
 
[QUOTE=ewmayer;550081]Thanks to Loïc Le Loarer, we have a vastly improved version of the primenet.py assignment-management script for users to try out.[/QUOTE]

Thank you Loïc Le Loarer for creating this new PrimeNet script! I just updated my [URL="https://www.mersenneforum.org/showthread.php?p=545949#post545949"]Install Script for Linux[/URL] to use it. It will automatically set most of the [C]--register[/C] options with the computers system info.

[QUOTE=ewmayer;550081]I have found and fixed a pair of critical bugs affecting FFT lengths of form 3*2[sup]k[/sup].[/QUOTE]

@ewmayer I tried to download the new source tarballs, but I am getting the old MD5 checksums and not what is listed on the Mlucas README. I was going to update my scripts with the new checksums.


All times are UTC. The time now is 01:26.

Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2021, Jelsoft Enterprises Ltd.