Fast Breeding (guru management)

[swellman]

Originally Posted by swellman

QUEUED C229_151_42 is ready for SNFS on 14e. Last 14e in my stores.

n: 1102417068447110828974330387319614606833947746041503077867648379042331914001941722688011464435548663098126330974444255295476735778999607110151139584098525740184596427948553032403054613968391022558764428920771666069942700842508993
type: snfs
size: 245
skew: 1.86441
c0: 42
c6: 1
Y1: 38126967124946768663101433365298971410432
Y0: -1789940649848551
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 5K

Q=20M   11483
Q=80M    8730
Q=150M   6265
Q=250M   4660
Q=350M   4104

Suggesting a sieving range of 20M-400M with a target number of relations = 460M.

C229_151_42 appears to producing at a prodigious yield, far greater than my test sieving results above. So high that I find 14e’s results difficult to believe.

Is there an issue with 14e? Lots of dups? Inspection of the poly file from 14e shows nothing obvious.

[fivemack]

Originally Posted by swellman

C229_151_42 appears to producing at a prodigious yield, far greater than my test sieving results above. So high that I find 14e’s results difficult to believe.

Is there an issue with 14e? Lots of dups? Inspection of the poly file from 14e shows nothing obvious.

Are you sure that your test sieving was over 5k rather than 2k ranges?

I have run

/work/math/gnfs-lasieve4I14e snfs -r -f 150000000 -c 5000

and see 6597 relations by Q=150002063

total yield: 15968, q=150005021 (0.11933 sec/rel)

is quite close to 5/2 of the claimed yield

[swellman]

I think I see what may have happened - the previous job I test sieved was C167_M31_k33, a GNFS job. Test sieved on the -a side. May have then immediately used the same scripts to test sieve C229_151_42. Embarrassed apologies.

Thank you for taking this uglier than it should be job.

[RichD]

C241 from the OPN MWRB file with OPN weight nearly 24K.

n: 1465198448177965428772026990227075055702727441032985216293696461981941574813770882021969879133562225263889540648065878923236437280161477935898854454731228974338074953129161253134126152495378305301918303763757927109426114532655728650934645831
# 13829^59-1, difficulty: 248.45, skewness: 6.73, alpha: 0.00
# cost: 7.37407e+18, est. time: 3511.46 GHz days (not accurate yet!)
skew: 6.732
c5: 1
c0: -13829
Y1: -1
Y0: 48920323413279685134888105908255791411939427791441
type: snfs
rlim: 134000000
alim: 268000000
lpbr: 32
lpba: 32
mfbr: 64
mfba: 95
rlambda: 2.7
alambda: 3.6

Trial sieving 5K blocks.

  Q Yield
 20M 6484
 60M 7328
100M 8315
150M 7586
200M 7368
300M 6913
400M 6279

[swellman]

Originally Posted by swellman

I think I see what may have happened - the previous job I test sieved was C167_M31_k33, a GNFS job. Test sieved on the -a side. May have then immediately used the same scripts to test sieve C229_151_42. Embarrassed apologies.

Thank you for taking this uglier than it should be job.

Confirmed the above did NOT happen. Reran C229_151_42 for 5K with Q=20M on the -r side and got 11483 relations. Odd. Maybe it is machine or siever dependent? I’ll rerun the test sieving this evening on another machine/environment. All my boxes are Win64, if that matters.

[RichD]

QUEUED AS C212_157xx799_13
C212 from the OPN t600 file.
[ a.k.a. Phi_13(Phi_31(11)/50159/2428541)/79/<p30> ]

n: 28074502122564319908979181531967537616095668707384454473748919573561082001884566015915909261090700889679832915180616153494785635778300687649218819936786961125157204537625400997331224951086304617912441364997580901
# 157571957584602258799^13-1, difficulty: 242.37, skewness: 1.00, alpha: 3.10
# cost: 4.612e+18, est. time: 2196.19 GHz days (not accurate yet!)
skew: 1.000
c6: 1
c5: 1
c4: -5
c3: -4
c2: 6
c1: 3
c0: -1
Y1: -157571957584602258799
Y0: 24828921817043693312917600278892972922402
type: snfs
rlim: 67000000
alim: 134000000
lpbr: 31
lpba: 31
mfbr: 61
mfba: 61
rlambda: 2.6
alambda: 2.6

Trial sieving 5K blocks.

  Q  Yield
 20M 12319
 60M 10064
100M  8778
150M  6902

[swellman]

Originally Posted by swellman

