Fast Breeding (guru management) - Page 115

RichD · 2017-11-22, 21:41

Quote:

Originally Posted by VBCurtis

I propose Two Golden Rules of 14e queue parameter choice:
1. Choose lim's such that your forecasted sieve range ends before 2 * {lim on the sieving side}. You don't have to choose a power-of-two lim: 140M is not a fast choice (just above a power-of-two), but there's nothing wrong with using 180M or 100M.
2. Choose LP bound such that average yield (specifically, relations divided by Q-range) is 2.0 or higher.

It's really unlikely to go wrong when following these two rules, and rarely faster to violate either of them.

Those are really good general rules to go by. The quartics (p^5-1) must have different attributes.

I tried increasing the lim from 67M to 134M but that added 20-25% more time per rel, but did increase the yield. We still needed the same number of total relations. Hence, more total time to sieve. My accidental first try had the best times of all - nearly half the current rate.

I usually like to keep the range to about 1.6-1.8 times the lim. I've seen curves where the yield starts at 2.0 but by the time the Q gets to 2*lim, it could be at or below 1.0. This curve is so flat there is not much of a penalty extending the range, for some unknown reason.

Which brings me to another point. I sometimes will increase the lim by 50% to squeeze a bit more yield. It increases the time/rel more than the yield gain but it keeps from getting past the 2*lim region where the curve really falls off. I try to avoid creating 32-bit jobs where it takes weeks on my Core-i5 to post-process.

P.S. These where the parameters jyb used for p55^5-1 jobs when he added items to the queue.

VBCurtis · 2017-11-22, 22:45

Quote:

Originally Posted by RichD

Those are really good general rules to go by. The quartics (p^5-1) must have different attributes.

I tried increasing the lim from 67M to 134M but that added 20-25% more time per rel, but did increase the yield. We still needed the same number of total relations. Hence, more total time to sieve. My accidental first try had the best times of all - nearly half the current rate.

I usually like to keep the range to about 1.6-1.8 times the lim. I've seen curves where the yield starts at 2.0 but by the time the Q gets to 2*lim, it could be at or below 1.0. This curve is so flat there is not much of a penalty extending the range, for some unknown reason.

Which brings me to another point. I sometimes will increase the lim by 50% to squeeze a bit more yield. It increases the time/rel more than the yield gain but it keeps from getting past the 2*lim region where the curve really falls off. I try to avoid creating 32-bit jobs where it takes weeks on my Core-i5 to post-process.

P.S. These where the parameters jyb used for p55^5-1 jobs when he added items to the queue.

This is, indeed, interesting to note the exceptions to such rules. Your job has a very unusually flat yield/Q curve, and a small choice of alim/rlim does appear better than my rules. I haven't done many (any?) quartics with SNFS, so my "golden rules" are perhaps only for degree 5-6 polys.

I do object to your 32-bit comment, though- unless this is another quartic quirk, I've found no difference in matrix size for 32LP vs 31LP, for a given difficulty of input number. Tough 32LP jobs are way bigger than most 31LP jobs, but there's no reason to assume that a bigger LP bound produces a bigger matrix.

RichD · 2017-11-24, 23:33

QUEUED C223_14083_59 C223 from the OPN t550 file.

Code:

n: 1865615717130772767119311116455570124208658607305842896726964588854670423572329039423087652007275888761705267019924529226143361268713546866643218854079602599917062877045108854870518360637155062971394820217914898442214150729
# 14083^59-1, difficulty: 248.92, skewness: 4.91, alpha: 0.00
# cost: 7.6469e+18, est. time: 3641.38 GHz days (not accurate yet!)
skew: 4.914
c6: 1
c0: -14083
Y1: -1
Y0: 306868134259300507087306303463544482273449
m: 306868134259300507087306303463544482273449
type: snfs
rlim: 134000000
alim: 268000000
lpbr: 32
lpba: 32
mfbr: 64
mfba: 64
rlambda: 2.7
alambda: 2.7

Trial sieving 5K blocks.

Code:

RichD · 2017-11-25, 00:21

QUEUED C188_895087_37 C188 from the OPN t600 file.

Code:

n: 10617829570839276659747741853830398849952865684054101910712506186845820619498688254461924516392091331519790551485245847452914148598316001358346365710249062092556695500444158007971971931097
# 895087^37-1, difficulty: SNFS-222
skew: 0.102
c6: 895087
c0: -1
Y1: -1
Y0: 514270363717491334687895212442791009
m: 514270363717491334687895212442791009
type: snfs
rlim: 67000000
alim: 134000000
lpbr: 30
lpba: 30
mfbr: 60
mfba: 60
rlambda: 2.6
alambda: 2.6

Trial sieving 5K blocks.

Code:

wombatman · 2017-11-25, 03:27

A C208 blocker from HP2(4496) index 314. It has been thoroughly ECM'd and shows no sign of breaking.

The polynomial is:

Code:

n: 8095101662371927421703337019465587498085337648622133688278589711654019359923503887978141510461468343349838217540569173400647791769725685803537804186347867144149599002247585690859122186539724272741806859085719
skew: 771127364.56
Y0: -17068243492239505219994785346910834818341
Y1: 1873940548553722757
c0: 165792391853474935561243616954647727516748946250496
c1: 2160239644350504494844955872920952825447896
c2: -21514458180493538566295548810659238
c3: -5887571126475837688637761
c4: 35919796435243602
c5: 5588280
type: gnfs

