Fast Breeding (guru management)

[swellman]

Originally Posted by RichD

So we are not running anymore 29-bit jobs? I was prepping a quartic at SNFS-197. I'll look for a different one.

29-bit jobs are not necessarily a hard no, especially with quartics.

The above list are guidelines, not hard rules of the road. I reproduce here the list previously
published list by debroulx:

* SNFS polynomials should have leading coefficients < 10^5
* SNFS tasks with degree 6 polynomials (preferred) should have 225 <= difficulty <= 250, ECM to 2/9 of SNFS difficulty
* SNFS degree 5 tasks should have 210 <= difficulty <= 235, ECM to 2/9 of (15+SNFS difficulty)
* SNFS degree 4 tasks should have 195 <= difficulty <= 220, ECM to 2/9 of (30+SNFS difficulty)
* GNFS tasks should have 155 <= difficulty <= 170, ECM to 2/7 of GNFS difficulty (a bit more than that for difficulty close to 170).

Personally, I have no issue with the lower limit of quartics being < 205. Even accounting for increases in throughput of modern home computers and subsequent re-evaluation of debrouxl’s rules of thumb above, quartics are tough to sieve.

So I will henceforth follow the guideline of quartic SNFS jobs 195-220.

My opinion on GNFS being < 175 is unchanged. More than 175 GNFS belongs on 15e. The lower GNFS limit is 150-155. I have no problem making this 150. But 14Xs you can sieve yourself in a week.

But back to the SNFS 263 with interesting parameters suggested by VBCurtis for 14e. Any objections to submitting it to 14e?

[RichD]

Originally Posted by swellman

My opinion on GNFS being < 175 is unchanged. More than 175 GNFS belongs on 15e. The lower GNFS limit is 150-155. I have no problem making this 150. But 14Xs you can sieve yourself in a week.

But back to the SNFS 263 with interesting parameters suggested by VBCurtis for 14e. Any objections to submitting it to 14e?

Some GNFS (slightly) above 175 are adequate for 14e if the E-score is at or near a record.

I think VBCurtis has done sufficient testing that he believes could be run on 14e. Given 15e always has a backlog and 14e is sometimes dry. This could be a learning lesson for all.

[R.D. Silverman]

Originally Posted by swellman

Currently we are using the following guidelines for 14e:

SNFS quartics 205-220
SNFS quintics/sextics 230-255
GNFS 155-175

So a SNFS-270 is definitely a 15e job. Your 14e/33 job (SNFS-263) probably should go to 15e as well (as a 15e/32 job) though I’m curious how it would perform on 14e with these parameters.

Anyone care to comment? 14e or 15e?

These limits are not hard.

See post 2208. This is a C203? Via SNFS? It seems these rules about size limits
do get violated. Quartics smaller than C205 get done all the time. I've seen sextics below C230 as well. SNFS above 255 and GNFS above C170 should probably go to 15e.

I am currently doing an SNFS C204 by myself. But I only have a single PC with 6 cores.

[jyb]

I believe the guideline for the high end shouldn't be so much "Is this too hard for 14e?" but rather "Would this be more efficient (i.e. require fewer overall resources) on 15e?".

That way the proof is in the test sieving, so to speak. So is an SNFS-270 wrong for the 14e queue? Instead of relying on particular difficulty values, just do some test sieving with both the 14e and 15e sievers. Which one will result in less CPU time, while allowing for a reasonable matrix to be built and solved?

