Can I reduce the number of cores in a running computatiuon?

[drkirkby]

I'm new to GIMPS today, so know very little about it.

I set mptime up on my Dell 7920 workstation, which is running CentOS 7 Linux. The Dell 7920 workstation is capable of very high performance (2 x 28 = 56 cores, 24 x 128 GB = 3 TB RAM, about a dozen disks etc), but mine is configured much more modestly, with a single Intel Xeon Silver 4110, which is 8-core 2.2 GHz CPU and currently a single 32 GB RDIMM. A 64-GB LRDIMM is on oder. I intend updating the CPU and RAM as soon as funds permit.

I've set mprime running using all 8-ccores, but the machine does feel noticeably slower, so I'd like to limit the number of cores used by mprime to 6 or 7, rather than all 8. Is this possible to do?

I'm currently testing 2^110068781 -1, which is estimated to take 16 days.

Can I either

a) Reduce the number of cores currently be used to 6?

b) If that's not possible, at least start the next test, in about 16 days, on less than 8-cores?

I intend upgrading the CPU soon, but it may or may not have more than 8 cores. There may be some advantages to me for real work, in going to a CPU with a higher clock speed, but less cores.

[VBCurtis]

Yes- you can tell mprime to use fewer cores. Just stop the current worker, change settings for your preferences, and start worker.

As for making your workstation feel snappier, you really ought to have 4 matching (same size) sticks of RAM. Memory access on that board/CPU is designed with 4 channels, but you only have one stick so only one channel used.

It's a bit like having an 8-lane bridge (CPU) with only 1 lane on the road to the bridge; it's not quite that simple because some calculations use data that's already stored on the CPU package (cache), so the memory restriction doesn't always hurt you.

In short, buy 3 more 32GB sticks rather than worry about the CPU in the short term.

[drkirkby]

How do I stop the current worker? Once stopped, how do I configure it to use less cores?

I take your point about the RAM. I intend removing the 32 GB RDIMM in the next few days, and replacing it with a 64 GB LRDIMM I have on order. I will eventually get at least another 3 LRDIMMs, but they are pretty damm expensive. Just over £300 each ($405). Four 64 GB LRDIMMs will have cost more than what I paid for the workstation, which was $1100 (£1100 with carriage and 20% TAX). It came with 2 x 8 GB sticks of RAM.

I will concentrate finances on the RAM before worrying about the CPU.

Dave.

[Prime95]

Welcome to GIMPS!

Ctrl-C or menu choice 4 will stop the current test.

Menu choice 2 "Test/Workers" will let you change #cores.

Just in case: ./mprime -m runs mprime with menus.

[drkirkby]

Originally Posted by VBCurtis

As for making your workstation feel snappier, you really ought to have 4 matching (same size) sticks of RAM. Memory access on that board/CPU is designed with 4 channels, but you only have one stick so only one channel used.

It's a bit like having an 8-lane bridge (CPU) with only 1 lane on the road to the bridge; it's not quite that simple because some calculations use data that's already stored on the CPU package (cache), so the memory restriction doesn't always hurt you.

In short, buy 3 more 32GB sticks rather than worry about the CPU in the short term.

I am really glad that you pointed this out.

I run the Passmark computer benchmark the other day and found that the machine was weakest on the memory compared to other users who had submitted their results. After I had installed a middle of the range Nvidia Quadro P2200 graphics card, the results were

Disk 60th percentile
CPU 57th percentile
3D graphics 37th percentile
2D graphics 33rd percentile
Memory 28th percentile

(Prior to changing the supplied poor graphics card, that was the weakest point)

I was aware that the CPU is clocking the RAM at 2400 MHz, whereas a better CPU would charge it to 2993 MHz, but that’s not a massive difference.

I am guessing that adding a second 64 GB LRDIMM would be a significant benefit, given I can’t afford to add 3 more just now.

[drkirkby]

I'm letting mprime use 26 cores at the minute, to attempt a LL test on M332311079 - something someone else tried in 2016 and gave up.



