Calibration of GNFS with 32-bit LP on 14e/15e

[fivemack]

C178 (aliquot 8352:1764), e=1.194e-13

Sieved most of 45M-135M with 15e, 32-bit LP, alim=rlim=135M

295833904 relations, 260362638 unique

Clique removal starts with 90079615 relations and 87419001 unique ideals
Ends with 66639026 relations and 66080931 ideals
2-way merge gets 37025791 relation sets and 36467696 unique ideals
Full merge fails at density=120

Trying with lower densities, since ramp-up and ramp-down times are a bit long just to throw more sieving at it; average yield here was 2.3 million relations per hour. So would be inclined to target 340M for next C178/32/15e.

[fivemack]

Density 110 gave the same 'found 256154 cycles, need 7678292' message at the full-merge stage as density 120, so I queued up an extra 15MQ (hopefully an extra 50M relations)

However, density 100 did produce a matrix

2-way merge gets 37025791 relation sets and 36467696 unique ideals
Full merge gets 17477896 cycles, weight is about 1748071808 (100.02/cycle)
ETA (three threads i7/2600) is around 373 hours, so in this case it's definitely worth waiting for the extra relations ...

[fivemack]

This is XYYXF_133_125, E=3.628e-13

334275782 relations is not enough to generate a matrix at target density 120, though is enough for 110.

td   cycles
110  10586238  ETA 76 hours
100  10932238
 90  11348238
 80  11846238
 70  12484238

So I'd want to aim for 360M relations for the next 170-digit 14e 32LP; the first post in this thread indicated that 270M is enough for 15e, so I'll take that in mind when deciding which queue to submit the next 170-digit GNFS to. At last, habemus data!

[fivemack]

At target density 120, adding more and more relations produces final matrix size

340M	10124877
360M	9575206
380M	9247366
400M	8942603
420M	8709511
440M	two attempts, 10532521 w=87.41
460M	three attempts, 11293415 w=66.44
467M	four attempts, 10235253 w=90.61

[VBCurtis]

This work shows 32-bit lp is reasonable for GNFS-165 and up, if not lower. I've done a little trial-sieving to locate the 32-33 bit transition on 15e, and it is also much lower than standard procedure previously indicated. However, I have never solved a 10M+ matrix; do the larger matrices produced by using 33-bit lp outweigh the time saved in sieving?

Can we have NFS@home run a 15e/33 GNFS-178? I believe 33-bit will require 5% less sieving, or better, at this size.

I suppose the quantity of data produced by 33 bit jobs may not be worth the single-digit sieve-time savings, but I think it's valuable to find the correct cutoffs if speed is the only concern. It may be possible to build matrices for 33-bit jobs at this size with well under 600M relations.

For the smaller case, I am about to try a SNFS-220 with 31 bit lp, to compare with a SNFS-219/30 bit I just completed.

[fivemack]

Originally Posted by fivemack

Density 110 gave the same 'found 256154 cycles, need 7678292' message at the full-merge stage as density 120, so I queued up an extra 15MQ (hopefully an extra 50M relations)

However, density 100 did produce a matrix

2-way merge gets 37025791 relation sets and 36467696 unique ideals
Full merge gets 17477896 cycles, weight is about 1748071808 (100.02/cycle)
ETA (three threads i7/2600) is around 373 hours, so in this case it's definitely worth waiting for the extra relations ...

Of course it took ten weeks for the extra sieving to get queued up and done; so although the 355.8M (308.8M unique) relations produced a 12.4M matrix at density 120 (with an ETA of about 120 hours, on admittedly faster hardware - 4 threads i7/4790), running the original matrix would have finished eight weeks ago.

Never ask for extra sieving (as opposed to widening the range of an existing sieving job): the corollary of this is not to move numbers to queued-for-post-processing or post-processing stage until you actually have the timer counting down from an acceptable ETA on the box where you're running the linear algebra. Asking for extra sieving on the same polynomial under a different project name also appears to confuse the relation-accounting.

[fivemack]

C260_131_97 (SNFS 260.3; 15e, 32): 318.7 million relations (249.8 unique) isn't enough to get to the clique-removal stage of filtering.