20191215, 07:34  #1 
"Curtis"
Feb 2005
Riverside, CA
2^{4}·17^{2} Posts 
Poly select and CADO sieving for 2,1165+ C217
The relevant record scores are from a C216 (3,766+):
Deg 6 4.66e16 Deg 5 3.61e16 Using the usual "1 digit is 15%" rule of thumb, a deg 6 score of 4e16 is possibly good enough to use for the factorization, likewise something over 3.1e16 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. 
20191215, 15:46  #2 
Sep 2008
Kansas
7·463 Posts 
Is it possible to setup a polyselect server? Might get more people to contribute.

20191217, 08:50  #3 
"Curtis"
Feb 2005
Riverside, CA
2^{4}×17^{2} Posts 
I don't have a publicfacing 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 threadsec 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.073e08 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 20191217 at 09:00 
20191217, 16:13  #4 
"Ben"
Feb 2007
3,361 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...

20191217, 16:36  #5 
Apr 2010
3^{2}·17 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.920175e21 alpha 7.994201 e 2.901123e16 rroots 3 skew: 272935816.97 c0: 1321311258050449254377307946997271755577294308703300 c1: 157024216494039455486973705902559780606936 c2: 283396893153422376141361447582125475 c3: 1015270589114307318053354579 c4: 5150088772251546860 c5: 200119920 Y0: 502748738495685686303209158930950892406421 Y1: 448393380165327916747 
20191217, 17:11  #6  
"Curtis"
Feb 2005
Riverside, CA
2^{4}·17^{2} 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 310 hits per second, and stage 2 (the part that writes a sizeoptimized 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 (rootopt) on the file of 100300 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 ~510 hits/sec and 50100 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. 

20191217, 17:57  #7 
Jun 2012
B7F_{16} 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 msieveGPU  I have developed a consistent methodology for generating quintics with msieveGPU 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 escore 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 msieveGPU again next week. 
20191217, 20:13  #8 
"Ben"
Feb 2007
3,361 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.

20191222, 07:13  #9 
"Curtis"
Feb 2005
Riverside, CA
4624_{10} 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.201e08 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.023e08 Approx. 8.2M threadseconds 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 C210211212 records. However, the more recent CADOteam records for RSA210 (1.49e15) and RSA220 (3.88e16) suggest something like 7.6e16 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 CPUhours you wish to spend. Each 1M interval is roughly 5M hyperthreadseconds (on 2.6ghz ivy bridge). Last fiddled with by VBCurtis on 20191222 at 07:22 
20191222, 17:32  #10  
Jun 2012
5577_{8} Posts 
Quote:


20191222, 17:54  #11 
"Curtis"
Feb 2005
Riverside, CA
1210_{16} Posts 
I neglected to list adrange: this should be 2x or 4x incr, since poly select runs 2threaded. 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 rootopt phase is tiny compared to the main sizeopt search; a value like 35 or 40 "should" be effectively "try as hard as you can". Number of polys to rootopt (nrkeep, I think, in paramspeak) 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  
Similar Threads  
Thread  Thread Starter  Forum  Replies  Last Post 
Poly select and planning for 2,2330M  VBCurtis  Cunningham Tables  69  20200508 06:39 
Poly select and planning for 2,2210M  swellman  Cunningham Tables  51  20200322 22:09 
Poly select and testsieving for RSA232  VBCurtis  Operation Kibibit  25  20200107 01:57 
YAFU Poly Select Deadline  amphoria  YAFU  22  20160917 09:47 
Starting NFS skipping poly select  jux  YAFU  5  20160102 01:01 