https://www.mersenne.org/report_expo...2311079&full=1


The problem is, something I feel the 26 cores is putting too much load on my machine, and I'd like to reduce that number for a while - perhaps give it 10 cores instead. Is there any way to do this? If so, how?

[Uncwilly]

Did you check the documentation? Isn't there a "man" file or a readme?
Maybe check out this thread:
https://www.mersenneforum.org/showth...=568938&nojs=1

[kriesel]

Originally Posted by drkirkby

I'm letting mprime use 26 cores at the minute, to attempt a LL test on M332311079 - something someone else tried in 2016 and gave up.

https://www.mersenne.org/report_expo...2311079&full=1

The problem is, something I feel the 26 cores is putting too much load on my machine, and I'd like to reduce that number for a while - perhaps give it 10 cores instead. Is there any way to do this? If so, how?

First: Why LL, not PRP?
Please stop running first LL tests immediately. Switch to PRP with GEC and ideally proof generation for all first primality tests as much as practical. Configure for a reasonable amount of disk space to allow at least power 7 proof generation if not higher.

From the v30.3b6 mprime whatsnew.txt file:

New features in Version 30.1/30.2/30.3 of mprime
------------------------------------------------

1) PRP proofs.  This allows GIMPS to double-check a PRP test at less than 1% of the cost of a full PRP test!
   PRP proofs require lots of temporary disk space.  See readme.txt for details.
   PRP proofs require uploading a large proof file.  See readme.txt for details.
   PRP proof verifications require downloading a modest verification file.  See readme.txt for details.
2) Proofs automatically uploaded to server in 30.2.
3) First time LL, World-record LL, 100M-digit LL work preference is deprecated.
4) New resource limits menu choice.  Consult readme.txt before making changes to these settings.
   Some options previously in Test/Worker Windows and Options/CPU are moved to the resources menu choice.
5) LL-DC and PRP-DC combined into a single work preference.
6) Warning raised if temporary disk space is less than 1.5GB -- you may not get first time prime tests.
7) Thanks to Mihai Preda, the P-1 probability calculator has been improved.  This change results in a
    lower optimal B1 value and higher optimal B2 value.

The Jacobi check used on LL has a 50% chance of detection of certain errors. The GEC detection rate is nearly 100% on PRP. The program can only retreat a bit and try again for errors it detects. Odds of successful completion of an LL test are therefore lower than of a PRP test on the same hardware and exponent. LL tests completed often wait 8 years for a double-check. PRP with proof generation typically get verification certs completed within hours or occasionally days or weeks. All who can run PRP on 100M exponent value or above, much less 100MDigit or above, should run PRP, NOT LL, for first tests.

See also https://www.mersenneforum.org/showth...345#post523345,
https://www.mersenneforum.org/showpo...35&postcount=1, or the first section of https://www.mersenne.org/

The readme.txt that comes with mprime says:

    PRP - PRobable Prime test (this is how we find new Mersenne primes)
    LL - Lucas-Lehmer test (this is how we used to find new primes)
    DC - Double-Checking (LL tests must be double-checked with a second LL test)

Second, do you plan to adequately P-1 factor that exponent first? (Please do. Or someone like Viliam Furik or I could before you spend cpu-core-years on PRP on it.
See https://www.mersenne.ca/exponent/332311079)


Third, may as well use the latest, v30.4b9. It has improvements in P-1 and ECM beyond v30.3b6.


Fourth, relating to the OP question, the readme.txt included in the mprime.tar.gz file says:

In Linux, FreeBSD, Mac OS X command line version, cd to the directory and type "./mprime -m".

and has a section titled INSTRUCTIONS FOR THE AUTOMATIC METHOD. I suggest look for the number-of-cores-per-worker control in the same menu as the number-of-workers.


Fifth, are those 26 cores in more than one socket? The communication path between sockets can be a bottleneck. Why was 26 chosen? Have you benchmarked the fft length being used for different core counts per worker? Is the system thought to be highly reliable as a result of turning in many correct LL DC and no bad ones? Including some large-exponent LL DC?