mersenneforum.org Reserved for MF - Sequence 4788
 Register FAQ Search Today's Posts Mark Forums Read

 2021-08-13, 15:26 #2993 VBCurtis     "Curtis" Feb 2005 Riverside, CA 3·1,667 Posts I'm using nrkeep of 24 for my small experiments. I ran 1260 to 5e4 with nq = 6^6 and incr 210, took a few hours. Root-opt wasn't timed but was maybe 25% of the size-opt step. Edit: poly score was 2.45e-16; I think 3.0+ are worth reporting, and we'd like 3.5 or better. Next I ran 5e4 to 35e4 with the same params. That's about 36hr on 30 threads for size-opt (of a dual-10-core Ivy Bridge, with the other 10 threads solving an msieve matrix). Finally, 35e4 to 1e6 is running on nq = 6^5 but sizeopteffort=2. Done tonight on a different machine, I'll see if that flag had much effect. My next reservation will use incr 420 and nq = 6^6, and probably not use sizeopteffort. EDIT2: adrange should be an even multiple of incr; I use 4 * incr, as that guarantees each thread in a process two coefficients to process per workunit. If you use a round number such as 1e4 instead, workunits will vary in length which isn't a big deal but is maybe a tiny bit less efficient (when a workunit has an odd number of multiples of incr, it will run single-threaded for quite a while). Last fiddled with by VBCurtis on 2021-08-13 at 15:34
2021-08-13, 18:33   #2994
charybdis

Apr 2020

2·251 Posts

Quote:
 Originally Posted by VBCurtis Root-opt wasn't timed but was maybe 25% of the size-opt step.
