mersenneforum.org  

Go Back   mersenneforum.org > Factoring Projects > YAFU

Reply
 
Thread Tools
Old 2020-06-07, 20:33   #45
James Heinrich
 
James Heinrich's Avatar
 
"James Heinrich"
May 2004
ex-Northern Ontario

BCC16 Posts
Default

Quote:
Originally Posted by VictordeHolland View Post
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?
James Heinrich is offline   Reply With Quote
Old 2020-06-07, 23:03   #46
charybdis
 
Apr 2020

22×23 Posts
Default

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.
Attached Files
File Type: zip yafu-r387-win64.zip (2.86 MB, 22 views)
charybdis is offline   Reply With Quote
Old 2020-06-07, 23:21   #47
James Heinrich
 
James Heinrich's Avatar
 
"James Heinrich"
May 2004
ex-Northern Ontario

22×5×151 Posts
Default

Thanks!
James Heinrich is offline   Reply With Quote
Old 2020-06-08, 02:54   #48
Madpoo
Serpentine Vermin Jar
 
Madpoo's Avatar
 
Jul 2014

2×1,637 Posts
Default

Quote:
Originally Posted by charybdis View Post
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.
Madpoo is offline   Reply With Quote
Old 2020-06-08, 12:48   #49
charybdis
 
Apr 2020

22·23 Posts
Default

Quote:
Originally Posted by Madpoo View Post
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 is offline   Reply With Quote
Old 2020-06-08, 19:43   #50
charybdis
 
Apr 2020

22×23 Posts
Default

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?
Attached Files
File Type: zip yafu-r379-win64-nehalem.zip (2.84 MB, 11 views)
charybdis is offline   Reply With Quote
Old 2020-06-08, 20:05   #51
bsquared
 
bsquared's Avatar
 
"Ben"
Feb 2007

2·5·7·47 Posts
Default

Quote:
Originally Posted by charybdis View Post
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)?
bsquared is offline   Reply With Quote
Old 2020-06-08, 21:07   #52
charybdis
 
Apr 2020

22·23 Posts
Default

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.

Quote:
Originally Posted by bsquared View Post
Are you using visual studio or MSYS2/mingw64 for your builds (or something else)?
I'm using MSYS2/mingw64.
charybdis is offline   Reply With Quote
Old 2020-06-08, 22:32   #53
Madpoo
Serpentine Vermin Jar
 
Madpoo's Avatar
 
Jul 2014

2×1,637 Posts
Default

Quote:
Originally Posted by charybdis View Post
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:
Code:
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?

Last fiddled with by Madpoo on 2020-06-08 at 22:33
Madpoo is offline   Reply With Quote
Old 2020-06-08, 22:35   #54
charybdis
 
Apr 2020

1348 Posts
Default

Not having any success unfortunately. Trying to build r383 with either GMP-6.2.0 or 6.1.2 fails with
Code:
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.

Last fiddled with by charybdis on 2020-06-08 at 22:38
charybdis is offline   Reply With Quote
Old 2020-06-09, 14:01   #55
bsquared
 
bsquared's Avatar
 
"Ben"
Feb 2007

2×5×7×47 Posts
Default

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.
Attached Files
File Type: zip yafu-x64-mingw-r388-sse41.zip (3.22 MB, 13 views)
bsquared is offline   Reply With Quote
Reply

Thread Tools


Similar Threads
Thread Thread Starter Forum Replies Last Post
Guide to compiling YAFU Mr. Odd YAFU 4 2017-04-24 15:40
Compiling YAFU under MinGW wombatman YAFU 10 2016-01-21 19:48
Need help compiling YAFU from SVN. Stargate38 YAFU 14 2016-01-20 21:46
compiling svn 427 for Windows 64 bit. skan NFSNET Discussion 7 2012-04-18 10:30
Compiling ECM 5.0.3 for windows BotXXX Factoring 25 2005-09-13 12:24

All times are UTC. The time now is 01:52.

Sun Sep 20 01:52:37 UTC 2020 up 9 days, 23:03, 0 users, load averages: 1.23, 1.29, 1.22

Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2020, Jelsoft Enterprises Ltd.

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.