Experimental lasieve4_64, compiled with MinGW-w64!

[Dan Ee]

I just happen to gain some interest in NFS and tried to compile "experimental lasieve4_64" for Windows, and I think I did it successfully.

The lasieve4 source code that I use as starting point is http://ggnfs.svn.sourceforge.net/vie...l/lasieve4_64/

Some notes for reproducing:
1) mingw-w64-bin-x86_64-20130104.7z from http://www.drangon.org/mingw/
2) MSYS-20111123.zip from http://sourceforge.net/projects/ming...0%2832-bit%29/
3) http://www.mpir.org/mpir-2.6.0.tar.bz2
4) My modified lasieve4_64 attached.
5) The build instruction is just like as in INSTALL file, except that I have renamed "athlon64" directory to "asm" so you do not need to create a link from asm to athlon64.

Summary of my changes:
1) In asm files, replace ".type foo,@function" with ".def foo; .scl 2; .type 32; .endef"
2) Insert __attribute__((sysv_abi)) at function prototypes of assembly routines. This may be the trick that a lot of people do not know.
3) Search for "long" in all C files, replace with "long long" if 64 bits are needed, else replace with "int"
4) For all fopen() calls, insert "b" (for binary) into the flags field. Some nasty crlf translation is happening without the binary flag, causing factor base save file corruption. My opinion is that file I/O API should not deal with crlf as special case, hence all fopen gets the binary flag.
5) Fixes in if.c, aligned malloc handling.
6) gmp.h -> mpir.h (optional, you may rename mpir.h to gmp.h instead)
7) There are parts that I have detected possible problems if compiled (for example, long is 32bit in Windows), but that part of the code is not compiled due to #ifdef. I have put in #error at those places just to make sure.

My compiled versions:
1) core2 (up to SSSE3)
2) westmere (up to SSE4.2)
3) ivybridge (up to AVX)

Ops, just found out that there is size restriction on attachments, so I put the Windows binaries here temporarily: http://storenow.net/my/?f=090e5e09e1...1a5d2a17528e8f
SHA1 (of lasieve4_win.zip): E6A40FE889C93016ED3496642AD2DFA29F102FC8

[prgamma10]

Does this version have ASM routines for 64-bit Windows?

[Dan Ee]

Yes, the assembly routines are included without changes.
__attribute__((sysv_abi)) makes gcc generate code that calls assembly routine using the Linux calling convention.

[jasonp]

If you can express your changes in patch form, please coordinate with frmky (Greg) to massively increase the throughput of NFS@Home :)

[pinhodecarlos]

Originally Posted by jasonp

If you can express your changes in patch form, please coordinate with frmky (Greg) to massively increase the throughput of NFS@Home :)

I already warned Greg about this thread, I think it was yesterday.

[henryzz]

I have just tested these and the speed is comparable to the binaries I compiled in http://mersenneforum.org/showthread.php?t=17963
Well done for getting this working. Several have tried and failed. I can now use windows pretty much exclusively which is very helpful.

[PhilF]

On my i7 Nehalem system, these binaries are much faster than the ones Henry mentioned (almost twice as fast). It appears the Core 2 and the Westmere versions both run at about the same speed on it.

[henryzz]

I have discovered a problem with these binaries.
If you provide them with a command line like:
gnfs-lasieve4I11e.exe -v -a nfs.job -f 605000 -c 2500 -o rels2.dat -n 2
then you get output like

Ignoring 8 trailing command line args
Warning:  lowering FB_bound to 4294967295.
FBsize 0+0 (deg 4), 92937+0 (deg 1)

If you move the -a nfs.job to the end like:
gnfs-lasieve4I11e.exe -v -f 605000 -c 2500 -o rels2.dat -n 2 -a nfs.job
then it runs properly.
It seems to be breaking from the while loop early. I can't see in the source why.
Myself I can just use this correctly. yafu unfortunately uses the problem form.

[bsquared]

Originally Posted by henryzz

Myself I can just use this correctly. yafu unfortunately uses the problem form.

Can you compile YAFU?

If so, change the sprintf on line 576 of nfs_sieving.c from

sprintf(syscmd,"%s%s -%c %s -f %u -c %u -o %s -n %d",
			thread_data->job.sievername, VFLAG>0?" -v":"", *side,
			fobj->nfs_obj.job_infile, thread_data->job.startq, 
			thread_data->job.qrange, thread_data->outfilename, thread_data->tindex);

to

sprintf(syscmd,"%s%s -f %u -c %u -o %s -n %d -%c %s ",
			thread_data->job.sievername, VFLAG>0?" -v":"", thread_data->job.startq, 
			thread_data->job.qrange, thread_data->outfilename, thread_data->tindex,
			*side, fobj->nfs_obj.job_infile);

[henryzz]

Theoretically I probably could. I have had huge problems in the past compiling things in windows. I can't be bothered fiddling to compile all the necessary components(ecm msieve mpir etc).
Currently I am using factmsieve.pl which is just about sufficient for my needs.
It is worth sorting this anyway. I will just use the old script until then.

[Dubslow]

Originally Posted by henryzz

I can now use windows pretty much exclusively which is very helpful.

Nooooooooooooo.



(As soon as Dota 2 is ported, I will be able to use GNU-Linux exclusively )