2022 Queue management of 15e - Page 14

kruoli · 2022-10-24, 11:12

QUEUED AS W861

861*2⁸⁶¹-1 is a Woodall number that is ready to be sieved as SNFS on 15e:

Code:

n: 188386046098466199536175452570229431563689849939659262401226219971317243525754666917537583167996559619029043912342710003045776630563860201451094450711950131189856666365670472827943792458379509903998351786742808639630866998718013603
# 861*2^861-1, difficulty: 262.12, anorm: -1.05e+36, rnorm: 1.35e+50
# scaled difficulty: 264.94, suggest sieving rational side
# size = 2.269e-13, alpha = 2.805, combined = 4.016e-14, rroots = 2
type: snfs
size: 262
skew: 0.29586
c6: 6888
c0: -1
Y1: -1
Y0: 11150372599265311570767859136324180752990208
rlim: 134000000
alim: 266000000
lpbr: 32
lpba: 32
mfbr: 94
mfba: 64
lss: 1
rlambda: 3.9
alambda: 2.7

Test sieving 1 kQ at a time gave

Code:

Q	norm. yield
35M	2465
40M	2257
70M	2194
125M	2069
200M	1680
300M	1597

So I am suggesting sieving Q from 35M to 275M on the rational side for around 460M raw relations.

I would like to do the LA.

swellman · 2022-10-24, 12:18

QUEUED AS 5m4_865M

5-4,865M from the HCN project is a SNFS 241 (quartic) job to be run on 15e. It is ready for sieving.

Code:

n: 202555903472921376017494458914423311746291773012577711177576348293001774379027222845952446030626352906737399177339738094628434247569226642258535081891097353893608325736988247777126991974546074562669981652275786573190793761
skew: 0.4472
type: snfs
size: 241
c4: 25
c3: 25
c2: 15
c1: 5
c0: 1
Y1: 11972621413014756705924586149611790497021399392059392
Y0: -1292469707114105741986576081359316958696581423282623291015625
rlim: 134000000
alim: 266000000
lpbr: 33
lpba: 32
mfbr: 96
mfba: 64
rlambda: 3.7
alambda: 2.4

Results of test sieving on the rational side with Q in blocks of 1000:

Code:

MQ       Norm_yield
35          1837
50          2261
75          2453
100         2560
150         2447
200         2320
250         2274
300         2187
350         2122

Suggesting a sieving range for Q of 35-350M in order to generate 710M raw relations.

swellman · 2022-11-03, 13:11

QUEUED AS 8m7_341

8-7,341 is a SNFS 280 job from the HCN project now ready for sieving on 15e.

Code:

n: 1257831877902465284401904732297195473572308017725568799120893001756116420424745947122036616596445694485123521851527252735379003753111652033442861028407880668528720791431272129213829740292842857152587040353849000045033642110230877933436752399007747939
# 8^341-7^341, difficulty: 279.96, skewness: 1.00, alpha: 2.22
# cost: 7.57243e+19, est. time: 36059.20 GHz days (not accurate yet!)
skew: 1.000
c5: 1
c4: 1
c3: -4
c2: -3
c1: 3
c0: 1
Y1: -1562531701075863192779448904272185314811647640213651456
Y0: 98104607686593128479834996959304746360186153111467503313
rlim: 134000000
alim: 266000000
lpbr: 33
lpba: 33
mfbr: 96
mfba: 66
rlambda: 3.65
alambda: 2.45

Results of test sieving on the rational side with Q in blocks of 1000:

Code:

MQ       Norm_yield
35          1881
50          1940
75          2127
100         2101
150         2085
200         1789
250         1829
300         1666
350         1588
400         1489
450         1553
500         1377
550         1355
600         1276

Suggesting a sieving range for Q of 35-600M to generate 950M raw relations.

I will park this job here until more jobs from other projects get posted.

kruoli · 2022-11-07, 10:53

QUEUED AS 145!-1

This C185 is a cofactor of the factorial minus 1 number 145!-1 that is ready to be sieved as GNFS on 15e:

Code:

n: 61961544527388294841688073882914854435388027897679210391156264443557149767638767403360578514778014603475277763521601393153149828278695416036164441248566103608937469068435239190125514623
type: gnfs
skew: 23388742
c5: 28963296
c4: -468307738325310
c3: -49748528932542980322741
c2: 314034469329584823868962434378
c1: 10234603583895446847339037580343693197
c0: 4983288639261044534250632896338765636096980
Y1: 4473326874907429
Y0: -335939328349166369840151777825025122
rlim: 266000000
alim: 134000000
lpbr: 32
lpba: 32
mfbr: 64
mfba: 94
lss: 0
rlambda: 2.7
alambda: 3.9

