Running GGNFS

[henryzz]

What modifications do i need to make to the svn source to make it compile on 64-bit ubuntu?
Have links been posted to the fully 64-bit code on the forum?

[Andi47]

Originally Posted by Jeff Gilchrist

Serge updated GGNFS in SVN to improve the -R resume feature and also added the updated Windows VC project files I made to automatically build lasieve4I15e and lasieve4I16e. Links to download the latest version below:

GGNFS Windows 32bit revision 331 from SVN compiled with GMP 4.2.4
optimized for Core 2 systems (Visual Studio 2008):
http://gilchrist.ca/jeff/ggnfs/ggnfs...in32-core2.zip

GGNFS Windows 64bit revision 331 from SVN compiled with GMP 4.2.4
optimized for Core 2 systems (Visual Studio 2008):
http://gilchrist.ca/jeff/ggnfs/ggnfs...in64-core2.zip

Jeff.

Can please somebody compile windows (win32) binaries of the latest version (I think it's version 336) optimized for Pentium 4?

[Jeff Gilchrist]

Originally Posted by Andi47

Can please somebody compile windows (win32) binaries of the latest version (I think it's version 336) optimized for Pentium 4?

Done. I have now posted 32bit Pentium 4, 64bit Core 2, and 64bit Opteron/AMD64 binaries here:
http://gilchrist.ca/jeff/factoring/

Jeff.

[Andi47]

Originally Posted by Jeff Gilchrist

Done. I have now posted 32bit Pentium 4, 64bit Core 2, and 64bit Opteron/AMD64 binaries here:
http://gilchrist.ca/jeff/factoring/

Jeff.

Thanks.

Please add a 32 bit Core 2 binary too. (Core 2's (and possibly opterons?) have been sold with 32 bit Win XP for quite a long time.)

[Jeff Gilchrist]

Originally Posted by Andi47

Please add a 32 bit Core 2 binary too. (Core 2's (and possibly opterons?) have been sold with 32 bit Win XP for quite a long time.)

There are no Core2 specific optimizations in the 32bit code, so the Pentium4 version should also the best one to use for Core 2. Same thing with Opterons, only 64bit specific optimizations available. I don't have 32bit Core2 or Opteron systems to test if the Pentium4 optimized code or the generic C code would be faster (I'm assuming P4).

You also need to test out the software to see which one in practice is faster. On my Core2 system the 32bit P4 lattice siever is faster than the 64bit Core2 version, other 64bit binaries are faster than the 32bit ones. So I generally use the 32bit sievers, and 64bit everything else in the GGNFS package. YMMV

Jeff.

[Andi47]

Thanks for the info.

Just one more question (I would need this for a ubasic script): Is it possible to specify the values given by -f and -c (start and size of the special q range) in the poly file and just start the siever with "gnfs-lasieve4I12e -a input.poly -o output.out"?

(it seems that ubasic won't start with a string variable (which is concatenated from several variables) as parameter (like doscmd "gnfs-lasieve4I12e"+<parameter string>), but it would start when the statement is something like doscmd "gnfs-lasieve4I12e -a input.poly -o output.out".)

[Batalov]

Originally Posted by Andi47

Just one more question (I would need this for a ubasic script): Is it possible to specify the values given by -f and -c (start and size of the special q range) in the poly file and just start the siever with "gnfs-lasieve4I12e -a input.poly -o output.out"?

Yes.
q0: <number> line in the file overrides -f (even if supplied from command line)
qintsize: <number> line in the file overrides -c ( --"--"-- )
The familiar perl scripts add that to the *.poly file and call it a *.job file.
You can follow this tradition and keep the *.poly file immutable for reading, create a *.job file, then call the line from ubasic. Ubasic will be your perl.

[Andi47]

Originally Posted by Batalov

Yes.
q0: <number> line in the file overrides -f (even if supplied from command line)
qintsize: <number> line in the file overrides -c ( --"--"-- )
The familiar perl scripts add that to the *.poly file and call it a *.job file.
You can follow this tradition and keep the *.poly file immutable for reading, create a *.job file, then call the line from ubasic. Ubasic will be your perl.

thanks.

I have changed the script now, and the (ubasic) line which is *supposed* to start gnfs-lasieve4I1?e reads:

 3600	if N<10^111 then doscmd "gnfs-lasieve4I12e -a POLY1.JOB -o r0.re1":goto 3710

N is a c97, and when I replace the goto statement by "stop", then the program does a "break in 3600", so the "if" condition is true.

The .job file (which is created by the script) reads:

n: 2732584592441395021720194901150787772285943502010496085503949065307202194967953137523967798489349
skew: 30459.08
Y0 -5289287989229448818
Y1 8453105473
c0 24850561794115389152026569
c1 1273750895887494774892
c2 -71491689305975523
c3 -3107085344298
c4 41476208
c5 660
rlim: 1200000 
alim: 1000000 
lpbr: 25 
lpba: 25 
mfbr: 45 
mfba: 45 
rlambda: 2.4 
alambda: 2.4 
q0: 1000000 
qintsize: 50000

So I wonder why this script won't start gnfs-lasieve4I12e.

(edit: I actually know the factors of this c97, I just use it for testing, because it is about the smallest GNFS that msieve will do (poly search, postprocessing).)

[10metreh]

Originally Posted by Andi47

n: 2732584592441395021720194901150787772285943502010496085503949065307202194967953137523967798489349
skew: 30459.08
Y0: -5289287989229448818
Y1: 8453105473
c0: 24850561794115389152026569
c1: 1273750895887494774892
c2: -71491689305975523
c3: -3107085344298
c4: 41476208
c5: 660
rlim: 1200000 
alim: 1000000 
lpbr: 25 
lpba: 25 
mfbr: 45 
mfba: 45 
rlambda: 2.4 
alambda: 2.4 
q0: 1000000 
qintsize: 50000

You need to add colons where I have done.

[Andi47]

Originally Posted by 10metreh

You need to add colons where I have done.

I added the colons - the siever still won't start.

n: 2732584592441395021720194901150787772285943502010496085503949065307202194967953137523967798489349
skew: 30459.08
Y0: -5289287989229448818
Y1: 8453105473
c0: 24850561794115389152026569
c1: 1273750895887494774892
c2: -71491689305975523
c3: -3107085344298
c4: 41476208
c5: 660
rlim: 1200000 
alim: 1400000 
lpbr: 25 
lpba: 25 
mfbr: 45 
mfba: 45 
rlambda: 2.4 
alambda: 2.4 
q0: 1400000 
qintsize: 50000

Edit: when I open a dos window and type

gnfs-lasieve4I12e -a POLY1.JOB -o r0.re1

then the sieving starts properly (IIRC it has even started without the colons when I tested starting from the command line yesterday), so the .JOB file is apparently not the problem.

[Andi47]

Originally Posted by Andi47

I added the colons - the siever still won't start.

Heureka!!

I found the problem: the ubasic command "doscmd" only accepts filenames in 8+3 format, so doscmd "gnfs-lasieve4I12e.exe" will probably get truncated and therefore doesn't work.

I have now renamed my copies of gnfs-lasieve4I1?e.exe to nfs4I1?e.exe, changed the ubasic statement accordingly, and now it works. (test run in progress...)