Compiling YAFU for Windows using mingw

[James Heinrich]

Originally Posted by VictordeHolland

Here you go
YAFU r373 (wip branch)
Win64 compiled on a C2D (SSE2).

This is the most recent Windows version I could find, but it's a couple years old now. Notably it predates a fix in r379 with regards to yafu.ini being ignored that I think might be affecting me. I made a half-hearted attempt at following the instructions here for compiling my own, but failed. Would somebody be able to build a current version of YAFU for me, please?

[charybdis]

Here's an attempt. Compiled with SSE4.1, apologies to anyone with really old computers. If your CPU supports AVX-512 there should be a substantial speedup but you'll need to ask someone else for a binary.

[James Heinrich]

Thanks!

[Madpoo]

Originally Posted by charybdis

Here's an attempt. Compiled with SSE4.1, apologies to anyone with really old computers. If your CPU supports AVX-512 there should be a substantial speedup but you'll need to ask someone else for a binary.

Hi Charybdis - I tried running this on a system with Xeon E5649 processors (Nehalem generation, Westmere EP class).

I can run it and do a simple test factor like "yafu 121" and get basic factors.

Then I tried to run a tune() and it crashed. Is this compiled with any options that wouldn't work on that CPU?

James and I have been testing things out in regards to odd things that the 1.34 version is doing on the Primenet server and hoping this newer build works around it, so hopefully we can get a Nehalem (or even just Xeon "Core") build with those options.

Nehalem does have SSE 4.1 (and 4.2) so I don't think that would be it...

Here's a link to the details for that CPU:
Nehalem / Westmere EP info

FYI, when I run this on my own laptop, with i7-7700, it seems just fine.

[charybdis]

Originally Posted by Madpoo

Hi Charybdis - I tried running this on a system with Xeon E5649 processors (Nehalem generation, Westmere EP class).

I can run it and do a simple test factor like "yafu 121" and get basic factors.

Then I tried to run a tune() and it crashed. Is this compiled with any options that wouldn't work on that CPU?

James and I have been testing things out in regards to odd things that the 1.34 version is doing on the Primenet server and hoping this newer build works around it, so hopefully we can get a Nehalem (or even just Xeon "Core") build with those options.

Nehalem does have SSE 4.1 (and 4.2) so I don't think that would be it...

Here's a link to the details for that CPU:
Nehalem / Westmere EP info

FYI, when I run this on my own laptop, with i7-7700, it seems just fine.

Whoops, I used GMP-ECM and msieve libraries that I compiled a few months ago on the same machine, and of course those might be incompatible with older CPUs - I suspect the binary I posted won't work on anything older than Skylake.

Might try again when I've got a bit of time...

[charybdis]

I have access to a Xeon E5645 (also Nehalem) but I don't have admin rights and there isn't a compiler installed, so I had to compile on a newer system and test on the old one. I couldn't get r387 to work - when running factor() it always crashed when trying to find Brent special forms, although siqs() was fine - but r379 appears to be OK.

Looks like changes made to yafu since r379 might have broken some things for older systems?

[bsquared]

Originally Posted by charybdis

I have access to a Xeon E5645 (also Nehalem) but I don't have admin rights and there isn't a compiler installed, so I had to compile on a newer system and test on the old one. I couldn't get r387 to work - when running factor() it always crashed when trying to find Brent special forms, although siqs() was fine - but r379 appears to be OK.

Looks like changes made to yafu since r379 might have broken some things for older systems?

It's possible, yes. It's getting harder to test on all possible system/compiler combinations as I check in new code. I just tested r388 (branch wip) on a linux system with a E5-2697 v3 chip built with NFS=1 USE_AVX2=1 USE_BMI2=1 and that seems to be working fine. I'll see if I can build for windows and test that.

Are you using visual studio or MSYS2/mingw64 for your builds (or something else)?

[charybdis]

Please ignore the r379 binary I posted above: it suffers from the issue described in this thread where GMP-6.2.0 incompatibility causes a crash on inputs divisible by small primes. I'll see if r383 works, if not I'll try r379 with an older GMP.

Originally Posted by bsquared

Are you using visual studio or MSYS2/mingw64 for your builds (or something else)?

I'm using MSYS2/mingw64.

[Madpoo]

Originally Posted by charybdis

