The lasieve5 latest code and patches

[frmky]

Originally Posted by henryzz

So the lasieve5f application is gnfs-lasieve4I16e from lasieve5 which you have modified to input and output like ggnfs? What is the difference to the 16e siever we have been using for ages? Have you been able to compile the f or g variants(not your system of lettering) from lasieve5? Are the changes you made available in the svn or is the boinc binary the only one available?

Yep. Primary changes for users are the ability to sieve larger q and lower memory usage. Neither f nor g compile out of the box. Both fail in linking due to undefined functions. I have spent no time trying to diagnose it. I've sent the patches to Serge to place in the SVN, but I don't think he's had time to do so. So I'll place them here.

The compile currently only works on Linux. Make sure cweb is installed on your computer. Then, download the original source and extract it. Then from the file attached, apply the patch lasieve5_ggnfs.patch and compile with
make gnfs-lasieve4I16e
and you should have a GGNFS compatible binary. If you wish to create a BOINC binary (which you generally wouldn't) then also apply the patch lasieve5_boinc.patch to add in the BOINC API.

[Batalov]

I have copied this message from a place that is probably somewhat hard to find (the B200 factoring thread).

This siever variant is coded in CWEB (unlike ggnfs-lasieve4 that was pre-ctangle'd, and as a consequence has no apparent comments). One would need CWEB installed.

[henryzz]

Originally Posted by Batalov

I have copied this message from a place that is probably somewhat hard to find (the B200 factoring thread).

This siever variant is coded in CWEB (unlike ggnfs-lasieve4 that was pre-ctangle'd, and as a consequence has no apparent comments). One would need CWEB installed.

If I remember correctly it didn't quite compile from source for me. I had to do a minor modification or two. Certainly for the f and g variants.

[ryanp]

Do you happen to have pre-built 64-bit Linux binaries that you can share, Henry? Thanks!

[PhilF]

Man, that would be wonderful (64-bit)!

[henryzz]

I am running something on windows until Sunday. I should be able to boot into linux and get it then. I need to have a fiddle with the logging in my version of the code. I enabled some logging for the ecm which people probably won't want. I think it is completely ggnfs compatible but am not completely certain. I haven't used it with a script. It will have the 33-bit large primes bound removed.

[ryanp]

So I've managed to get a 64-bit build of lasieve5 by installing cweb, grabbing the original source, applying lasieve5patches.tar.gz, and running "make gnfs-lasieve4I16e". Thanks for the help so far!

But...

Something is clearly still broken. It's choking on a degree-7 poly that was sieving just fine before. For example:

n: 1781056819551587311167253765397471748765469171240870505462407060867649014317194406461520462336804039779111642284118679577665056707252469899060086198662541274397501623097455995734118041976126321856178468908894950778559560264712879791194008065472089
c7: 58956
c0: 25
Y1: -89838575310635468195373605518341064453125
Y0: 68907938065037080137715194116000115064832
skew: 0.33      
rlim: 250000000
alim: 250000000
lpbr: 33
lpba: 33
mfbr: 67
mfba: 96
rlambda: 2.6
alambda: 3.6
q0: 1041833576
qintsize: 12
#q1:1041833588

which works with a stock gnfs-lasieve4I16e build from head, now fails with:

Error: the polynomials don't have a common root:
c0: 25
Y0: 68907938065037080137715194116000115064832
Y1: -89838575310635468195373605518341064453125
n: 1781056819551587311167253765397471748765469171240870505462407060867649014317194406461520462336804039779111642284118679577665056707252469899060086198662541274397501623097455995734118041976126321856178468908894950778559560264712879791194008065472089

Any idea what it's choking on? Are there other patches that need to be applied too?

[henryzz]

Originally Posted by ryanp

So I've managed to get a 64-bit build of lasieve5 by installing cweb, grabbing the original source, applying lasieve5patches.tar.gz, and running "make gnfs-lasieve4I16e". Thanks for the help so far!

But...

Something is clearly still broken. It's choking on a degree-7 poly that was sieving just fine before. For example:

n: 1781056819551587311167253765397471748765469171240870505462407060867649014317194406461520462336804039779111642284118679577665056707252469899060086198662541274397501623097455995734118041976126321856178468908894950778559560264712879791194008065472089
c7: 58956
c0: 25
Y1: -89838575310635468195373605518341064453125
Y0: 68907938065037080137715194116000115064832
skew: 0.33      
rlim: 250000000
alim: 250000000
lpbr: 33
lpba: 33
mfbr: 67
mfba: 96
rlambda: 2.6
alambda: 3.6
q0: 1041833576
qintsize: 12
#q1:1041833588

which works with a stock gnfs-lasieve4I16e build from head, now fails with:

Error: the polynomials don't have a common root:
c0: 25
Y0: 68907938065037080137715194116000115064832
Y1: -89838575310635468195373605518341064453125
n: 1781056819551587311167253765397471748765469171240870505462407060867649014317194406461520462336804039779111642284118679577665056707252469899060086198662541274397501623097455995734118041976126321856178468908894950778559560264712879791194008065472089

Any idea what it's choking on? Are there other patches that need to be applied too?

The patch is limited to degree 6. People rarely use above this.
On lines 654 and 657 of the patch change && (token[1] <= '6') to && (token[1] <= '10')
This will allow upto degree 10 polys. I am pretty sure that this will work it is a little bit of a mess of pointers to pointers so I am not certain. c is not my best language.

Lines 638 and 639 might need changing as well from:
+ *A = xmalloc(8*sizeof(**A)); /* plenty o' room. */
+ *B = xmalloc(8*sizeof(**B));

to

+ *A = xmalloc(10*sizeof(**A)); /* plenty o' room. */
+ *B = xmalloc(10*sizeof(**B));
Not sure.
Degree 7 should work without the second change. Anyone feel like correcting my c code? Looks like I should get to making binaries today rather than tomorrow.

[Batalov]

Originally Posted by henryzz

change && (token[1] <= '6') to && (token[1] <= '10')
This will allow upto degree 10 polys. I am pretty sure that this will work ...

I am sorry but this clearly will not work. Put it down to '8' - as the great master wrote it.

[henryzz]

Originally Posted by Batalov

I am sorry but this clearly will not work. Put it down to '8' - as the great master wrote it.

I suspected I was being optimistic. As a learning exercise what would need to be changed to support more? Is it that xmalloc?

[Batalov]

No, there's simply no such thing as '10'.

Secondarily, to that - there's no need. The siever will sieve uselessly slow above degree 8. Even with deg 8, pretty much any poly is useless. (There are very rare exceptions.) For example, I've recently played with one semi-suitable upcoming candidate from 6LM extensions, it has an obvious quartic of degree ~240 (i.e. a very long job), or an octic of degree 193. The latter is painfully slow. I am not sure if it is useable (as opposed to quartic-240).


P.S. ...and of course xmalloc should be for 8+1. I haven't looked recently in the lasieve5 code, but I thought that Greg transferred all lasieve4_64 patches to lasieve5. Here's how the corresponding code looks in lasieve4_64 (since 2008):

  *adeg = *bdeg = 0;
  *A = xmalloc(9*sizeof(**A)); /* plenty o' room. */
  *B = xmalloc(9*sizeof(**B));
  for (i=0; i<9; i++) {
    mpz_init_set_ui((*A)[i], 0);
    mpz_init_set_ui((*B)[i], 0);
  }
#..............
      } else if ((token[0]=='c') && (token[1] >= '0') && (token[1] <= '8')) {
        mpz_set_str((*A)[token[1]-'0'], value, 10);
        *adeg = MAX(*adeg, token[1]-'0');
      } else if ((token[0]=='Y') && (token[1] >= '0') && (token[1] <= '8')) {
        mpz_set_str((*B)[token[1]-'0'], value, 10);
        *bdeg = MAX(*bdeg, token[1]-'0');
# obviously, this had only changes from 6 to 8, but no additional control for the presense ':' 
# Note: a line "c10: 1" (in .poly-file) would be silently accepted, but the coefficient would be put into the c1

See also.