Test sieving 1 kQ at a time gave

Code:

Q	norm. yield
35M	3344
40M	3227
70M	2997
125M	2634
200M	2283
300M	1970
400M	1675

So I am suggesting sieving Q from 35M to 205M on the algebraic side for around 460M raw relations.

I would like to do the LA.

RichD · 2022-11-11, 01:29

C278 from the MWRB file with OPN 11673.

I compromised on the alambda. Increasing it any more generated a few more rels at the cost of time per rels, so I stopped at 2.6. rlambda at 3.6 was much better than 3.5.
I remember several years ago one could change the skew a bit to get better yield. I didn’t modify the skew value.
The formulaic generation of parameters seems to be pretty good but test sieving is always beneficial, along with other's advice.
Please hold for a day or two before queuing to allow feedback and/or modifications.

Code:

n: 10929875925037315024994112350260780199767161975518955535270167413583164858504212664897476377692335059939499260248762932645204102682318951183447267479739483769724008717453251826937850228654862574004845245478825442381443215504635534927206893532265948445909765759873218837942895601
# 7043^73-1, difficulty: 280.89, skewness: 0.23, alpha: 0.00
# cost: 8.09051e+19, est. time: 38526.25 GHz days (not accurate yet!)
skew: 0.228
c6: 7043
c0: -1
Y1: -1
Y0: 14896775084042115440192394458997575421235964401
type: snfs
rlim: 134000000
alim: 268000000
lpbr: 33
lpba: 32
mfbr: 96
mfba: 64
rlambda: 3.6
alambda: 2.6

Trial sieving 2K blocks.

Code:

  Q  Yield N-Yld
 35M  4173  4576
 40M  4523  4251
 70M  3876  4011
100M  3808  3759
200M  3008  2914
300M  2541  2528
400M  2075  2277
485M  1949  2119

This is a 32/33 hybrid job. The region should create about 650M relations.

swellman · 2022-11-11, 13:30

Quote:

Originally Posted by RichD

C278 from the MWRB file with OPN 11673.

I compromised on the alambda. Increasing it any more generated a few more rels at the cost of time per rels, so I stopped at 2.6. rlambda at 3.6 was much better than 3.5.
I remember several years ago one could change the skew a bit to get better yield. I didn’t modify the skew value.
The formulaic generation of parameters seems to be pretty good but test sieving is always beneficial, along with other's advice.
Please hold for a day or two before queuing to allow feedback and/or modifications.

A few suggestions:

I believe the lambda should be mfb/log2(lim) + 0.05 which for the algebraic side is closer to 2.33 or 2.35 if you prefer.

For 15e, rlim + alim is limited to 400M per Greg. alim must be changed to 266M.

I’m not sure about your comment on skew. You’ve used the standard skew = |c0/c6|^(1/6). Cownoise recommends shifting skew to a value of 0.29722 but you should confirm this skew value with cownoise and whether if it improves things via test sieving. (I doubt it will help.)

Max had a method of spinning things to lower skew with holding escore (nearly) constant but he’s not been around for awhile now. No one else has his recipe for this technique to my knowledge.

Lastly, you could invert the roots of the polynomial to get a better skew value as suggested for this past job, with @charybdis’s recommendation.

The job as posted should run just fine, but you may want to investigate some of the above ideas. Perhaps others will add deeper insights.

kruoli · 2022-11-11, 13:36

Quote:

Originally Posted by swellman

I believe the lambda should be mfb/log2(lim) + 0.05 which for the algebraic side is closer to 2.33 or 2.35 if you prefer.

IIRC what charybdis said, it should be plus 0.2 or 0.3; I cannot find the post right now.

VBCurtis · 2022-11-11, 16:24

Quote:

Originally Posted by kruoli

IIRC what charybdis said, it should be plus 0.2 or 0.3; I cannot find the post right now.

Charybdis did suggest adding 0.2 to the formula, but I've found that adding 0.05 captures nearly all the relations as adding 0.2, but with faster sec/rel. Dropping the non-sieve-side lambda to 2.35 or 2.4 has gained me 10% or so in job elapsed-time versus my previous "2.6 is good enough" assumption for nearly every job.

