mersenneforum.org  

Go Back   mersenneforum.org > Factoring Projects > NFS@Home

Reply
 
Thread Tools
Old 2015-01-29, 10:03   #12
fivemack
(loop (#_fork))
 
fivemack's Avatar
 
Feb 2006
Cambridge, England

143508 Posts
Default Another data point

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 is offline   Reply With Quote
Old 2015-01-29, 13:23   #13
fivemack
(loop (#_fork))
 
fivemack's Avatar
 
Feb 2006
Cambridge, England

143508 Posts
Default 8352_1764: back into the pot

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 ...

Last fiddled with by fivemack on 2015-01-30 at 16:23
fivemack is offline   Reply With Quote
Old 2015-01-31, 13:04   #14
fivemack
(loop (#_fork))
 
fivemack's Avatar
 
Feb 2006
Cambridge, England

23×797 Posts
Default 170 digits, 14e

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.

Code:
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 is offline   Reply With Quote
Old 2015-02-04, 23:18   #15
fivemack
(loop (#_fork))
 
fivemack's Avatar
 
Feb 2006
Cambridge, England

23·797 Posts
Default Over-sieving results for XYYXF_133_125

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

Code:
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
fivemack is offline   Reply With Quote
Old 2015-02-06, 05:06   #16
VBCurtis
 
VBCurtis's Avatar
 
"Curtis"
Feb 2005
Riverside, CA

106238 Posts
Default

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.

Last fiddled with by VBCurtis on 2015-02-06 at 05:09 Reason: fixed 500M -> 600M, and noted GNFS178/32bit already done in this thread
VBCurtis is online now   Reply With Quote
Old 2015-04-12, 07:13   #17
fivemack
(loop (#_fork))
 
fivemack's Avatar
 
Feb 2006
Cambridge, England

23×797 Posts
Default

Quote:
Originally Posted by fivemack View Post
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.

Last fiddled with by fivemack on 2015-04-12 at 07:14
fivemack is offline   Reply With Quote
Old 2016-01-05, 09:37   #18
fivemack
(loop (#_fork))
 
fivemack's Avatar
 
Feb 2006
Cambridge, England

23×797 Posts
Default Another data point

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.
fivemack is offline   Reply With Quote
Reply

Thread Tools


Similar Threads
Thread Thread Starter Forum Replies Last Post
GNFS targets which need more ECM XYYXF XYYXF Project 295 2017-10-27 12:38
3,697+ (GNFS 220.9) pinhodecarlos NFS@Home 0 2014-12-24 19:13
3,766+ (GNFS 215.5) pinhodecarlos NFS@Home 34 2014-04-01 21:27
64-bit gnfs-lasieve* mklasson Factoring 81 2012-05-06 21:30
c97 GNFS not possible? Andi47 Msieve 5 2009-01-26 18:19

All times are UTC. The time now is 22:08.

Wed Dec 2 22:08:43 UTC 2020 up 83 days, 19:19, 2 users, load averages: 3.90, 2.14, 2.31

Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2020, Jelsoft Enterprises Ltd.

This forum has received and complied with 0 (zero) government requests for information.

Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.2 or any later version published by the Free Software Foundation.
A copy of the license is included in the FAQ.