20200420, 12:16  #56  
Apr 2020
263 Posts 
Quote:


20200420, 13:59  #57 
"Ed Hall"
Dec 2009
Adirondack Mtns
47·79 Posts 

20200420, 14:26  #58  
Apr 2020
263 Posts 
Quote:
Quote:
Code:
Mon Apr 20 13:10:09 2020 commencing relation filtering Mon Apr 20 13:10:09 2020 setting target matrix density to 120.0 ... Mon Apr 20 13:48:51 2020 found 115949063 hash collisions in 374461390 relations Mon Apr 20 13:49:13 2020 commencing duplicate removal, pass 2 Mon Apr 20 13:56:33 2020 found 158222008 duplicates and 216239382 unique relations ... Mon Apr 20 15:10:51 2020 matrix is 12730379 x 12730604 (5886.1 MB) with weight 1588223894 (124.76/col) Mon Apr 20 15:10:51 2020 sparse part has weight 1415690179 (111.20/col) Mon Apr 20 15:10:51 2020 using block size 8192 and superblock size 884736 for processor cache size 9216 kB Mon Apr 20 15:11:28 2020 commencing Lanczos iteration (6 threads) Mon Apr 20 15:11:28 2020 memory use: 5541.4 MB Mon Apr 20 15:11:59 2020 linear algebra at 0.0%, ETA 70h20m 

20200420, 14:43  #59  
"Curtis"
Feb 2005
Riverside, CA
1001010101011_{2} Posts 
Quote:
While I don't think going down to 31/31 for the c175 file makes sense, your data tells me I should only very slowly add LP sizes as we increase the size of the input. Perhaps still 31/32 on I=15 for c180, then 32/32 I = 15 for C185 and C190. Fivemack has tested 32 vs 33 (without testing 32/33 hybrid) at C193 and found 33 marginally faster for ggnfs, but we were ignoring matrix size; so I think I'd go with 32/33 for c195 and test I=15 against A=30. Somewhere in the 180190 range, 3 large primes on one side ought to become faster. I think we should test that starting soon; whomever does a C178180 next, please post your poly so I can testsieve a variety of 3LP scenarios. 

20200420, 22:25  #60  
"Ed Hall"
Dec 2009
Adirondack Mtns
E81_{16} Posts 
Quote:
Code:
n: 1258632688840167527990479924759660967727113832014282715541202945214604444063933854224497640052542892497254083608311352572748398102592769128719761767229021194362137011186342088871 skew: 21118322.345 c0: 2400190655725017956973353574287095281260800 c1: 211014402684521569088239119813217640 c2: 39939568153496532334089408958 c3: 1552818850110399495593 c4: 58933721795178 c5: 294840 Y0: 21186307570697279371433463611848173 Y1: 8845196529223700328463 # MurphyE (Bf=4.295e+09,Bg=2.147e+09,area=2.684e+14) = 1.310e07 # f(x) = 294840*x^5+58933721795178*x^41552818850110399495593*x^339939568153496532334089408958*x^2+211014402684521569088239119813217640*x+2400190655725017956973353574287095281260800 # g(x) = 8845196529223700328463*x21186307570697279371433463611848173 On a totally separate note, I appear to have discovered my polyselect stalls. It would seem that one of my clients is failing to return a WU and it is not replaced until the timeout is reached, at what point the new assignment of the WU has to start from scratch. Unfortunately, I was using a 12 hour timeout because some of my ancient machines are yet too young to stay up through the night and I was getting an overrun of maxtimedout for multiday jobs. I must think out my strategy to cope with this. . . 

