mersenneforum.org PRP tests on known composite numbers
 Register FAQ Search Today's Posts Mark Forums Read

 2021-02-23, 08:08 #1 drkirkby   "David Kirkby" Jan 2021 Althorne, Essex, UK 11000112 Posts PRP tests on known composite numbers I don’t know what I done wrong while running mprime -m, but I inadvertently succeeded in getting myself about 18 assignments I did not want. They were in the range and type (PRP) tests I wanted, but about a third of them are known to be composite. https://www.mersenne.org/report_expo...0829939&full=1 https://www.mersenne.org/report_expo...0829407&full=1 https://www.mersenne.org/report_expo...0829473&full=1 https://www.mersenne.org/report_expo...0829521&full=1 https://www.mersenne.org/report_expo...0829669&full=1 https://www.mersenne.org/report_expo...0829717&full=1 Is this a bug, or intensional behaviour?
 2021-02-23, 09:15 #2 LaurV Romulan Interpreter     Jun 2011 Thailand 9,371 Posts Those are PRP-CF and PRP-CF-DC assignments. You are testing if the cofactor (i.e. what remains after the mersenne number is divided by known factors) is (probable) prime or not. If you are not particularly picky about the job you want to do, I suggest to let them run. They will finish very fast in an average computer (pay attention to the exponents, it may be confusing, because they start with 108, but they are 10 times smaller than we test now for primality at the PRP front edge, they are on 10.8M, and not 108M. These ranges were tested 20 years ago, and when you say "they are the range I wanted", you should be aware that there are NO mersenne primes in that range - this question was answered negative 20 years ago). Last fiddled with by LaurV on 2021-02-23 at 09:17
 2021-02-23, 09:16 #3 kruoli     "Oliver" Sep 2017 Porta Westfalica, DE 22×32×13 Posts The exponents you have listed are all of a special work type: PRP-CF. This differs from "normal" PRP such that you will execute a PRP test on the co-factor of a known composite Mersenne number with known factor(s). Probably, that's not what you wanted, but from our project point of view, this is working as expected. Please make sure your selected work type is not PRP-CF if you do not want to do it. The advantage of PRP-CF is that they will be done quickly and uses less disk space. The disadvantage is: It will not scale as nicely on your high core machine, if you run only one worker. Edit: Sorry for the crosspost. Somebody else has faster fingers than me. Last fiddled with by kruoli on 2021-02-23 at 09:17 Reason: Sorry for the crosspost.
 2021-02-23, 11:30 #4 drkirkby   "David Kirkby" Jan 2021 Althorne, Essex, UK 11000112 Posts Thank you both of you. I see the problem. I'd set my preferences to 160 160 - First time PRP on Mersenne cofactors instead of the 150 - First time prime tests which I intended. I must have mis-typed a 6 instead of a 5 - the keys are next to each other! The assignments at https://www.mersenne.org/workload/ just indicate PRP, not PRF-CF or PRP-CF-DC . I removed a few characters from this line, as as admin edited some post of mine to remove it, so I have done likewise. PRP=,1,2,10829717,-1,99,0,3,1,"86637737,23478826457,1919090830703" Anyway, if these are not going to take long, and are useful to someone, I will let them run. This computer is running far from optimally at the moment, as it only has two sticks of RAM, not the multiple of 4 it should have. Dave Last fiddled with by axn on 2021-02-23 at 13:42 Reason: AID redacted
 2021-02-23, 11:58 #5 kriesel     "TF79LL86GIMPS96gpu17" Mar 2017 US midwest 10011101000012 Posts "Do not post assignment IDs for current assignments, or 64-bit residues for results not yet verified, or MD5 hashes for proof files." (It's not good to post on a worldwide-readable web site, data that are supposed to be secrets shared only between you, your computer, and the PrimeNet server and perhaps its administrators.) Standard practice is to replace an assignment AID with the text (AID) or (AID redacted); to replace the rightmost two digits of an unverified res64 with __, to replace an MD5 hash with something like the text (hash). https://www.mersenneforum.org/showpo...64&postcount=2 Worktodo formats https://www.mersenneforum.org/showpo...8&postcount=22 Result formats https://www.mersenneforum.org/showpo...9&postcount=28 A moderator may alter your post to reduce the information leak after the fact. Last fiddled with by kriesel on 2021-02-23 at 12:06
 2021-02-23, 12:11 #6 firejuggler     Apr 2010 Over the rainbow 43×59 Posts Those prp-dc take me about 2H on three core I7-8700, about 3.3to 3.4 GhZ-day
