mersenneforum.org The lasieve5 latest code and patches
 Register FAQ Search Today's Posts Mark Forums Read

2012-05-08, 22:56   #1
frmky

Jul 2003
So Cal

22·33·19 Posts

Quote:
 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.
Attached Files
 lasieve5patches.tar.gz (8.4 KB, 217 views)

 2013-03-14, 16:57 #2 Batalov     "Serge" Mar 2008 Phi(4,2^7658614+1)/2 217108 Posts The lasieve5 latest code and patches 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.
2013-03-14, 17:31   #3
henryzz
Just call me Henry

"David"
Sep 2007
Cambridge (GMT/BST)

131668 Posts

Quote:
 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.

 2013-03-14, 19:36 #4 ryanp     Jun 2012 Boulder, CO 22·53 Posts Do you happen to have pre-built 64-bit Linux binaries that you can share, Henry? Thanks!
 2013-03-14, 21:14 #5 PhilF     Feb 2005 Colorado 10001000102 Posts Man, that would be wonderful (64-bit)!
 2013-03-14, 22:26 #6 henryzz Just call me Henry     "David" Sep 2007 Cambridge (GMT/BST) 2·53·23 Posts 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.
 2013-03-16, 15:06 #7 ryanp     Jun 2012 Boulder, CO 22×53 Posts 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: Code: 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: Code: 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?
2013-03-16, 15:59   #8
henryzz
Just call me Henry

"David"
Sep 2007
Cambridge (GMT/BST)

2·53·23 Posts

Quote:
 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: Code: 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: Code: 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.

2013-03-16, 18:43   #9
Batalov

"Serge"
Mar 2008
Phi(4,2^7658614+1)/2

23·5·229 Posts

Quote:
 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.

2013-03-16, 19:30   #10
henryzz
Just call me Henry

"David"
Sep 2007
Cambridge (GMT/BST)

2·53·23 Posts

Quote:
 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?

 2013-03-16, 20:08 #11 Batalov     "Serge" Mar 2008 Phi(4,2^7658614+1)/2 23×5×229 Posts 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): Code:  *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. Last fiddled with by Batalov on 2013-03-16 at 20:30

 Similar Threads Thread Thread Starter Forum Replies Last Post pinhodecarlos Prime Gap Searches 170 2019-12-10 19:33 ATH GMP-ECM 10 2012-07-29 17:15 ATH GMP-ECM 7 2012-01-07 18:34 Batalov Factoring 6 2011-12-27 22:40 davieddy Lounge 0 2011-01-21 19:29

All times are UTC. The time now is 20:17.

Fri Nov 27 20:17:36 UTC 2020 up 78 days, 17:28, 3 users, load averages: 2.08, 2.02, 1.81

This forum has received and complied with 0 (zero) government requests for information.

Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.2 or any later version published by the Free Software Foundation.
A copy of the license is included in the FAQ.