mersenneforum.org Advice for large GNFS jobs?
 Register FAQ Search Today's Posts Mark Forums Read

2013-07-23, 02:18   #45
swellman

Jun 2012

2·3·479 Posts

Quote:
 Originally Posted by lorgix I'm no expert, but my experiments indicate that you could get away with using r/alim of 2^26-2 and Code: lpbr: 30 lpba: 30 mfbr: 60 mfba: 60 rlambda: 2.7 alambda: 2.7 if you sieve over alim/3 through alim. If that is not a good idea, for whatever reason; let me know.
Again I thank you for your insights. I did a lot more test sieving, focusing on r/alim of 67M. It did improve performance. The best case is the set of parameters you suggested, which gives the minimum estimated sieving time and a yield of about 1.57 rels/spec_q.

All looks good but for one thing - for lpba/r of 30, I need ~93M rels which equates to ~60M spec_q. If I am to run spec_q from alim/3 to alim, I need alim of about 90M.

Or am I missing something? Can I safely run spec_q to values far greater than alim?

For laughs I did run some trials using the 16e siever - great yields but terribly slow. I take it GNFS of 169 is too small for this siever. What's the minimum, 180?

2013-07-23, 07:10   #46
lorgix

Sep 2010
Scandinavia

3×5×41 Posts

Quote:
 Originally Posted by WraithX Hmmm, I've never tried to compile ggnfs before. Can it be compiled in MinGW64? I'm using the binaries that had the Windows ASM improvements provided by Dan Ee over in this thread. Actually, looking at it again, he used MinGW64 and gives instructions on how to compile it. What needs to be changed to allow lpbr/lpba > 33? Also, do you have any thoughts on my question of how to compare the timing (sec/rel) between all my test sieves? Or anyone else, what is the best way to compare these timings? Should I scale the timings the same way I scaled the relations and then perhaps add them up to do a comparison? Or should I just add up the numbers as they are to compare them?
I don't actually know what needs to be changed, or how to do it. But IIRC someone on here said it shouldn't be very hard. Something is limited to 32 bits and it doesn't have to be.
I don't know what the best way to compare timings is. I would certainly scale them to account for the fact that larger lpb needs more rels.
Quote:
 Originally Posted by swellman Again I thank you for your insights. I did a lot more test sieving, focusing on r/alim of 67M. It did improve performance. The best case is the set of parameters you suggested, which gives the minimum estimated sieving time and a yield of about 1.57 rels/spec_q. All looks good but for one thing - for lpba/r of 30, I need ~93M rels which equates to ~60M spec_q. If I am to run spec_q from alim/3 to alim, I need alim of about 90M. Or am I missing something? Can I safely run spec_q to values far greater than alim? For laughs I did run some trials using the 16e siever - great yields but terribly slow. I take it GNFS of 169 is too small for this siever. What's the minimum, 180?
I'm sorry, I may have misled you. I thought 67M would be enough. I am kind of a beginner at this still.
I did not think the yield would be that low. My experiments indicated that the yield would be sufficient. I think you need to raise lpba (and also lim) to get a better yield.
I have just assumed that I can not sieve above lim. That could be wrong.
From what I've seen the cut-off for the 16e-siever is about 180.

If I were you I'd raise lpba and try to figure out which region sieves best.

I hope I didn't waste too much of your time. At least now we know for sure 67M is too low.

 2013-07-23, 07:23 #47 VBCurtis     "Curtis" Feb 2005 Riverside, CA 26·3·23 Posts It is my (beginner) understanding that we can sieve above alim, but yield drops off; if we go too far, we find precious few unduplicated relations. If you look at Rich's parameters in the 4708 thread in aliquot forum (link: http://mersenneforum.org/showpost.ph...postcount=2124), you'll see he has alim at 20M, but plans to sieve from 10M to 34M. I'm not sure why he isn't sieving 7-10M, but his plan indicates it's no big deal to sieve even 40% above alim. -Curtis Last fiddled with by VBCurtis on 2013-07-23 at 07:24 Reason: added link
 2013-07-23, 08:33 #48 fivemack (loop (#_fork))     Feb 2006 Cambridge, England 2×29×109 Posts I find that changing alim doesn't change yield-per-relation very much. Sieving above alim is really not an issue, but once you're at 2.5x or 3x alim the yield does start to drop off. Duplication rate is mostly a function of the siever used, but it's obviously a bit difficult to measure in small samples. I used 16e for a 197-digit gnfs and for a 947-bit snfs, I think that's about the middle of its useful range. For C180 or the 249-digit SNFS I'm doing on and off, I'd be on 15e
 2013-07-23, 08:47 #49 henryzz Just call me Henry     "David" Sep 2007 Cambridge (GMT/BST) 5×31×37 Posts In the 64-bit win sievers to remove the 33-bit limit change the 1 to a 0 in the following code snippet: Code:  #if 1 if(max_primebits[i]> 33) { complain("Only large primes up to 33 bits are allowed.\n"); } #endif
