![]() |
![]() |
#1 |
"Curtis"
Feb 2005
Riverside, CA
4,673 Posts |
![]()
The relevant record scores are from a C216 (3,766+):
Deg 6 4.66e-16 Deg 5 3.61e-16 Using the usual "1 digit is 15%" rule of thumb, a deg 6 score of 4e-16 is possibly good enough to use for the factorization, likewise something over 3.1e-16 for deg 5. I expect CADO's poly select in deg 6 to have an easier time setting such a record than msieve's deg 5, and I believe CADO >> msieve for deg 6 searches currently. As always, post your reservations here! Reserving CADO deg 6 4200 to 400k with nq = 46656 and incr = 210. |
![]() |
![]() |
#2 |
Sep 2008
Kansas
22×32×7×13 Posts |
![]()
Is it possible to setup a polyselect server? Might get more people to contribute.
|
![]() |
![]() |
#3 |
"Curtis"
Feb 2005
Riverside, CA
4,673 Posts |
![]()
I don't have a public-facing machine for CADO presently; I'm on winter break from school, though I suppose I could head to campus to adjust connections and configurations.
I need a couple trials on poly select params before I'd bother with a group effort anyway; maybe in a week or so I could have something set up. In the meantime, my first 3M thread-sec on CADO produced: Code:
skew: 3631171.462 c0: -103220456173951037642079956867090542810700338000 c1: -18535032273910066670092638781455152940780 c2: 94238827588202654144043099738383124 c3: -13243543462937303918281188995 c4: -8572476993744421137857 c5: 236432891435768 c6: 2088240 Y0: -140092283048428812607002686772711843 Y1: 1087402352458110598938121111 # MurphyE (Bf=3.436e+10,Bg=1.718e+10,area=2.147e+16) = 1.073e-08 ![]() The current CADO git now saves the best 15 polys to individual files! The top scoring one was 7% better than #2 according to CADO's score. Here is #2: Code:
skew: 1084707.215 c0: 87195291152770812378337092082653153342545664 c1: -2640270365420005034047822153246712699296 c2: -13599612443255728863299577941084002 c3: 1782144334403094596253622441 c4: 13437582792511043374318 c5: -2600097158176650 c6: -79896600 Y0: -147363113018984583605698621219842357 Y1: 7248193407388299119464733 These results are a bit surprising. EDIT: Round 2 on CADO, taking 400k to 2M with incr = 420, P =12M, nq still 46656. I used P = 10M on the first run. Last fiddled with by VBCurtis on 2019-12-17 at 09:00 |
![]() |
![]() |
#4 |
"Ben"
Feb 2007
3,371 Posts |
![]()
Can someone walk me through how to best contribute to this using GPU msieve? I don't want to duplicate work and want to make the best use of my card and don't really know how to do either of those things. I seem to remember there being some fiddleiness in parameters for numbers this large for the various stages...
|
![]() |
![]() |
#5 |
Apr 2010
2·79 Posts |
![]()
I'm running GPU msieve deg5 for lc >100M and multiple of 120120.
I think that you need to use the CADO sopt for the size optimesation otherwise you're wasting a lot of stage 1 hits. I use stage 1 norm 6.4e31, but this depends on the lc. I'm not sure about the best stage 2 norm for the rootsieve, currently I use 3e29. I've an early hit: Code:
# norm 1.920175e-21 alpha -7.994201 e 2.901123e-16 rroots 3 skew: 272935816.97 c0: 1321311258050449254377307946997271755577294308703300 c1: 157024216494039455486973705902559780606936 c2: -283396893153422376141361447582125475 c3: 1015270589114307318053354579 c4: 5150088772251546860 c5: 200119920 Y0: -502748738495685686303209158930950892406421 Y1: 448393380165327916747 |
![]() |
![]() |
#6 | |
"Curtis"
Feb 2005
Riverside, CA
4,673 Posts |
![]() Quote:
Pick your c5 range, enter it on the command line with no flags for norms. Cancel the job after a few seconds, see what default stage1 and stage2 norms are. For my slow 750ti, I divide stage1 norm by 9 or 10 and divide stage 2 norm by 30 or 35; faster cards might choose to restrict output a bit more tightly. I aim to restrict output enough such that stage 1 (the part that makes all the screen output, flagged as -np1) yields 3-10 hits per second, and stage 2 (the part that writes a size-optimized hit to disk, also known as -nps) yields 50 to 100 hits a day. Once every day or two, I kill msieve to run -npr (root-opt) on the file of 100-300 hits. This takes a couple hours. For really large inputs like this one on degree 5, small c5 values will produce skews larger than we want. I'd start at 40 or 50 million for c5, but others will likely choose 10 or 20 million (I am not generally the one who searches the smallest c5 values). If you choose to run deg 6 msieve, I'm afraid I don't have reliable advice for restricting output to ~5-10 hits/sec and 50-100 nps hits/day. C217 is likely to be in the range where deg 6 is better, but that is not guaranteed so deg 5 searches are helpful. |
|
![]() |
![]() |
#7 |
Jun 2012
32·7·47 Posts |
![]()
A few thoughts on this enormous poly search:
- CADO seems to give much better results for larger jobs, e.g. > c200 - This problem screams out for a sextic, though perhaps a quintic could work - I do not have a way of consistently generating sextics using msieve-GPU - I have developed a consistent methodology for generating quintics with msieve-GPU for up to say c185, but these methods don’t seem to scale well to jobs like this one - Don’t bother reporting any result with skews over 3e8 (max). Might have a decent e-score but likely terrible sieving performance. - I usually search 1 < c5 < n, where n is 5M to ~20M depending on GNFS difficulty but this search strategy doesn’t work for these size composites. As VBCurtis mentioned, low c5 values will likely generate high skews (see above). Gimarel just got a notable hit with c5~200M! All IMHO of course. I’m playing with CADO now, and I’m going to wrestle with generating sextics using msieve-GPU again next week. |
![]() |
![]() |
#8 |
"Ben"
Feb 2007
3,371 Posts |
![]()
I will see if I can get anything done with quintics. At the moment having trouble getting the card to run at all (I was using this project as motivation to finally get it to work), with the same issue as here. After editing the gpu_sm.props sheet and hacking the code to attempt loading of the resulting stage1_core_sm75.ptx file, I can get past the error and the card appears to start. But after a few seconds it hangs and I have to kill the powershell window. I have no more ideas past that.
|
![]() |
![]() |
#9 |
"Curtis"
Feb 2005
Riverside, CA
4,673 Posts |
![]()
Behold:
Code:
skew: 2382635.076 c0: 3987095627700723668556412616355906815127705992 c1: 10621479627429548899812810235604051573030 c2: -4682349569391313556729607478081235 c3: -18433207794474459950952563135 c4: 1015293418294354295928 c5: 1005061270114440 c6: -39916800 Y0: -110058966911042321282835020413351605 Y1: 14771789483157557668102843 # MurphyE (Bf=3.436e+10,Bg=1.718e+10,area=2.147e+16) = 1.201e-08 Second poly from this run: Code:
skew: 795472.597 c0: 7619329897958484267003311101205639257382400 c1: 972789506471289955182741591383079851052 c2: 7982747782724676457598194955195188 c3: -11632872254364925227187277187 c4: -16770915348493964743837 c5: 4545814836283056 c6: 430133760 Y0: -139963034380019911364058910747595047 Y1: 24194513859610490327764807 # MurphyE (Bf=3.436e+10,Bg=1.718e+10,area=2.147e+16) = 1.023e-08 Approx. 8.2M thread-seconds for this second run, 11M total. The score from the first poly in this post is about the expected record score for a C215, if we use previous records and extrapolate from C210-211-212 records. However, the more recent CADO-team records for RSA-210 (1.49e-15) and RSA-220 (3.88e-16) suggest something like 7.6e-16 for C215 is possible. So, maybe more like a record C216 poly- except this is a C217. Anyway, this is a good poly, and Max should see if any improvement is possible. I am pausing poly search for a bit, so that others might join in the fun. Anyone interested in a CADO run might choose: deg 6, nq = 46656, admin 2e6, incr 420, P = 12000000 to 14000000; admax is a matter of how many CPU-hours you wish to spend. Each 1M interval is roughly 5M hyper-thread-seconds (on 2.6ghz ivy bridge). Last fiddled with by VBCurtis on 2019-12-22 at 07:22 |
![]() |
![]() |
#10 | |
Jun 2012
56218 Posts |
![]() Quote:
|
|
![]() |
![]() |
#11 |
"Curtis"
Feb 2005
Riverside, CA
4,673 Posts |
![]()
I neglected to list adrange: this should be 2x or 4x incr, since poly select runs 2-threaded. That is, for incr = 420, using adrange = 840 gives one c6 value to each thread, while using adrange = 1680 gives two values to each thread per workunit. I've usually used 4x incr (=1680 here), figuring it reduces idle thread time a bit.
Also, ropteffort must be set. The root-opt phase is tiny compared to the main size-opt search; a value like 35 or 40 "should" be effectively "try as hard as you can". Number of polys to root-opt (nrkeep, I think, in param-speak) can be quite small for your 0.5M range, like 30 to 60. I think CADO defaults to like 200 for an entire search of this size, while I used 36 for each of my two runs. |
![]() |
![]() |
Thread Tools | |
![]() |
||||
Thread | Thread Starter | Forum | Replies | Last Post |
Poly select and planning for 2,2330M | VBCurtis | Cunningham Tables | 70 | 2021-02-16 06:32 |
Poly select and planning for 2,2210M | swellman | Cunningham Tables | 51 | 2020-03-22 22:09 |
Poly select and test-sieving for RSA232 | VBCurtis | Operation Kibibit | 25 | 2020-01-07 01:57 |
YAFU Poly Select Deadline | amphoria | YAFU | 22 | 2016-09-17 09:47 |
Starting NFS skipping poly select | jux | YAFU | 5 | 2016-01-02 01:01 |