(My guess is that SNFS-270 jobs will pretty much always end up being better for 15e, but it's just a guess, and more importantly, my guess doesn't matter since there's a better way to decide.)

[VBCurtis]

I test-sieved 13*2^892-1 on 15e last night also, and was a bit disappointed with timings when comparing to the last job I submitted (13_2_857m, about a year ago). So I tried 871 on 14e, was pleasantly surprised to find it fit within Q below 250M, and suggested it.

I have no doubt that 15e would be a bit more efficient, but my 2018 grasp of the queues is that 14e needs food more than 15e needs "easy" tasks. I don't mind test-sieving this on 15e and reporting an estimated efficiency (i.e. total sieve time) savings- but if the savings is under 10% (15%?) shouldn't it feed 14e to keep workers in business? That's the same logic as using GNFS196-199 on 15e; 16e is more efficient, but we have available workers on 15e and more interesting jobs running on 16e (not to mention a lack of control over the 16e queue).

I'll report on 15e timings tonight.

[jyb]

Originally Posted by VBCurtis

I test-sieved 13*2^892-1 on 15e last night also, and was a bit disappointed with timings when comparing to the last job I submitted (13_2_857m, about a year ago). So I tried 871 on 14e, was pleasantly surprised to find it fit within Q below 250M, and suggested it.

I have no doubt that 15e would be a bit more efficient, but my 2018 grasp of the queues is that 14e needs food more than 15e needs "easy" tasks. I don't mind test-sieving this on 15e and reporting an estimated efficiency (i.e. total sieve time) savings- but if the savings is under 10% (15%?) shouldn't it feed 14e to keep workers in business? That's the same logic as using GNFS196-199 on 15e; 16e is more efficient, but we have available workers on 15e and more interesting jobs running on 16e (not to mention a lack of control over the 16e queue).

I'll report on 15e timings tonight.

These are reasonable points, and I don't want to sound doctrinaire on this. As Bob said, the limits aren't firm here. In particular, if you do in fact find that the difference is under 10%, then it doesn't seem worth worrying about if it goes into the "wrong" queue. I'm more concerned with bigger inefficiencies than that.

But as for keeping the 14e workers busy, I'm not sure that's a very important goal. My thoughts on that are probably best summed up in point #2 here.

Now 15e vs 16e may be a different story, for the reasons you've already given: 1) 16e is working on more "interesting" things (e.g. Cunningham numbers, which are of interest to a lot more people), and 2) we don't control the 16e queue. I think the latter point may be the most important one here. The tools we have to work with are the 14e and 15e queues. If a job is tractable with those tools then it makes sense to use them, even if a better tool could do it faster; in a sense we don't have that better tool, so why consider it?

[fivemack]

I have decided to run the kind of quartic jobs that work significantly better at 16e than 15e locally rather than using the 15e queue, but I'm not quite sure if I'd still be doing that if the 15e queue weren't hopelessly clogged with my effort to finish the Fibonacci numbers to 200 digits by the end of the year.

(they can be run at 32-bit, don't need all that many relations and produce pleasingly small matrices; F1475 is currently in linalg after not quite two months of sieving, L2855A which is almost exactly at the 15e/16e breakeven is currently sieving)

[swellman]

Originally Posted by VBCurtis

I test-sieved 13*2^892-1 on 15e last night also, and was a bit disappointed with timings when comparing to the last job I submitted (13_2_857m, about a year ago). So I tried 871 on 14e, was pleasantly surprised to find it fit within Q below 250M, and suggested it.

I have no doubt that 15e would be a bit more efficient, but my 2018 grasp of the queues is that 14e needs food more than 15e needs "easy" tasks. I don't mind test-sieving this on 15e and reporting an estimated efficiency (i.e. total sieve time) savings- but if the savings is under 10% (15%?) shouldn't it feed 14e to keep workers in business? That's the same logic as using GNFS196-199 on 15e; 16e is more efficient, but we have available workers on 15e and more interesting jobs running on 16e (not to mention a lack of control over the 16e queue).

I'll report on 15e timings tonight.

I’m fine with submitting this job to 14e, though a comparison to its 15e performance may be enlightening. But it’s certainly not a precondition.

[VBCurtis]

Originally Posted by jyb

These are reasonable points, and I don't want to sound doctrinaire on this. As Bob said, the limits aren't firm here. In particular, if you do in fact find that the difference is under 10%, then it doesn't seem worth worrying about if it goes into the "wrong" queue. I'm more concerned with bigger inefficiencies than that.

I test-sieved 15e; to reduce variables and guesses, I changed lim's to 100M/134M but did not change mfb or lbp. Measuring at the same Q values, sec/rel is about 15% better while yield is up 80% or so.
Combining those two effects means a Q-range of 15-110M rather than 15-245M, and with the average relation being found at ~50M rather than ~110M the actual time saved is around 25-28% for 15e over 14e. That assumes 710M raw 15e relations would produce a similar matrix as 750M raw 14e relations (since bigger sievers have a lower duplicate rate).
I have previously measured sec/rel at 10-15% better for 15e, but didn't fully consider the effect of not having to sieve the large Q values before. I won't be submitting any more SNFS-260+ to 14e, unless someone wants to see just how far 14e can go (I'm your man for such curiosities!).
Thank you all for your consideration, and for queueing the number anyway.
15e data, with Q-ranges of 500 tested:

#15e 100/134M, 33/93-64 -r: Q=15-110M = 710M rels
#Q=20M	5786 rels, 0.084 sec/rel
#Q=50M	4044 rels, 0.106 sec/rel
#Q=80M	2691 rels, 0.113 sec/rel
#Q=110M	2805 rels, 0.134 sec/rel

Edit: Here's the original 14e data again, for those curious to compare: (Q-range of 1000 here, 500 above)

#14e 134/268M, 33/93-64 -r:	Q=15-245M = 750M rels
#Q=20M	6244 rels, 0.097 sec/rel
#Q=50M	4390 rels, 0.121 sec/rel
#Q=80M	3365 rels, 0.144 sec/rel
#Q=110M	3284 rels, 0.154 sec/rel
#Q=140M	2871 rels, 0.181 sec/rel
#Q=170M	2320 rels, 0.164 sec/rel
#Q=200M	2693 rels, 0.177 sec/rel
#Q=230M	2465 rels, 0.186 sec/rel

[jyb]

QUEUED AS 9p8_308

Wow, there seems to be a surge of activity on the queues. Anyone know why?

SNFS-251.92 C217 HCN (9+8,308), ECM to t55. For 14e.

n: 1011066397196212826464164521783438912271908925959739134277425479471368133367797326158505023644700822558279986670511556505523599625146380271489729182304591357198196305077595784461303504854399221824061156472884420764449
# 9^308+8^308, difficulty: 251.92, skewness: 1.00, alpha: 2.24
skew: 1.000
c6: 1
c5: -1
c4: 1
c3: -1
c2: 1
c1: -1
c0: 1
Y1: -5444517870735015415413993718908291383296
Y0: 969773729787523602876821942164080815560161
rlim: 134000000
alim: 134000000
lpbr: 31
lpba: 31
mfbr: 93
mfba: 62
rlambda: 3.6
alambda: 2.6

Trial sieving 2K blocks.

 Q		Yield
---		-----
20M		4353
60M		2996
100M		2562
140M		2008
180M		1786
220M		1885
260M		1931
300M		1670

Recommend sieving special Q on rational side, 20M - 230M.

[jyb]

QUEUED AS 9p7_308

SNFS-251.92 C230 HCN (9+7,308), ECM to t55. For 14e.

n: 14231437641237527396672442339718567599203126314523548581341470571370907183161585296696101695575090049536532853263310239745321933931950242499538883397359686213918612029109553279746435055975073118262214442484072293625975589778956801
# 9^308+7^308, difficulty: 251.92, skewness: 1.00, alpha: 2.24
skew: 1.000
c6: 1
c5: -1
c4: 1
c3: -1
c2: 1
c1: -1
c0: 1
Y1: -15286700631942576193765185769276826401
Y0: 969773729787523602876821942164080815560161
rlim: 134000000
alim: 134000000
lpbr: 31
lpba: 31
mfbr: 93
mfba: 62
rlambda: 3.6
alambda: 2.6

Trial sieving 2K blocks.

 Q		Yield
---		-----
20M		4452
60M		2998
100M		2607
140M		2098
180M		1833
220M		1865
260M		1865
300M		1647

Recommend sieving special Q on rational side, 20M - 230M.