Thinking about lasieve5

[Batalov]

The time has likely come to use lasieve5 (or maybe solicit an even newer source branch from authors). lasieve5 source builds without a hitch with CWEB and works off the box - with CWI-poly in, CWI-relations out.

[henryzz]

Originally Posted by Batalov

The time has likely come to use lasieve5 (or maybe solicit an even newer source branch from authors). lasieve5 source builds without a hitch with CWEB and works off the box - with CWI-poly in, CWI-relations out.

How much effort would it be to convert lasieve5 to use ggnfs polys and relations?
Is it any more than just changing the input and output of the siever? We have code from lasieve4(before and after conversion to ggnfs?) which we can use for comparison.

[Batalov]

It is not much to patch for the CWI-to-GGNFS conversion. (And the code can be readily borrowed from the lasieve4 which had already passed this change.)

But there are also quite a few patches - to name a few, to decrease the memory requirements, to avoid infinite loops in redu2.c and in the assembly portion for the I16 siever... - there's much more burden in testing the final evolution of the code and eventual "support" (that is, suppose the siever is deployed at NFS@Home or elsewhere and then a thousand computers are hung, someone will have to debug, and this is time-consuming). If those are not applied, the siever will sort of work but will probably hang frequently as early versions of lasieve4I16e did (and a brief inspection showed that the lasieve5 code is vulnerable in the same places where lasieve4 was). It would be nice to do it just once if code newer than lasieve5 (dated 2009) is available.

[fivemack]

I've just emailed Thorsten

[fivemack]

(I have of course asked his permission to forward this)

Is there a newer version of lasieve around than the lasieve5 dated November 2008 which you supplied to Alex Kruppa and is attached at http://mersenneforum.org/showpost.ph...9&postcount=28 ?

It is identical to the latest version I can find.

mersenneforum is gearing up to try to do some >200-digit GNFS job, and the version of lasieve4 that we've been using in the past is not coping well with the very high-skew polynomials that Jason's latest polynomial optimisation tends to produce.

If the lattice basis for a special q does not fit into 31 bits this special q is discarded. If the number of discarded special q gets too high for your project you might modify the function reduce2 in redu2.w to keep more special q (although the sieving for them will be less efficient). This does not really solve the problem, but adapting the code to high skewness is more difficult and you probably do not want to wait until I finish the new version (>=1 year I expect).
In the case that you want to use the I=15 version, you could try to use the I=16 version with parameter -J 13 (so sieving area 2^16*2^13 instead
of 2^15*2^14) which will probably discard less special q.

[Batalov]

Then, I'll start the lasieve5_64 branch (this time with all .w files) - next to lasieve4_64 in experimental/ and CWEB the code into it to make it more accessible for tinkering. I'll start transferring known patches: GGNFS formatting, SCHED_TOL, redu, and mitigation of idiopathic infinite loops.

[henryzz]

Originally Posted by Batalov

Then, I'll start the lasieve5_64 branch (this time with all .w files) - next to lasieve4_64 in experimental/ and CWEB the code into it to make it more accessible for tinkering. I'll start transferring known patches: GGNFS formatting, SCHED_TOL, redu, and mitigation of idiopathic infinite loops.

Is it worth mailing known bugs in both lasieve4 and lasieve5 to Thorsten along with fixes? I assume he doesn't know them if they are in both.