My best from msieve, A1 from 10M to 11.8M default stage 1 norm:
[code]# norm 1.255195e-17 alpha -7.418710 e 7.273e-14 rroots 1
skew: 12833137.64
c0: -1651844500202603092273209171676707935633280
c1: -666189676666650339051903353897671332
c2: -22882374219520520514775531444
c3: 19138754816351501187919
c4: 118556687648450
c5: 11772024
Y0: -42052088395839133578660941153950487
Y1: 3988882332181554479[/code]
Second best is 7.10, no others over 7.0.
CADO should finish soon.

My best poly:
[CODE]
# norm 1.410097e-17 alpha -6.283760 e 7.775168e-14 rroots 5
skew: 55099868.10
c0: -26923371051647154482176838989390697776905419
c1: 270802559180583462999025156019328254
c2: 79868109989680201381603449209
c3: -598976376776587014086
c4: -36162563490522
c5: 13860
Y0: -162033630917183209833724693720279332
Y1: 9661052375909867827
[/CODE]All polys above score 7e-14:
[ATTACH]13756[/ATTACH]

I havn't done any testsieving.

Here's the best from CADO:
[code]skew: 28549120.0
c0: 31695133714159212627102779580357485588240640
c1: -7140263814077019281755963680358035664
c2: -138241522083103402667415875346
c3: 17364522990413160912171
c4: 91780801517494
c5: 209520
Y0: -93609149816794578396382623932473153
Y1: 5902366602845958906530717[/code]
Stats: a1 run from 1 to 2.31M, P = 5000000 (default for c180). Default root-opt was 900 hits (ugh), reducing it between stages 1 and 2 produced an error so I let it root-opt for 2 days. CADO 2.1.1. 2.2.0 has better poly select, I'll try that next time (for less time, now that I know more about poly-select parameter choice).

I have not test-sieved this, nor have I tried msieve to find out E-score; the methods for producing E-score are different, so the scores are not close to comparable. CADO's e-score is 6.50e-12.

A quick test-sieve: 15e/32, alim=rlim=199M (chosen by factmsieve), q=33.1 and 33.4M (two threads), q-range 500 per thread. All sieving done by ggnfs (CADO refers to the source of the poly, not the sieving)

CADO .324 rel/sec, yield 3.3 EDIT: sec/rel, not rel/sec!
Gimarel .272 sec/rel, yield 2.8
Curtis .274 sec/rel, yield 2.6
Wombatman .273 sec/rel, yield 2.0

So, 5 min of test sieve is only enough to show the CADO poly is not competitive at small q. CADO doesn't sieve below alim by default, so I wonder if the polys CADO produces are better at higher q.

Wombatman's score 7.36 poly appears to yield very poorly, so a more thorough test-sieve between gimarel and my own poly appears in order.

It looks to me that your CADO poly is by far the best poly, achieving a nearly 20% better rels/second, and a better yield to boot. Why do you say it's not competitive?

That would be because I wrote rel/sec, rather than seconds per relation as ggnfs reports. Whoops! (fixed via edit)

[QUOTE=VBCurtis;423637]That would be because I wrote rel/sec, rather than seconds per relation as ggnfs reports. Whoops! (fixed via edit)[/QUOTE]

That was my best guess :smile: It's still quite curious that it achieves the best rel/q despite the worst rel/sec. Curious indeed.

I revisited these polys with some test sieving at q=67M and 100M over a range of 1e4 q. Most seem close in performance. The CADO poly just wasn't ever in the mix, it always lagged in speed.

Will post them in the NFS@Home queue management thread.

It is absolutely not worth making decisions on yield from a region as narrow as 500Q, you're just measuring fluctuations in the distribution of prime ideals.

1e4 range is the minimum one to use for answers you can trust, and I would still be wary about deciding between a yield of 4.2rel/Q and 3.8rel/Q from so narrow a sieve. I *would* be willing to believe that one polynomial sieves faster than another given a 0.01sec/rel difference on a 1e4-range experiment.

3366.2124 done and in the database; I've done 1000@1e7 ECM on the C126 from 3366.2125, which is probably enough, and leave the GNFS to someone else.

I've cracked several easy composites and now stopped at i2132 C167 which resist 7200@43e6.