For the C104 that Luigi is doing, I would use factLat.pl and nfs2ms.pl rather than going through all the complicated stuff. nfs2ms.pl creates all the files for msieve, too.

For GNFS: What composit length is the crossover between using gnfs-lasieve4I[b]12e[/b] and 13e?

[quote=Andi47;155442]For GNFS: What composit length is the crossover between using gnfs-lasieve4I[B]12e[/B] and 13e?[/quote]
110 digits according to factmsieve.pl

Some more datapoints for lp/siever choice
 

I've been doing a bit of my own tuning for this.

One very obvious observation: starting at Q=alim and going backwards (rather than starting at Q=alim/2 and going forwards as factLat.pl does) seems to get you to a factorisation more quickly.

[b]For GNFS[/b]

12/13 crossover does seem to be around 110 digits.

At 144 digits, lp=28 using 13e is worse than lp=29 using 14e, which is itself worse than lp=28 using 14e.

28/13 beats 28/14 at 138 digits, so the crossover there is around 140

29/14 beats 28/14 quite soundly by 150 digits.

[b]For SNFS[/b]

On quartics it makes sense to go to /15 very early on (2^860+1 S208 is helped by using /15)

30/14 appears to be better than 29/14 by about S210, though rather worse at S200.

For 10^263-1, initial small experiments suggests 32/15 and 31/15 are very comparable, and since the linalg for lp=32 takes four times as long I'd use the latter.

Andi47, you put "4.7 million?" for the number of relations needed for a C100 GNFS. According to schickel, it is around 3.8 million. When I did a C100 and oversieved to 5.2 million, msieve had trouble building a matrix.

[QUOTE=10metreh;155778]Andi47, you put "4.7 million?" for the number of relations needed for a C100 GNFS. According to schickel, it is around 3.8 million. When I did a C100 and oversieved to 5.2 million, msieve had trouble building a matrix.[/QUOTE]

Thanks. These 4.7M were more or less a wild guess. I corrected it and attached the new file to this posting.

BTW: Data marked with a "?" are guesses based on interpolations, where I don't have enough / any data yet.

[quote=Andi47;155787]Thanks. These 4.7M were more or less a wild guess. I corrected it and attached the new file to this posting.

BTW: Data marked with a "?" are guesses based on interpolations, where I don't have enough / any data yet.[/quote]

In the end I knocked the number of relations down to 4 million and it worked. A tip: never oversieve too much.

I managed to download, compile and run GGNFS on my Linux64 box.

Thank you all for the help! :smile:

Luigi

P.S. is a yield of 0.0077 sec/rel a "good" parameter?:huh:

[QUOTE=ET_;155806]I managed to download, compile and run GGNFS on my Linux64 box.[/QUOTE]

Where did you download the source, what version? I'm having trouble compiling the ggnfs-0.77.1.tar.gz from sourceforge on my Linux64 box getting these errors:

[CODE]echo "#define GGNFS_VERSION \"0.77.1\"" > include/version.h
make -C src
make[1]: Entering directory `/home/jeffg/ggnfs/src'
gcc -I../include -O3 -fomit-frame-pointer -Wall -march=core2 -c
blanczos64.c
blanczos64.c: In function ‘MultB64’:
blanczos64.c:316: warning: pointer targets in initialization differ in
signedness
blanczos64.c: In function ‘MultB_T64’:
blanczos64.c:469: warning: pointer targets in initialization differ in
signedness
/tmp/ccyfRMZS.s: Assembler messages:
/tmp/ccyfRMZS.s:164: Error: `(%rdx,%ecx,2)' is not a valid base/index
expression
/tmp/ccyfRMZS.s:167: Error: `8*1(%rdx,%ecx,2)' is not a valid
base/index expression
/tmp/ccyfRMZS.s:167: Error: `8*2(%rdx,%ecx,2)' is not a valid
base/index expression
/tmp/ccyfRMZS.s:167: Error: `8*3(%rdx,%ecx,2)' is not a valid
base/index expression
/tmp/ccyfRMZS.s:167: Error: `8*4(%rdx,%ecx,2)' is not a valid
base/index expression
/tmp/ccyfRMZS.s:167: Error: `8*5(%rdx,%ecx,2)' is not a valid
base/index expression
/tmp/ccyfRMZS.s:167: Error: `8*6(%rdx,%ecx,2)' is not a valid
base/index expression
/tmp/ccyfRMZS.s:169: Error: `(%rsi,%eax,8)' is not a valid base/index
expression
...
/tmp/ccgdcQdx.s:55976: Error: `8*n(%rbx,%eax,8)' is not a valid
base/index expression
/tmp/ccgdcQdx.s:55976: Error: `8*n(%rbx,%eax,8)' is not a valid
base/index expression
make[1]: *** [blanczos64.o] Error 1
make[1]: Leaving directory `/home/jeffg/ggnfs/src'[/CODE]

So the errors seem to come from the blancsoz64 source file which as
inline assembler. Do I need to so something special with GCC to
assemble this?

Jeff.

Batalov posted in [URL="http://www.mersenneforum.org/showpost.php?p=154007&postcount=71"]another thread[/URL], that he has added a -R (resume) option and an input sanity check to the siever (version 328). Are there win32 binaries (for P4 and/or C2D) available of gnfs-lasieve4I12e .... 4I15e, version 328?

edit: I just got an "issue" myself, which caused a windows error message, and turned out to be a typo in my input:

[code]n 171715153617185465051393022673714527931465270135551225634357302947311904186640760284113383777747947192749639705628979
skew: 261187.54
Y0 -34809139703073288415331
Y1 2359110901579
c0 3824914116375045584368825974840
c1 15238950334340823938379382
c2 -87184131588771861153
c3 -433560750171960
c4 330570356
c5 3360
rlim: 4000000
lim: 4000000
lpbr: 27
lpba: 27
rlambda: 2.6
alambda: 2.6
mfbr: 50
mfba: 50
[/code]

The "a" of alim was missing, thus causing a fatal crash of the siever (this was a version which is (much?) older than 328, so it would be nice if someone could post a (link to a) windows binary of the sievers.)

Edit2: and the colon between n and the number was missing. *grrr* (*wants an option for msieve to output ggnfs-formatted polys*)

Ok so I found the latest trunk code:
[url]http://ggnfs.svn.sourceforge.net/viewvc/ggnfs/[/url]

I was able to compile this code now. Thanks.