Correct.
Your reported SALPMAX 4294967296, SRLPMAX 4294967296 were the indication that 2^32 large prime bounds were used. Sometimes referred to as a 32bit project (e.g. NFS @ Home has a whole spectrum from 29 to 33bit, and they, too, [URL="http://escatter11.fullerton.edu/nfs/crunching.php"]use this lingo[/URL]). For 6,373 and for 3,613, we were using 2^33 large prime bounds but ~2 times lower FAMAX/FRMAX of 2^28 (vs your 476900000) and starting from 20000000. I've seen similar settings work well in other hands too, so I didn't improvise too much. I remember some threefour year old trailblazing projects from Greg where he reached the limit, too (only 15e siever was available at the time), so they sieved extra on the other side. It turned out to be quite redundant, but it was the best what could be done for that project at that time. You'd need to page down for quite a while in the Factoring (or possibly in Cunninghams') forum to find notes from that project. So sieving on both sides was deemed to be generally avoided. 
In general, what's the strategy most people take for really large GNFS/SNFS projects? Sieve the same q values (e.g. q = 1e7 through q = 2^311) with different large prime bounds, e.g. 29 <= lpbr <= 33? Something else?
Is this described in any documentation/papers anywhere? Thanks! 
Sieving the same region with different largeprime bounds is a complete waste of time.
There is a limit to the size of jobs that can be efficiently done with the current versions of the current tools; that limit is rather smaller than the size of some jobs than have been done (that is, those jobs were done inefficiently). Fixing the tools to allow larger largeprime bounds is not trivial but is what would need doing; fixing them to allow larger sieving areas is much less trivial but would also be useful. 
[QUOTE=fivemack;330307]Sieving the same region with different largeprime bounds is a complete waste of time.
There is a limit to the size of jobs that can be efficiently done with the current versions of the current tools; that limit is rather smaller than the size of some jobs than have been done (that is, those jobs were done inefficiently). Fixing the tools to allow larger largeprime bounds is not trivial but is what would need doing; fixing them to allow larger sieving areas is much less trivial but would also be useful.[/QUOTE] Increasing the max large primes is a trial change in the siever. You just need to comment out the check. Did you mean the factor base size? I just compiled the siever with the change and sieved with 34 bit large primes. I ran the results through a filtering run in msieve. There were no errored relations. To prove there were 34bit large primes in there, I sieved again with 33 bit large primes and there was less relations. I repeated with a bound of 40 and same results. More relations and no errors. 
The concern is that every extra bit in large primes means you need about twice as many relations in order to converge to a matrix. The current postprocessing code we use has a hard limit of 4G relations, and we're 25% of the way there right now with 33bit LPs.
Msieve can handle up to 48bit large primes, an arbitrary number of them per relation, but cannot handle a dataset with 10^13 relations... 
[QUOTE=henryzz;330343]Increasing the max large primes is a trial change in the siever. You just need to comment out the check.[/quote]
No, I meant max large primes  the MPQS at present only works with 96bit cofactors and you need larger cofactors if you want sensibly to use three larger primes. (though this is a matter for experiment; maybe two 35bit large primes give useful yield) Doing the uniqifying and easysingletonremoval passes before giving the data to msieve gets the size down enough to allow maybe one more bit of large primes. 
[QUOTE=jasonp;330347]The concern is that every extra bit in large primes means you need about twice as many relations in order to converge to a matrix. The current postprocessing code we use has a hard limit of 4G relations, and we're 25% of the way there right now with 33bit LPs.
Msieve can handle up to 48bit large primes, an arbitrary number of them per relation, but cannot handle a dataset with 10^13 relations...[/QUOTE] If we are 25% there now with 33bit, we should be able to hopefully do 35bit. What causes this limit is it extendable? 
For the record, I wasn't asking whether using different large prime bounds was the most efficient way to do large jobs. I was only asking what's *possible*. :)
Currently once you hit q=2^301, that's too high for GGNFS to handle, and you need a different strategy. If your polynomial isn't good enough to get all the needed relations by q=2^301, what strategies are possible to get to the linear algebra stages? Or are factorizations of these large GNFS/SNFS jobs simply impossible at this point with the tools available? 
[QUOTE=henryzz;330357]If we are 25% there now with 33bit, we should be able to hopefully do 35bit.
What causes this limit is it extendable?[/QUOTE] Msieve refers to a relation during the postprocessing by its line number in the save file, and this is currently a 32bit integer. It's no big deal to make it a larger integer, but the assumption of 32bit relation numbers is everywhere in a complex codebase. It's in file formats, hashtables, etc. 
[QUOTE=fivemack;330355]No, I meant max large primes  the MPQS at present only works with 96bit cofactors and you need larger cofactors if you want sensibly to use three larger primes.
(though this is a matter for experiment; maybe two 35bit large primes give useful yield) Doing the uniqifying and easysingletonremoval passes before giving the data to msieve gets the size down enough to allow maybe one more bit of large primes.[/QUOTE] That is in the v4 siever. v5 has a second mpqs routine(mpqs3.c) that looks like it does upto 148 bits. There is also a built in ecm and p1 routine that is used if you provide a parameter file. I worked out the parameter file format but didn't make much headway against getting optimal parameters(I imagine we could improve the speed of numbers we are currently factoring by at least 10% with this if we work out parameters. Potentially we could gain much more). I now see there is a program ecmstat that might help with this. I think the v5 siever can do more than we are asking of it currently. If we run out of prime special Qs for a number we can always sieve some composite ones with the f version of the siever as well(from memory 1/3 of the speed). 
The CADO code also includes a tremendously fast ECM/P+1 implementation for up to 126 bit operands (two 64bit words max) that Alex reports is even faster than the MPQS code in the Franke/Kleinjung sievers.

All times are UTC. The time now is 08:12. 
Powered by vBulletin® Version 3.8.11
Copyright ©2000  2020, Jelsoft Enterprises Ltd.