rlim: 800000000
alim: 800000000
lpbr: 33
lpba: 33
mfbr: 96
mfba: 96
rlambda: 2.6
alambda: 4.6

All parameters were set based on the previous C207 I ran as well as some sieving tests. The best degree 6 polynomial was also checked and found to be slower.

Sieve timings are as follows:

Code:

Q-blocks of 2000, 16e
33A
	 50M: total yield: 2030, q=50002009  (2.37828 sec/rel)
	100M: total yield: 2986, q=100002011 (2.19112 sec/rel)
	200M: total yield: 2663, q=200002007 (2.28734 sec/rel)
	300M: total yield: 3343, q=300002029 (2.41504 sec/rel)
	400M: total yield: 2874, q=400002011 (2.70271 sec/rel)
	500M: total yield: 2619, q=500002003 (3.04544 sec/rel)
	600M: total yield: 2464, q=600002003 (2.94305 sec/rel)
	700M: total yield: 2263, q=700002011 (3.67559 sec/rel)
	800M: total yield: 2904, q=800002003 (3.70078 sec/rel)
	900M: total yield: 2771, q=900002017 (3.72014 sec/rel)

The C207 needed 950M+ relations to build the matrix, according to the log, so the Q-range needs to be ~635M long or so, which would suggest something like 100M-800M?

I know this will need to be sent to frmky to actually get added to the 16e queue, but I figured I would post it here for both posterity and to make sure I didn't miss anything obvious before I make my request to him.

swellman · 2017-11-25, 16:55

Just curious - did you mean alambda: 4.6 or is that a typo?

If intentional, does it make a big difference in speed/yield?

wombatman · 2017-11-25, 18:52

Quote:

Originally Posted by swellman

Just curious - did you mean alambda: 4.6 or is that a typo?

If intentional, does it make a big difference in speed/yield?

The 4.6 is intentional and it does slightly improve the speed and yield over 3.6.

VBCurtis · 2017-11-25, 19:02

The 2.6 for the other lambda makes no sense, since you have 96 for mfbr. 3LP require lambda above 3.0.

wombatman · 2017-11-25, 19:04

Quote:

Originally Posted by VBCurtis

The 2.6 for the other lambda makes no sense, since you have 96 for mfbr. 3LP require lambda above 3.0.

Thanks. I'll up it and re-run a few ranges to see how that parameter affects the speed and yield.

RichD · 2017-11-26, 15:14

QUEUED C215_10695665473_23 C215 from the OPN t550 file.
Sieve on the algebraic side.

Code:

n: 30763230003902403786374728887690763700728078820500331429048458439998376653484290078336744584927334552651151486915560134867070802466057580185289662645224533831086254604129851935910106985930522415164930677253990639963
# 10695665473^23-1, difficulty: 240.70, skewness: 46.94, alpha: 0.00
# cost: 4.04942e+18, est. time: 1928.29 GHz days (not accurate yet!)
lss: 0
skew: 46.939
c6: 1
c0: -10695665473
Y1: -1
Y0: 13086733074990294411997693788174817885441
m: 13086733074990294411997693788174817885441
type: snfs
rlim: 132000000
alim: 132000000
lpbr: 32
lpba: 32
mfbr: 64
mfba: 64
rlambda: 2.7
alambda: 2.7

Trial sieving 5K blocks.

Code:

swellman · 2017-11-27, 18:43

QUEUED AS C210_129_103b because I put it on 14e first by mistake C210_129_103 is ready for SNFS on the 15e siever.

Code:

n: 973422547784370322457514782831736956145196852856089924944333043407352689659116145124574973212168048907620323202284319881038292185920124546679327720675621471037727699034904089811538148953969144467029739410525629
# 129^103+103^129, difficulty: 261.77, anorm: 2.37e+040, rnorm: -3.95e+048
# scaled difficulty: 263.14, suggest sieving rational side
# size = 1.970e-013, alpha = 0.000, combined = 3.740e-014, rroots = 0
type: snfs
size: 261
skew: 4.5150
c6: 129
c0: 1092727
Y1: -1860294571709496226110032706809177658295303
Y0: 758621374683090977986568634824263809
rlim: 268000000
alim: 268000000
lpbr: 32
lpba: 32
mfbr: 64
mfba: 64
rlambda: 2.8
alambda: 2.8

Test sieving on the -r side with Q in blocks of 2K.

Code:

20M    4879
80M    3522
150M   3378
250M   3015
320M   2764

Suggesting a sieving range of 20M-300M with target # rels=480M.

Similar Threads
Thread	Thread Starter	Forum	Replies	Last Post
System management notes	kriesel	kriesel	7	2020-10-21 18:52
Improving the queue management.	debrouxl	NFS@Home	10	2018-05-06 21:05
Script-based Primenet assignment management	ewmayer	Software	3	2017-05-25 04:02
Do normal adults give themselves an allowance? (...to fast or not to fast - there is no question!)	jasong	jasong	35	2016-12-11 00:57
Power Management settings	PrimeCroat	Hardware	3	2004-02-17 19:11

2017-11-25, 16:55	#1260
swellman Jun 2012 110000010011₂ Posts	Just curious - did you mean alambda: 4.6 or is that a typo? If intentional, does it make a big difference in speed/yield?

2017-11-25, 19:02	#1262
VBCurtis "Curtis" Feb 2005 Riverside, CA 11412₈ Posts	The 2.6 for the other lambda makes no sense, since you have 96 for mfbr. 3LP require lambda above 3.0.