20200424, 03:07  #61 
"Curtis"
Feb 2005
Riverside, CA
1001010101011_{2} Posts 
I have a little bit of testsieving done on the c178 poly Ed provided a few posts ago.
I am testing a variety of mfb1 settings, leaving mfb0 untouched (at 31/lambda 1.88). The tests are run 12threaded, Q starting at 30M (somewhere around the middle third of relation gathering, seemed representative enough). I let CADO run an hour or so, record the number of relations found, Qrange done, and ETA. Workunits are in blocks of 1000; I thought that was small enough to reduce granularity, but it seems maybe not. When I change settings, I restart CADO and let it run 3040 min to flush out the workunits with the old settings and shuffle up the end times of workers enough to reduce the effect of granular workunits. Original: mfb1 60, lambda1 1.865. 112500 relations/hr, ETA 81 days 20 hr (for default 237M relations). Run 2: mfb1 60, no lambda set. 134200 relations/hr, ETA 78 days 15 hr Run 3: mfb1 64, no lambda. 167000 relations/hr, ETA 70 days 14 hr Next I'll test a variety of mfb1 3LP settings, from 88 to 94. The catch with the apparent clear boost in speed is that using really tight lambda setting reduces relations required quite a lot. A typical 31/32LP job of this size would require 300325M relations, but our runs require 260270. I'm confused by the disparity between relations/hr and ETA; if I go by ETA I'm getting ~15% faster for mfb1=64, but I expect to need 1518% more relations so it's a wash or small loss (though more of the relations would have larger LPs, so one might expect a larger matrix to turn up). If I go by relations/hr, 64 is a clear win. I think the ETA is more accurate, since it accounts for actual workunit length while I may have simply picked lucky endpoints where a bunch of WUs had just ended. When sieving with ggnfs, using 3LP produces a dramatic dropoff in sec/rel as Q rises; so once I find the best MFB1 setting for 3LP here, I'll repeat the comparison at Q=80M for mfb60/64/whatever is best with 3LP. If that indicates a big change in relative timing, I'll do it again at Q=5M. 
20200424, 03:33  #62  
Jun 2012
BB1_{16} Posts 
Quote:


20200424, 04:09  #63 
"Curtis"
Feb 2005
Riverside, CA
3^{4}×59 Posts 
Whoa, that's 20% better than the previous record!? 15% is a digit, so this is near the C177 record? I suppose I should look that up
(moments pass) Yep! C177 record is 1.545e13. So, the CADO poly select and a nice turn of luck took over a digit off the difficulty of this composite. Neat! I imagine one of Carybdis' C177s broke that record, too. 
20200424, 06:23  #64  
"Curtis"
Feb 2005
Riverside, CA
3^{4}×59 Posts 
Quote:
For 2LP runs, I used ncurves1 = 35. For 3LP, I'm using 12; I should test higher also. The ETA gain may be due in part to this drop in ncurves. Run 4: mfb1 88, no lambda. 171000 rels/hr, ETA 62 days 5 hr. Yield 5.12 Run 5: mfb1 90, no lambda. 174500 rels/hr, ETA 59 days 15 hr. Yield 5.21 I added yield to the first 3 runs in the quote above. I'll try mfb1 = 92 tomorrow. Yield is now so high that A=28 is even more likely to be faster than I=15; I'll test that too once I decide which mfb is likely to minimize ETA. Miniconclusion: Sieve speed up 25% over the params Ed is running, yield up 50%. However, unknown how many additional relations are needed without the tight lambda and with 3LP. 

20200424, 12:14  #65  
Apr 2020
263 Posts 
Quote:
Code:
54_1085L 177 (1535...) 1.455e13 1211_759L 177 (5646...) 1.315e13 5+2_415 177 (5721...) 1.440e13 It looks like I=15 31/32 is going to end up being a bit faster than A=28 31/32; I'll report more on this later today. 

20200424, 12:49  #66 
"Ed Hall"
Dec 2009
Adirondack Mtns
111010000001_{2} Posts 
What he said! However, the question forms:
Could there have been any possible advantage to my having 30+ totally separate machines searching (maybe close to 200 threads), vs. a few machines with many threads? @VBCurtis: Are you taking into account duplication ratios? Is that something to even consider? I will have to see what other poly's look like, if I can find/figure out cow noise. . . 
Thread Tools  
Similar Threads  
Thread  Thread Starter  Forum  Replies  Last Post 
Integers congruent to last two decimal digits mod 23  enzocreti  enzocreti  1  20200303 18:38 
Twin Primes with 128 Decimal Digits  tuckerkao  Miscellaneous Math  2  20200216 06:23 
Playing with decimal representation  Nick  Puzzles  9  20130213 17:17 
Decimal Value of Mersenne Prime  vsuite  GPU Computing  11  20110202 04:47 
Decimal Places  Corbyguy  Software  3  20080609 18:09 