Confirmed the above did NOT happen. Reran C229_151_42 for 5K with Q=20M on the -r side and got 11483 relations. Odd. Maybe it is machine or siever dependent? I’ll rerun the test sieving this evening on another machine/environment. All my boxes are Win64, if that matters.

Repeated this exercise on another machine with the
newer ggnfs sievers. Got 23767 relations on a 5K block of Q. I knew the newer sievers were faster but had never noticed such disparity in yield. Mystery solved, and I’ll not use the old sievers again!

[RichD]

QUEUED AS C202_31_173
C202 from the OPN t600 file.

n: 2905727676062406581210143813463355281321549043490114270159566965555133147925016922068597211500273316200934979655112275928267750162727044710845265351725732582843332610215496302023194109196714634798893557
# 31^173-1, difficulty: 259.50, skewness: 1.77, alpha: 0.00
# cost: 1.70111e+19, est. time: 8100.53 GHz days (not accurate yet!)
skew: 1.772
c6: 1
c0: -31
Y1: -1
Y0: 17761887753093897979823770061456102763834271
type: snfs
rlim: 268000000
alim: 536000000
lpbr: 32
lpba: 32
mfbr: 64
mfba: 94
rlambda: 2.6
alambda: 3.6

Trial sieving 5K blocks.

  Q  Yield
 30M 10818
 90M  9676
150M  8316
250M  7390
350M  7003

[RichD]

QUEUED AS C191_295xx029_13
C191 from the OPN t600 file.
[ a.k.a. Phi_13(Phi_3(Phi_29(13)/1973/2843/3539)/3/11959/85093/79236309623407)/<p32> ]

n: 12794062033878655457450355776266486437430348094623888074791572090516980553375503615389937683920201291889580924137859987844778415030061375032797695148998297559103483481688024256497772362510753
# 2959025653654433029^13-1, difficulty: 221.65, skewness: 1.00, alpha: 3.10
# cost: 8.81455e+17, est. time: 419.74 GHz days (not accurate yet!)
skew: 1.000
c6: 1
c5: 1
c4: -5
c3: -4
c2: 6
c1: 3
c0: -1
Y1: -2959025653654433029
Y0: 8755832818985044651391268463446114842
type: snfs
rlim: 17000000
alim: 34000000
lpbr: 29
lpba: 29
mfbr: 58
mfba: 58
rlambda: 2.5
alambda: 2.5

Trial sieving 5K blocks.

 Q Yield
 6M 9836
10M 8908
20M 7450
40M 5587
50M 5081

[kosta]

The best poly so far, for the C174_M127_k24, at 50% complete with CADO.
Is this good enough? Test sieving with some unoptimized param gave yield 8160 @6M, but i am not sure i did this right :-(

n: 94410615373218704797201510125651849712559525623382519147033843966374414757318643595714477201887765034604269728700950434464990003242159016268314282962617716190928317011619566657
Y0: -7471849389251086201749091300586895
Y1: 708649660173940995547
c0: 2621705914649230171819209755822160165162
c1: -993914513963741328984046025976199
c2: -1358186992798631904082561818
c3: 265509778204990369114
c4: -243054615251784
c5: -12161880
skew: 2530302.065
# lognorm 53.49, E 47.81, alpha -5.68 (proj -2.31), 3 real roots
# MurphyE(Bf=1.00e+07,Bg=5.00e+06,area=1.00e+16)=1.30e-13
# Average exp_E: 47.62, average E: 47.81

[fivemack]

Originally Posted by kosta

The best poly so far, for the C174_M127_k24, at 50% complete with CADO.
Is this good enough?

That looks a perfectly reasonable polynomial.

Test-sieving results are only meaningful if you list the limits and the command line used: with

lpbr: 32
lpba: 32
mfbr: 64
mfba: 64
alambda: 2.6
rlambda: 2.6
alim: 268000000
rlim: 268000000

I get

> ./gnfs-lasieve4I14e -a M127_k24.gnfs -f 268000000 -c 999
total yield: 1638, q=268001011 (0.34965 sec/rel) 
> ./gnfs-lasieve4I15e -a M127_k24.gnfs -f 268000000 -c 1000
total yield: 3824, q=268001011 (0.21752 sec/rel)
> ./gnfs-lasieve4I16e -a M127_k24.gnfs -f 268000001 -c 999
total yield: 8517, q=268001011 (0.23832 sec/rel)

so, unless you tell me not to in the next day, I will queue this on 14e (it's much less efficient than 15e, but the queue is much shorter so it will get done quicker)