Nonstandard lasieve binaries

[fivemack]

A couple of years ago I built 15e with the check for lpb<=33 simply removed (having looked through to see that the large-prime-part was only ever handled by gmp utilities, so wasn't getting trimmed at 64 bits); it worked fine, but I didn't try it on any examples big enough for 34-bit large primes to be needed.

Something that intrigued me in the RSA200 writeup was that the lambda values were 3.6 rather than 2.6; do the 15f and 15g sievers actually allow more than two large primes? I remember Alex's and Thorstein's talks at Nancy in 2008 mentioning several-large-primes variants, but I don't know if they're included in the released source.

IIRC there was one pair of sievers which had a very short diff between them, the only difference was that Q was allowed to be larger than 2^32.

[henryzz]

where is the source for the 15f and 15g sievers? i can't find it

[Batalov]

Ah, it was courtesy of Alex, actually. Here.
lasieve5-20081105.tar.bz2 (233.4 KB, 42 views)
15e and 15f have the <=33-bit warning in the code (which can be #if 0'd).
15g doesn't. 15g uses mpz_t for the special_q and more changes.
This source uses SCHED_TOL of 2.0; the first thing to try is to use SCHED_TOL of 1.2 plus padding of 48.

I wonder if there exists an even newer one.
_________

By merging the sources and then debugging of what will be broken, 16e/g may (?) be built (totally unsure about the assembly code compatibility). 17*-sievers will not work in the current form (the internal implementation of many structures is in 16-bit integers; even if this is changed, the sievers will become impractical because the memory footprint would immediately double).

[Andi47]

Just for curiosity: Do 16g (or even 17g) sievers exist? (No, I don't have the ressources to actually use them in a meaningful way, I'm just curious.)

[henryzz]

Originally Posted by Batalov

Ah, it was courtesy of Alex, actually. Here.
lasieve5-20081105.tar.bz2 (233.4 KB, 42 views)
15e and 15f have the <=33-bit warning in the code (which can be #if 0'd).
15g doesn't. 15g uses mpz_t for the special_q and more changes.
This source uses SCHED_TOL of 2.0; the first thing to try is to use SCHED_TOL of 1.2 plus padding of 48.

I wonder if there exists an even newer one.
_________

By merging the sources and then debugging of what will be broken, 16e/g may (?) be built (totally unsure about the assembly code compatibility). 17*-sievers will not work in the current form (the internal implementation of many structures is in 16-bit integers; even if this is changed, the sievers will become impractical because the memory footprint would immediately double).

Thanks
I booted into linux and successfully compiled 12e.
I had to type:
make libgmp-aux.a
before it would compile though

12f or 12g won't compile for me without further changes
any ideas? is the bug reproducable for you?

[Andi47]

Originally Posted by henryzz

Thanks
I booted into linux and successfully compiled 12e.
I had to type:
make libgmp-aux.a
before it would compile though

12f or 12g won't compile for me without further changes
any ideas? is the bug reproducable for you?

Do I understand correctly that the difference between 15e and 15g is that 15g is able to sieve with lpb's bigger than 33? Is there any other difference / advantage of the 1?g-sievers?

If not - what purpose would a 12g siever have? GNFSing 90-digit composites with BIG large primes for testing purpose?
(I'd expect that lpb > 33 would become relevant in regions of 190+ digits where 16g (or even 17g if it exists) sievers will also become relevant...)

[Batalov]

I've never built this particular source. I've also been reading on and off the cweave'd commented source and honestly didn't get anywhere close to understanding.

Because it was not a very trivial excercise (.w -> .tex -> .pdf, I've done it a year ago and now my pdftex doesn't run, so I cannot reproduce), I will post this PDF to SourceForge. It has all the comments that the .c code doesn't.

I cannot answer any questions about this code.

[Batalov]

Ok, a few read-only notes from a nightly build. (everyone who wants to build this source is on their own.)

FWIW, this source builds as is (with a working CWEB).
It is a CWI-oriented source: CWI-poly in, CWI-relations out.
I hacked the GGNFS-poly input and a few patches (right into .w files, of course; the intermediate .[ch] files are erased with every build).
16* binaries do not build with L1_BITS 15 (ther's a TODO tag in the parts of the asm code; no wonder; I did solve it earlier for 16e, it remains to be seen if it will work for 16g).
15f needs additional -DVERY_LARGE_Q to build.

So, they do build; now the research question is: what do we get back from sieving the two-three different RSA-200 at different bit-levels?

[Batalov]

A bit of humor, if you can call it that.
Here's an obfuscated hack for SCHED_TOL

 
was 
#define SCHED_TOL 2
 
replace by
#define SCHED_TOL 48+1.2
 
<and then, it is used in expression>
allocate= rint(SCHED_TOL*n_i*j_per_strip*log(log(fbp_ub)/log(fbp_lb)));

Don't do it at home.