More generally, I think too much focus in test-sieving is on improving yield, rather than improving speed. Often both improve at the same time, but with lambda it's worth losing a few relations to find the others faster. I'd test mfba of 63 also; you'll need 4-5% fewer relations to finish the job (like 625M instead of 650M) by shrinking mfba, so if you lose less than 4% in sec/rel it's a net win.

RichD · 2022-11-12, 02:12

The following was performed on a Sandy Bridge chip at Q=40M using 2K block.
I need to investigate this further and the other ideas in the coming days.

Code:

 rlambda=2.6 | rlambda=2.5 | rlambda=2.4
yield sec/rel|yield sec/rel|yield sec/rel
 4251  0.519 | 4376  0.521 | 4371  0.520

kruoli · 2022-11-12, 16:07

...and IIUC, enlarging lambda's more than this 0.05 is theoretically useful when the Q range is largely below the corresponding lim? (This would need test sieving over the whole Q range.)

Regarding not optimising for rel/s, I plead guilty.

VBCurtis · 2022-11-13, 02:19

Enlarging the lambda *on the sieve side* beyond this 0.05 "extra" is indeed useful, because GGNFS reduces the lim on the sieve side to {start of Q range -1}. So, if you have sieve-side lim of 60M and sieve from 20M-80M, Your lim is actually 19,999,999 for the first sieve range (and 29,999,999 when sieving a range starting at Q=30M, etc) and thus benefits from a larger lambda. This is part of the explanation for why folks who use far-too-big lambdas have test-sieve results with really fast results at small Q (lambda nearly ideal and lower Q are faster anyway) but sec/rel falls off really fast as Q rises (larger Q suffering from lots of wasted cofactor-splitting work due to large lambda).

On the non-sieve side, none of this happens / is relevant, so lambda should be simply what theory indicates for lim/MFB choice, with a few hundredths / a tenth added to compensate for the estimation errors that occur in the step where lambda is used.

2022-11-12, 02:12	#152
RichD Sep 2008 Kansas EE0₁₆ Posts	The following was performed on a Sandy Bridge chip at Q=40M using 2K block. I need to investigate this further and the other ideas in the coming days. Code: rlambda=2.6 \| rlambda=2.5 \| rlambda=2.4 yield sec/rel\|yield sec/rel\|yield sec/rel 4251 0.519 \| 4376 0.521 \| 4371 0.520

2022-11-13, 02:19	#154
VBCurtis "Curtis" Feb 2005 Riverside, CA 1608₁₆ Posts	Enlarging the lambda on the sieve side beyond this 0.05 "extra" is indeed useful, because GGNFS reduces the lim on the sieve side to {start of Q range -1}. So, if you have sieve-side lim of 60M and sieve from 20M-80M, Your lim is actually 19,999,999 for the first sieve range (and 29,999,999 when sieving a range starting at Q=30M, etc) and thus benefits from a larger lambda. This is part of the explanation for why folks who use far-too-big lambdas have test-sieve results with really fast results at small Q (lambda nearly ideal and lower Q are faster anyway) but sec/rel falls off really fast as Q rises (larger Q suffering from lots of wasted cofactor-splitting work due to large lambda). On the non-sieve side, none of this happens / is relevant, so lambda should be simply what theory indicates for lim/MFB choice, with a few hundredths / a tenth added to compensate for the estimation errors that occur in the step where lambda is used. Last fiddled with by VBCurtis on 2022-11-13 at 02:20

Similar Threads
Thread	Thread Starter	Forum	Replies	Last Post
Queue management for 14e queue	VBCurtis	NFS@Home	170	2023-01-02 15:27
2022 - queue management for 15e_small	swellman	NFS@Home	186	2022-12-29 17:58
Queue management for 16e queue	VBCurtis	NFS@Home	154	2022-12-23 21:35
Queue management for e_small and 15e queues	VBCurtis	NFS@Home	254	2022-01-02 01:59
Improving the queue management.	debrouxl	NFS@Home	10	2018-05-06 21:05

2022-11-12, 16:07	#153
kruoli "Oliver" Sep 2017 Porta Westfalica, DE 1,327 Posts	...and IIUC, enlarging lambda's more than this 0.05 is theoretically useful when the Q range is largely below the corresponding lim? (This would need test sieving over the whole Q range.) Regarding not optimising for rel/s, I plead guilty.