2021-02-25, 01:21   #7
drkirkby

"David Kirkby"
Jan 2021
Althorne, Essex, UK

6316 Posts

Quote:
 Originally Posted by kruoli Probably, that's not what you wanted, but from our project point of view, this is working as expected. Please make sure your selected work type is not PRP-CF if you do not want to do it. The advantage of PRP-CF is that they will be done quickly and uses less disk space. The disadvantage is: It will not scale as nicely on your high core machine, if you run only one worker..
Yes, I noticed the cores were not doing much work. I thought they were going to be fairly quick so did not bother setting up more workers. The test was actually using about 40% of the computers resources. I let two finish, but decided to abandon the rest. The CPU in this machine is pretty slow. So the machine does not work too well unless all its cores are in use.

Would more workers, each using less cores, result in more memory access? I really want to avoid that as much as possible at the minute. I'm very aware the memory in my machine is not configured optimally - there are two DIMMs, but they should be installed in groups of 4. Unfortunately, I'm having problems getting hold of the right DIMMs.

 2021-02-25, 10:21 #8 kruoli     "Oliver" Sep 2017 Porta Westfalica, DE 22×32×13 Posts You should run the throughput benchmark. That will tell you about the optimal settings for your current setup. You could also benchmark different FFT sizes (e.g. one for the PRP wavefront, one for LL-DC wavefront, one for the PRP-CF wavefront) to see what is the most efficient for your machine. Rule of thumb: The larger the exponent (and by that larger FFT), the fewer workers is optimal. Having a single worker across two physical CPUs is never good, but if I recall correctly, you have only one CPU installed. If you are unsure about what to do I'd suggest executing the following and reporting the results here (I myself are not sure on how to use 26 cores optimally since this is 2 * 13; the benchmark below will use 24 cores): Code: \$ ./mprime -m ... Your choice: 17 Benchmark type (0 = Throughput, 1 = FFT timings, 2 = Trial factoring) (0): 0 FFTs to benchmark Minimum FFT size (in K) (2048): 512 Maximum FFT size (in K) (8192): 6400 Benchmark with round-off checking enabled (N): N Benchmark all-complex FFTs (for LLR,PFGW,PRP users) (N): N Limit FFT sizes (mimic older benchmarking code) (N): N CPU cores to benchmark Number of CPU cores (comma separated list of ranges) (26): 24 Benchmark hyperthreading (Y): Y Throughput benchmark options Benchmark all FFT implementations to find best one for your machine (N): N Number of workers (comma separated list of ranges) (1,2,4): 1,2,3,4,6,8,12,24 Time to run each benchmark (in seconds) (15): 30 Accept the answers above? (Y): Y That will take some time. Make sure that no other processes cause load during that process. When I ran the above on an eight core machine, the line Number of workers (comma separated list of ranges) (1,2,4): did not show up after I entered that he should test 24 cores since that would be nonsensical for my system. So please make sure that line appears, it will test a lot of combinations on your system.

 Similar Threads Thread Thread Starter Forum Replies Last Post Viliam Furik Number Theory Discussion Group 22 2020-12-08 14:45 sweety439 sweety439 4 2020-02-15 07:55 baih Factoring 16 2019-09-29 15:48 jshort Factoring 9 2019-04-09 16:34 philmoore Factoring 21 2004-11-18 20:00

All times are UTC. The time now is 13:42.

Sat Apr 17 13:42:40 UTC 2021 up 9 days, 8:23, 0 users, load averages: 1.60, 1.68, 1.80