Nitpicking a bit, but the sizeopt step is only a small part of what the polyselect binary does. Most of the time is just spent searching for polynomials, and size optimization (the bit that's controlled by sopteffort) only takes a short time. You can see this by looking at the output files from polyselect, which end with something like

Code:
# Stat: total phase took 1115.95s
# Stat: size-optimization took 37.47s
...and this is from a c182 GNFS, *after* setting sopteffort=10!

I haven't done any testing to see what's actually best, but sizeopt takes proportionally less time for larger numbers (at least while we're still using degree 5) so it may make sense to increase it for bigger jobs.

 2021-08-13, 21:32 #2995 VBCurtis     "Curtis" Feb 2005 Riverside, CA 138916 Posts You know, I've only played with sizeopteffort on degree 6 jobs, and it seems on those jobs it takes proportionally longer than on deg 5 jobs- so I thought it was controlling effort on that entire first step. My time with msieve reminds me of the *three* phases of poly select, and my failure to consider that CADO combines phases 1 and 2 together into the first step. So, nq is a sort of search depth per coefficient for finding candidate polys, while size-optimizing (and sizeopteffort) is to "polish" those found polys. Thanks for the correction and amplification!
2021-08-14, 01:01   #2996
swellman

Jun 2012

1100100000112 Posts

Quote:
 Originally Posted by VBCurtis I'm using nrkeep of 24 for my small experiments. I ran 1260 to 5e4 with nq = 6^6 and incr 210, took a few hours. Root-opt wasn't timed but was maybe 25% of the size-opt step. Edit: poly score was 2.45e-16; I think 3.0+ are worth reporting, and we'd like 3.5 or better.
For a GNFS 220, msieve is looking for an e-score between 2.98e-16 and 3.42e-16+, regardless of poly degree(?). Not sure how many data points they used to establish these guidelines or if it was based on extrapolation.

Cooperstown lists 3.36e-16 to 3.884e-16 for a G-220 poly with degree 6.

My feeling is polys with e-scores of >3.0e-16 are worth reporting as VBCurtis suggests - spin may ultimately help a bit too. 3.9+ is a hard stop, however unlikely it may be.

ETA: I am ignoring degree 5 polys for a composite of this size. Also ignoring msieve-GPU for this effort - just too big a job unless one uses advanced techniques like Gimarel.

Last fiddled with by swellman on 2021-08-14 at 01:17

2021-08-14, 03:26   #2997
VBCurtis

"Curtis"
Feb 2005
Riverside, CA

3·1,667 Posts

Quote:
 Originally Posted by VBCurtis Finally, 35e4 to 1e6 is running on nq = 6^5 but sizeopteffort=2. Done tonight on a different machine, I'll see if that flag had much effect.
1.44M thread-seconds for stage 1, 20k thread-seconds for root-opt of top 24 polys. Best poly was 13% better than my first run, using CADO's score:
# MurphyE (Bf=1.718e+10,Bg=1.718e+10,area=3.221e+17) = 1.179e-09

So maybe a 2.8, I'm too lazy to cownoise it. Stage 1 E-score was 54.64 for 24th place.

I'll leave 1e6-2e6 for bur; taking 2e6-5e6 with nq=46656 and incr=420. EDIT: I'm using P=12e6 so far, haven't tried any other settings.

Last fiddled with by VBCurtis on 2021-08-14 at 03:30

 2021-08-14, 09:25 #2998 bur     Aug 2020 79*6581e-4;3*2539e-3 2·3·67 Posts Here are test results for nq=46656 vs nq=7776 Other settings: Code: tasks.polyselect.P = 10000000 tasks.polyselect.admin = 1000000 tasks.polyselect.admax = 1016800 tasks.polyselect.adrange = 1680 tasks.polyselect.incr = 420 tasks.polyselect.nrkeep = 24 tasks.polyselect.sopteffort = 0 tasks.polyselect.ropteffort = 50 nq=46656 Code: (size optimized): raw lognorm (nr/min/av/max/std): 3524/66.240/77.238/78.270/1.005 (size optimized): optimized lognorm (nr/min/av/max/std): 3273/61.250/65.599/68.080/0.904 (size optimized): Total time: 51126.6 (root optimized): Total time: 13715 (root optimized): Rootsieve time: 13714.8 # MurphyE (Bf=3.436e+10,Bg=1.718e+10,area=8.590e+17) = 1.401e-09 cownoise: 2.63300493e-16 nq=7776 Code: (size optimized): raw lognorm (nr/min/av/max/std): 617/73.240/77.332/78.260/0.891 (size optimized): optimized lognorm (nr/min/av/max/std): 541/61.510/65.602/68.080/1.095 (size optimized): Total time: 8491.2 (root optimized): Total time: 13530.4 (root optimized): Rootsieve time: 13530.2 # MurphyE (Bf=3.436e+10,Bg=1.718e+10,area=8.590e+17) = 1.160e-09 cownoise: 2.02216808e-16 That's an almost 25% larger e-score for a 6-fold increase in time. I don't know if this was just coincidence, but it agrees with Gimarel's results (though I am not sure what they specifically mean tbh). If my settings are generally sound, then I'll start a search for the full 1e6-2e6 range with nq=46656. I noticed default cado has P=10e6, while vbcurtis wrote he used 12e6. Should I keep it consistent or doesn't it matter? Last fiddled with by bur on 2021-08-14 at 09:28
2021-08-14, 14:12   #2999
VBCurtis

"Curtis"
Feb 2005
Riverside, CA

3·1,667 Posts

Quote:
 Originally Posted by bur If my settings are generally sound, then I'll start a search for the full 1e6-2e6 range with nq=46656. I noticed default cado has P=10e6, while vbcurtis wrote he used 12e6. Should I keep it consistent or doesn't it matter?
It may matter, and we don't know which is better, so may as well stick with what you've been running.

 2021-08-14, 15:45 #3000 bur     Aug 2020 79*6581e-4;3*2539e-3 19216 Posts Ok, I did that. ETA for size opt of 1e6 - 2e6 is Aug 18th. I couldn't find the file where the priority polymers are written to, any idea where that is? Or isn't it a single file?
 2021-08-14, 16:25 #3001 swellman     Jun 2012 320310 Posts What about wutimeout, which my notes say is required for deg 6 rootsieve? Factory value for a C220 is 24000. Is it still required? I presume it’s a deadman timer to eventually move past bad polys that don’t play nice with CADO(?) I am planning to search in the higher ranges, starting at 40-41M, with P=10M, nq=46656, incr=4620 and adrange=18480, with a ropteffort value of 100, strike that it’s 35. nrkeep is 100. sopteffort=10 just because. Planning to start on Monday. Last fiddled with by swellman on 2021-08-14 at 16:50
 2021-08-14, 17:20 #3002 bur     Aug 2020 79*6581e-4;3*2539e-3 2·3·67 Posts I think wutimeout is how long cado waits for an individual slave to return a result. If exceeded it's canceled.
2021-08-14, 17:48   #3003
charybdis

Apr 2020

2·251 Posts

Quote:
 Originally Posted by bur I couldn't find the file where the priority polymers are written to, any idea where that is? Or isn't it a single file?
The priority queue is kept in the sqlite3 database (the .db file) rather than a separate file. You could also find high scoring polys by running a grep command in the .upload directory.

The default for wutimeout is 10800, or 3 hours. From the looks of it, individual rootopt tasks are finishing much more quickly than that, so I doubt it needs changing, but there shouldn't be any problem setting it to a higher value unless your clients have a tendency to go down without taking the server with them.

I'll probably join in with the search towards the end of next week.

Last fiddled with by charybdis on 2021-08-14 at 17:49

 Similar Threads Thread Thread Starter Forum Replies Last Post kar_bon Aliquot Sequences 136 2021-10-21 16:17 RichD Aliquot Sequences 476 2021-10-04 20:47 RichD Aliquot Sequences 524 2021-09-06 21:00 prism019 GPU to 72 6 2020-09-21 22:11 petrw1 Lone Mersenne Hunters 82 2010-01-11 01:57

All times are UTC. The time now is 19:29.

Sun Oct 24 19:29:59 UTC 2021 up 93 days, 13:58, 1 user, load averages: 1.65, 1.64, 1.41