I have access to a Xeon E5645 (also Nehalem) but I don't have admin rights and there isn't a compiler installed, so I had to compile on a newer system and test on the old one. I couldn't get r387 to work - when running factor() it always crashed when trying to find Brent special forms, although siqs() was fine - but r379 appears to be OK.

Looks like changes made to yafu since r379 might have broken some things for older systems?

(LOL - I just saw your follow up post saying not to use that build... but I'll keep my reply here just for fun):

Hmm... I got a little farther when running tune() on the server in question, but it did still error out at this part:

starting SIQS on c70: 6470287906463336878241474855987746904297564226439499503918586590778209

==== sieving in progress (1 thread):   12224 relations needed ====
====           Press ctrl-c to abort and save state           ====
overriding small TF cutoff of 20 to 15

I have versions of gmp-ecm and ggnfs that seem to be working fine with an older version of YAFU, so I don't think the error is coming from those, and I don't think the tune() process got to calling any of those external libraries yet anyway.

If push came to shove and I had to compile it, I could probably fire up a test VM on that same server and get VS installed on it...

Any tips on compiling it, if I had to go the long way to get there?

[charybdis]

Not having any success unfortunately. Trying to build r383 with either GMP-6.2.0 or 6.1.2 fails with

arith/monty.c:36:17: error: redefinition of '_umul128'
   36 | __inline uint64 _umul128(uint64 a, uint64 b, uint64 *c)
      |                 ^~~~~~~~
In file included from C:/msys64/mingw64/x86_64-w64-mingw32/include/intrin.h:41,
                 from include/types.h:38,
                 from include/yafu.h:50,
                 from arith/monty.c:26:
C:/msys64/mingw64/x86_64-w64-mingw32/include/psdk_inc/intrin-impl.h:979:18: note: previous definition of '_umul128' was here
  979 | unsigned __int64 _umul128(unsigned __int64 a, unsigned __int64 b, unsigned __int64 *hi)
      |                  ^~~~~~~~
arith/monty.c: In function '_umul128':
arith/monty.c:39:12: warning: unused variable 'lo' [-Wunused-variable]
   39 |     uint64 lo = (uint64)result;
      |            ^~
arith/monty.c: In function 'fp_montgomery_calc_normalization':
arith/monty.c:51:12: warning: unused variable 'bits' [-Wunused-variable]
   51 |     int x, bits;
      |            ^~~~
arith/monty.c:51:9: warning: unused variable 'x' [-Wunused-variable]
   51 |     int x, bits;
      |         ^
arith/monty.c: In function 'mulmod128':
arith/monty.c:382:9: warning: variable 's' set but not used [-Wunused-but-set-variable]
  382 |  uint64 s[3];
      |         ^
arith/monty.c: In function 'sqrmod128':
arith/monty.c:493:9: warning: variable 's' set but not used [-Wunused-but-set-variable]
  493 |  uint64 s[3];
      |         ^
arith/monty.c: In function '_umul128':
arith/monty.c:41:1: warning: control reaches end of non-void function [-Wreturn-type]
   41 | }
      | ^
make: *** [Makefile.mingw:286: arith/monty.o] Error 1

I managed to build r379 with GMP-6.1.2, but on the Nehalem it crashes on SIQS jobs larger than ~70 digits (same for the last binary I posted - edit: Madpoo I see you found this too). It's entirely possible that building for a Nehalem on a Kaby Lake requires more care than I've been taking; I'm giving up for now.

[bsquared]

First off, sorry for all of the difficulty here. I have not been in the habit of checking for successful builds on windows when checking in code, especially for older systems. It is also no fun that mingw builds take *so long*.

I've attached a build of the most recent version with only SSE4.1 activated in yafu. The underlying gmp and ecm builds I believe used -march=k8 and msieve had no special -march.

This version has better management of -logfile. In the tests I've done if you specify -logfile NUL or -logfile "" then neither factor.log nor session.log are written at all.

Also for some reason the system() calls that yafu uses to run external ecm and ggnfs no longer work. They all immediately return error code 127 (command can not be found or executed), even though the paths are all correct. Even trying something like system("pwd") fails with code 127. I can't yet figure out what's going on there. So, this version won't do either of those things. The attached yafu.ini sets the ecm_ext crossover fairly large, so the internal ecm is able to take care of things. I don't think your primary intention is to factor 100+ digit numbers anyway.

With those caveats, hopefully this works.