2013-07-23, 09:00   #50
fivemack
(loop (#_fork))

Feb 2006
Cambridge, England

11000101100102 Posts

Quote:
 Originally Posted by swellman ... for lpba/r of 30, I need ~93M rels ...
That seems rather a lot of relations to aim for, though I suppose it's a C169; for C150-scale numbers, I aim for 80M raw relations and that's usually enough.

I would always aim on the large side for lpba/r; you don't need twice as many relations for one more bit of large primes (I'd expect 150M usually to suffice at 31-bits, and 250M for 32-bits), particularly with the new faster LA step making big matrices less scary. For a C169 I would definitely use 31-bit lpba/r.

2013-07-23, 09:07   #51
lorgix

Sep 2010
Scandinavia

3×5×41 Posts

Quote:
 Originally Posted by VBCurtis It is my (beginner) understanding that we can sieve above alim, but yield drops off; if we go too far, we find precious few unduplicated relations. If you look at Rich's parameters in the 4708 thread in aliquot forum (link: http://mersenneforum.org/showpost.ph...postcount=2124), you'll see he has alim at 20M, but plans to sieve from 10M to 34M. I'm not sure why he isn't sieving 7-10M, but his plan indicates it's no big deal to sieve even 40% above alim. -Curtis
Quote:
 Originally Posted by fivemack I find that changing alim doesn't change yield-per-relation very much. Sieving above alim is really not an issue, but once you're at 2.5x or 3x alim the yield does start to drop off. Duplication rate is mostly a function of the siever used, but it's obviously a bit difficult to measure in small samples. I used 16e for a 197-digit gnfs and for a 947-bit snfs, I think that's about the middle of its useful range. For C180 or the 249-digit SNFS I'm doing on and off, I'd be on 15e
Thanks, I'm learning a lot here.

How should we be choosing alim then? Or better yet; what is alim? And what are the effects from changing it?

2013-07-23, 12:16   #52
swellman

Jun 2012

54728 Posts

Quote:
 Originally Posted by swellman Have you checked Kamada's site? May be helpful on parameter selection (or not). http://homepage2.nifty.com/m_kamada/math/graphs.htm
I've used the models given on this site for several GNFS jobs in the 150s and low 160s with great success. The site collects data from successful factorizations. I will make the observation that successful =/ optimal.

The parameters for composite of GNFS difficulty d are given by

r/alim = INT(3*10^(d/37+3))

lpbr/a = INT(d/18+21)

mfbr/a = INT(d/5+28)

r/alambda = INT(d/26+21)/10

Pure black box approach to be sure, but a sanity check if nothing else.

Similar formulas are given for SNFS.

 2013-07-23, 17:24 #53 firejuggler     Apr 2010 Over the rainbow 46128 Posts just a piece of advice : a line like Code: msieve151_gpu -v -np1 "stage1_norm=3e24 stage2_norm=7e23 800000,1000000" -nps -t 3 work and severly limit you .ms size. -npr after that is much faster, even if you don't put bond. Last fiddled with by firejuggler on 2013-07-23 at 17:24
2013-07-23, 19:04   #54
VBCurtis

"Curtis"
Feb 2005
Riverside, CA

26×3×23 Posts

Quote:
 Originally Posted by firejuggler just a piece of advice : a line like Code: msieve151_gpu -v -np1 "stage1_norm=3e24 stage2_norm=7e23 800000,1000000" -nps -t 3 work and severly limit you .ms size. -npr after that is much faster, even if you don't put bond.
Restricting stage 1 norm is not helpful for poly quality, and composite sizes that produce more stage 1 output by using threads already produce too much for the -nps step to keep up with. I think all -t 3 does for searches that do -nps at the same time is create more GPU heat.

That said, restricting stage 2 norm in the -nps step seems quite useful- my baseline is to divide the default msieve norm by 18-20. I aim for 200-400 hits per day to do -npr on, but tighter -nps stage2norm may be called for.

 2013-07-23, 19:14 #55 firejuggler     Apr 2010 Over the rainbow 244210 Posts what I meant is " don't forget to put a arsh stage2_norm if you use np1 and nps at the same time" for the composite I work on (the last in the poly thread), it seems that any poly of value has a stage2_norm below 1e+023. If it is higher, it won't produce a *good* poly.

 Similar Threads Thread Thread Starter Forum Replies Last Post ryanp Factoring 69 2013-04-30 00:28 ixfd64 Factoring 3 2012-06-06 08:27 WraithX Msieve 18 2012-05-20 22:19 Syd Aliquot Sequences 7 2011-03-14 18:35 bdodson Factoring 20 2008-11-26 20:45

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

Fri Oct 30 22:43:49 UTC 2020 up 50 days, 19:54, 2 users, load averages: 1.95, 2.06, 1.99