Nothing but good news, I am happy too.

Possible bug in SIQS
 

When I try to factor this number, YAFU gets stuck, and just sits there using up my RAM:

[code]05/06/21 11:38:27,
05/06/21 11:38:27, ****************************
05/06/21 11:38:27, Starting factorization of 22483602822411223334855029666009218022270527893974405884054854479042089269501959654874976198718241182261793523272124947
05/06/21 11:38:27, using pretesting plan: deep
05/06/21 11:38:27, using tune info for qs/gnfs crossover
05/06/21 11:38:27, ****************************
05/06/21 11:38:27, rho: x^2 + 3, starting 1000 iterations on C119
05/06/21 11:38:27, prp9 = 405125431
05/06/21 11:38:27, rho: x^2 + 3, starting 1000 iterations on C110
05/06/21 11:38:27, prp10 = 3464048167
05/06/21 11:38:27, rho: x^2 + 3, starting 1000 iterations on C101
05/06/21 11:38:28, rho: x^2 + 2, starting 1000 iterations on C101
05/06/21 11:38:28, rho: x^2 + 1, starting 1000 iterations on C101
05/06/21 11:38:28, pm1: starting B1 = 150K, B2 = gmp-ecm default on C101
05/06/21 11:38:28, current ECM pretesting depth: 0.00
05/06/21 11:38:28, scheduled 30 curves at B1=2000 toward target pretesting depth of 33.67
05/06/21 11:38:28, Finished 30 curves using GMP-ECM method on C101 input, B1=2k, B2=gmp-ecm default
05/06/21 11:38:28, current ECM pretesting depth: 15.18
05/06/21 11:38:28, scheduled 74 curves at B1=11000 toward target pretesting depth of 33.67
05/06/21 11:38:30, Finished 74 curves using GMP-ECM method on C101 input, B1=11k, B2=gmp-ecm default
05/06/21 11:38:30, current ECM pretesting depth: 20.24
05/06/21 11:38:30, scheduled 214 curves at B1=50000 toward target pretesting depth of 33.67
05/06/21 11:38:38, Finished 214 curves using GMP-ECM method on C101 input, B1=50k, B2=gmp-ecm default
05/06/21 11:38:38, pm1: starting B1 = 3750K, B2 = gmp-ecm default on C101
05/06/21 11:38:39, current ECM pretesting depth: 25.33
05/06/21 11:38:39, scheduled 430 curves at B1=250000 toward target pretesting depth of 33.67
05/06/21 11:39:37, Finished 430 curves using GMP-ECM method on C101 input, B1=250k, B2=gmp-ecm default
05/06/21 11:39:37, pm1: starting B1 = 15M, B2 = gmp-ecm default on C101
05/06/21 11:39:39, current ECM pretesting depth: 30.45
05/06/21 11:39:39, scheduled 582 curves at B1=1000000 toward target pretesting depth of 33.67
05/06/21 11:44:26, Finished 582 curves using GMP-ECM method on C101 input, B1=1M, B2=gmp-ecm default
05/06/21 11:44:26, final ECM pretested depth: 33.67
05/06/21 11:44:26, scheduler: switching to sieve method
05/06/21 11:44:26, starting SIQS on c101: 16021105361578943740813272184915150830500965883014131722097771902253017316544048423666824742984602611
05/06/21 11:44:26, random seed: 2350092192
[/code]

Stdout:

[code]starting SIQS on c101: 16021105361578943740813272184915150830500965883014131722097771902253017316544048423666824742984602611
static memory usage:
assigning tdiv_medprimes_32k_avx2 ptr
assigning tdiv_LP_avx2 ptr
assigning resieve_medprimes_32k_avx2 ptr
assigning med_sieveblock_32k_avx2 ptr
assigning nextRoots_32k_sse41 ptr
initial cycle hashtable: 16777216 bytes
initial cycle table: 160000 bytes
factor base: 2452160 bytes
fb bounds
small: 1024
SPV: 36
10bit: 88
11bit: 160
12bit: 296
13bit: 528
32k div 3: 688
14bit: 984
15bit: 1760
med: 2912
large: 16704
large_x2: 31670
all: 122608
start primes
SPV: 251
10bit: 1063
11bit: 2153
12bit: 4177
13bit: 8273
32k div 3: 11083
14bit: 16417
15bit: 32803
med: 57593
large: 393161
large_x2: 786431
all: 3423347
05/06/21 11:44:26, multiplying 0 primes from 3423347 to 1398101[/code]

During this process, the CPU usage suggests only 1 out of 8 threads are running. Looks like a memory leak. Same thing happens with 2.01.

Looks like it is trying to run TLP, which is still somewhat experimental. Set forceDLP=1 in yafu.ini or use -forceDLP on command line. I should set the crossover point much higher.

Bug in SIQS
 

This number crashes YAFU when I try to factor it by SIQS: 18425466191500234497808154837889417418704176536401223

[code]C:\Numbers\aliqueit112>yafu siqs(18425466191500234497808154837889417418704176536401223)
Applying tune_info entry for WIN64 - Intel(R) Core(TM) i5-9300H CPU @ 2.40GHz


YAFU Version 2.01
Built with Microsoft Visual Studio 1928
Using GMP-ECM 7.0.4, Powered by MPIR 3.0.0
Detected Intel(R) Core(TM) i5-9300H CPU @ 2.40GHz
Detected L1 = 32768 bytes, L2 = 8388608 bytes, CL = 64 bytes
Using 1 random witness for Rabin-Miller PRP checks
Cached 664579 primes; max prime is 9999991

===============================================================
======= Welcome to YAFU (Yet Another Factoring Utility) =======
======= bbuhrow@gmail.com =======
======= Type help at any time, or quit to quit =======
===============================================================

>>
starting SIQS on c53: 18425466191500234497808154837889417418704176536401223

==== sieve params ====
n = 54 digits, 177 bits
factor base: 1824 primes (max prime = 33317)
single large prime cutoff: 2165605 (65 * pmax)
double large prime range from 1110022489 to 122254169454
DLP MFB = 1.75
using AVX2 enabled 32k sieve core
sieve interval: 2 blocks of size 32768
polynomial A has ~ 6 factors
using multiplier of 7
using SPV correction of 20 bits, starting at offset 32
trial factoring cutoff at 59 bits

==== sieving in progress ( 8 threads): 1888 relations needed ====
==== Press ctrl-c to abort and save state ====

C:\Numbers\aliqueit112>[/code]factor.log (different number):

[code]05/08/21 12:00:58,
05/08/21 12:00:58, ****************************
05/08/21 12:00:58, Starting factorization of 7441641010125238485066955189052433051233165900729353
05/08/21 12:00:58, using pretesting plan: deep
05/08/21 12:00:58, using tune info for qs/gnfs crossover
05/08/21 12:00:58, ****************************
05/08/21 12:00:58, rho: x^2 + 3, starting 1000 iterations on C52
05/08/21 12:00:58, rho: x^2 + 2, starting 1000 iterations on C52
05/08/21 12:00:58, rho: x^2 + 1, starting 1000 iterations on C52
05/08/21 12:00:58, pm1: starting B1 = 150K, B2 = gmp-ecm default on C52
05/08/21 12:00:58, current ECM pretesting depth: 0.00
05/08/21 12:00:58, scheduled 30 curves at B1=2000 toward target pretesting depth of 17.33
05/08/21 12:00:58, Finished 30 curves using GMP-ECM method on C52 input, B1=2k, B2=gmp-ecm default
05/08/21 12:00:58, current ECM pretesting depth: 15.18
05/08/21 12:00:58, scheduled 33 curves at B1=11000 toward target pretesting depth of 17.33
05/08/21 12:00:59, Finished 33 curves using GMP-ECM method on C52 input, B1=11k, B2=gmp-ecm default
05/08/21 12:00:59, final ECM pretested depth: 17.41
05/08/21 12:00:59, scheduler: switching to sieve method
05/08/21 12:00:59, starting SIQS on c52: 7441641010125238485066955189052433051233165900729353
05/08/21 12:00:59, random seed: 271793012
[/code]

What could be causing this?

Thanks for the report. I found the problem, will update github tonight.

Updated .exe, version 2.02, works for me for both inputs now.

Super slow SIQS job
 

Version 2.02. Is this a bug, or is this number just extra hard to SIQS?

[code]starting SIQS on c102: 587798871182819125651887557119241311895329541639294971678415636172181853499307568869458721586841379351
input from file = 14250842901942372507862702317705623516368553484793953297942917764303309346251613
input to yafu = 587798871182819125651887557119241311895329541639294971678415636172181853499307568869458721586841379351
assigning tdiv_medprimes_32k_avx2 ptr
assigning tdiv_LP_avx2 ptr
assigning resieve_medprimes_32k_avx2 ptr
assigning med_sieveblock_32k_avx2 ptr
assigning nextRoots_32k_sse41 ptr
fb bounds
small: 1024
SPV: 37
10bit: 104
11bit: 160
12bit: 288
13bit: 528
32k div 3: 688
14bit: 976
15bit: 1824
med: 2944
large: 16560
large_x2: 31466
all: 136784
start primes
SPV: 251
10bit: 1093
11bit: 2063
12bit: 4099
13bit: 8233
32k div 3: 11083
14bit: 16477
15bit: 33181
med: 57653
large: 393073
large_x2: 786419
all: 3853613

==== sieve params ====
n = 102 digits, 339 bits
factor base: 136784 primes (max prime = 3853613)
single large prime cutoff: 4194304 (2^22)
double large prime range from 14850333153769 to 1786161908965
DLP MFB = 1.85
allocating 10 large prime slices of factor base
buckets hold 2048 elements
large prime hashtables have 1966080 bytes
using AVX2 enabled 32k sieve core
sieve interval: 12 blocks of size 32768
polynomial A has ~ 13 factors
using multiplier of 1
using SPV correction of 21 bits, starting at offset 37
trial factoring cutoff at 100 bits

==== sieving in progress ( 8 threads): 136848 relations needed ====
==== Press ctrl-c to abort and save state ====
30849 rels found: 29856 full + 993 from 4937 partial, ( 13.40 rels/sec)[/code]Notice how slow it's going (13.4 rels/sec). Definitely not normal for any number, especially <120 digits (my qs/nfs cutoff is about 107 digits).

Also, if I hit Ctrl+C, it acts like it's going to stop and save progress, but then it resumes SIQS, and hitting Ctrl+C after that results in the same thing happening, ad infinitium.

This composite shut down YAFU 2.0:

[CODE]05/23/21 17:33:05,
05/23/21 17:33:05, ****************************
05/23/21 17:33:05, Starting factorization of 103308857900791703352287869169508708227648131233709032715890962117020801090916449
05/23/21 17:33:05, using pretesting plan: normal
05/23/21 17:33:05, using tune info for qs/gnfs crossover
05/23/21 17:33:05, ****************************
05/23/21 17:33:05, rho: x^2 + 3, starting 1000 iterations on C81
05/23/21 17:33:05, rho: x^2 + 2, starting 1000 iterations on C81
05/23/21 17:33:05, rho: x^2 + 1, starting 1000 iterations on C81
05/23/21 17:33:06, pm1: starting B1 = 150K, B2 = gmp-ecm default on C81
05/23/21 17:33:06, current ECM pretesting depth: 0.00
05/23/21 17:33:06, scheduled 30 curves at B1=2000 toward target pretesting depth of 24.92
05/23/21 17:33:06, prp13 = 3872943390781 (curve 6 stg1 B1=2000 sigma=970380758 thread=0)
05/23/21 17:33:06, Finished 5 curves using GMP-ECM method on C81 input, B1=2k, B2=gmp-ecm default
05/23/21 17:33:06, current ECM pretesting depth: 0.00
05/23/21 17:33:06, scheduled 25 curves at B1=2000 toward target pretesting depth of 20.92
05/23/21 17:33:06, Finished 25 curves using GMP-ECM method on C68 input, B1=2k, B2=gmp-ecm default
05/23/21 17:33:06, current ECM pretesting depth: 15.18
05/23/21 17:33:06, scheduled 74 curves at B1=11000 toward target pretesting depth of 20.92
05/23/21 17:33:10, Finished 74 curves using GMP-ECM method on C68 input, B1=11k, B2=gmp-ecm default
05/23/21 17:33:10, current ECM pretesting depth: 20.24
05/23/21 17:33:10, scheduled 30 curves at B1=50000 toward target pretesting depth of 20.92
05/23/21 17:33:11, prp21 = 218508274628377506823 (curve 9 stg2 B1=50000 sigma=2404298899 thread=0)
05/23/21 17:33:11, Finished 8 curves using GMP-ECM method on C68 input, B1=50k, B2=gmp-ecm default
05/23/21 17:33:11, final ECM pretested depth: 20.43
05/23/21 17:33:11, scheduler: switching to sieve method
05/23/21 17:33:11, starting SIQS on c48: 122075503284873779273269492531896208174435532323
05/23/21 17:33:11, random seed: 673297527610098076
05/23/21 17:33:11, prp48 = 122075503284873779273269492531896208174435532323
05/23/21 17:33:11, Total factoring time = 6.8201 seconds
05/23/21 17:34:13,
05/23/21 17:34:13, ****************************
05/23/21 17:34:13, Starting factorization of 273968285551543561558929035118492073468079807518167517816153740095519155430779807
05/23/21 17:34:13, using pretesting plan: normal
05/23/21 17:34:13, using tune info for qs/gnfs crossover
05/23/21 17:34:13, ****************************
05/23/21 17:34:13, rho: x^2 + 3, starting 1000 iterations on C81
05/23/21 17:34:14, rho: x^2 + 2, starting 1000 iterations on C81
05/23/21 17:34:14, rho: x^2 + 1, starting 1000 iterations on C81
05/23/21 17:34:14, pm1: starting B1 = 150K, B2 = gmp-ecm default on C81
05/23/21 17:34:15, c38 = 48704721444132343902237399692386801093
05/23/21 17:34:15, final ECM pretested depth: 0.00
05/23/21 17:34:15, scheduler: switching to sieve method
05/23/21 17:34:15, starting SIQS on c43: 5625086797094281224029938254545114665121299
05/23/21 17:34:15, random seed: 673297527610098076
05/23/21 17:34:15, prp43 = 5625086797094281224029938254545114665121299
05/23/21 17:34:15,
05/23/21 17:34:15, ****************************
05/23/21 17:34:15, Starting factorization of 48704721444132343902237399692386801093
05/23/21 17:34:15, using pretesting plan: normal
05/23/21 17:34:15, no tune info: using qs/gnfs crossover of 95 digits
05/23/21 17:34:15, no tune info: using qs/snfs crossover of 75 digits
05/23/21 17:34:15, ****************************
05/23/21 17:34:15, rho: x^2 + 3, starting 1000 iterations on C38
05/23/21 17:34:15, rho: x^2 + 2, starting 1000 iterations on C38
05/23/21 17:34:15, rho: x^2 + 1, starting 1000 iterations on C38
05/23/21 17:34:15, final ECM pretested depth: 0.00
05/23/21 17:34:15, scheduler: switching to sieve method
05/23/21 17:34:15, starting SIQS on c38: 48704721444132343902237399692386801093
05/23/21 17:34:15, random seed: 16249113150029718896[/CODE]

[QUOTE=richs;578962]This composite shut down YAFU 2.0:
[/QUOTE]

Are you sure you have the latest executable version 2.02? It works for me in every version I can test with 2.02.

[QUOTE=Stargate38;578815]Version 2.02. Is this a bug, or is this number just extra hard to SIQS?
...
Definitely not normal for any number, especially <120 digits (my qs/nfs cutoff is about 107 digits).
[/QUOTE]

Thanks. Yeah, that's a bug... it is using (kind of) a table of parameters for TLP when it shouldn't be. I will upload a new executable tonight.

[QUOTE=Stargate38;578815]
Also, if I hit Ctrl+C, it acts like it's going to stop and save progress, but then it resumes SIQS, and hitting Ctrl+C after that results in the same thing happening, ad infinitium.[/QUOTE]

You need to hit Ctrl+C twice somewhat rapidly. If it doesn't detect a second Ctrl+C soon enough it will resume.

[QUOTE=bsquared;578977]Are you sure you have the latest executable version 2.02? It works for me in every version I can test with 2.02.[/QUOTE]

It works fine with 2.02. I was using 2.0 for that run. Sorry for the trouble.

This C104 locks up my Windows 10 laptop:

[CODE]Applying tune_info entry for WIN64 - Intel(R) Core(TM) i7-10510U CPU @ 1.80GHz


YAFU Version 2.02
Built with Microsoft Visual Studio 1928
Using GMP-ECM 7.0.4, Powered by MPIR 3.0.0
Detected Intel(R) Core(TM) i7-10510U CPU @ 1.80GHz
Detected L1 = 32768 bytes, L2 = 8388608 bytes, CL = 64 bytes
Using 1 random witness for Rabin-Miller PRP checks
Cached 664579 primes; max prime is 9999991

===============================================================
======= Welcome to YAFU (Yet Another Factoring Utility) =======
======= bbuhrow@gmail.com =======
======= Type help at any time, or quit to quit =======
===============================================================

>> siqs (57101411218654014741793559578775000033369536827633664601791874261717679856288033051871376889825129117307)


starting SIQS on c104: 57101411218654014741793559578775000033369536827633664601791874261717679856288033051871376889825129117307
05/24/21 13:27:01, multiplying 0 primes from 4353163 to 1398101[/CODE]

Nothing happens after this and I have to shut it down. Same thing happens with YAFU 2.0. SIQS on this number runs fine on YAFU 1.0.

[QUOTE=richs;578987]This C104 locks up my Windows 10 laptop:


Nothing happens after this and I have to shut it down. Same thing happens with YAFU 2.0. SIQS on this number runs fine on YAFU 1.0.[/QUOTE]


Thanks for the report. This is due to the same bug Stargate reported and will be fixed after I'm able to re-build the project tonight.

[QUOTE=bsquared;578988]Thanks for the report. This is due to the same bug Stargate reported and will be fixed after I'm able to re-build the project tonight.[/QUOTE]

Thanks! I'll get the revised executable when available.

Feedback
 

I've just managed to factor a C190 into PRP26, PRP52 and PRP113 using YAFU 2.02. It took 5 days and 5 hours, but that's down to my awful hardware. I am pleased with this.

If anyone's interested the C190 was 30^128 + 17^128.

Incidentally, I'm sure I've seen something posted about this here before, but what's the largest number of decimal digits YAFU will handle?

I've run partial factorizations of larger numbers (up to 900 digits; sometimes Yafu will crash on numbers >1000 digits, but that was before I upgraded to 2.x), and sometimes I'll get a full factorization, but it's very rare.

Any chance you could post the factors of 30^128+17^128 on FactorDB? It still says it's a C190: [url]http://www.factordb.com/index.php?id=1100000000441930677[/url]

[QUOTE=Stargate38;579083]I've run partial factorizations of larger numbers (up to 900 digits; sometimes Yafu will crash on numbers >1000 digits, but that was before I upgraded to 2.x), and sometimes I'll get a full factorization, but it's very rare.[/QUOTE]
Thank you.

[QUOTE=Stargate38;579083]Any chance you could post the factors of 30^128+17^128 on FactorDB? It still says it's a C190: [url]http://www.factordb.com/index.php?id=1100000000441930677[/url][/QUOTE]
Done.
How many of these Homogeneous Cunninghams should go onto FactorDB? I've got a lot of them that I've not been posting after someone complained about them a few years back.

sigma() appears to be broken
 

[code]05/26/21 10:01:49 v1.35-beta @ math97, System/Build Info:
Using GMP-ECM 7.0.5-dev, Powered by GMP 6.2.0
detected Intel(R) Core(TM) i7-2600 CPU @ 3.40GHz
detected L1 = 32768 bytes, L2 = 8388608 bytes, CL = 64 bytes
measured cpu frequency ~= 3392.250200
using 1 random witnesses for Rabin-Miller PRP checks
. . .
cached 664579 primes. pmax = 9999991


>> sigma(28,1)
56
>> [/code][code]YAFU Version 2.0
Built with GCC 9
Using GMP-ECM 7.0.5-dev, Powered by GMP 6.2.0
Detected Intel(R) Core(TM) i7-2600 CPU @ 3.40GHz
Detected L1 = 32768 bytes, L2 = 8388608 bytes, CL = 64 bytes
Using 1 random witness for Rabin-Miller PRP checks
Cached 664579 primes; max prime is 9999991
. . .
>> sigma(28,1)

ans = 1

>> [/code]

[QUOTE=BudgieJane;579124]
How many of these Homogeneous Cunninghams should go onto FactorDB? I've got a lot of them that I've not been posting after someone complained about them a few years back.[/QUOTE]

Assuming you don't have millions of them they should all go into factordb once you have fully factored them.

I think I once complained about a load of small unfactored ones being added to factordb (I am running a script to factor small number iin factordb, it went to the trouble of factoring them only to find them done when it tried to submit the result).

Chris

Version 2.03 is now available with recently reported bugs fixed. Thanks Stargate38, richs, and EdH!

Great! Thanks for all your work!

Thanks, Ben. Your efforts are most appreciated!

There appears to be a bug in SNFS polynomial selection for (at least) the k*b^n+-1 and b^n+-k forms, for example:
[code]$ yafu "snfs(1281979*2^520+1,615852095139018818180740532155742854813285752039357209617222174313731523072704248288595303399267379211703243385678043310396893565702501281889421988426549324889)"
Applying tune_info entry for LINUX64 - Intel(R) Core(TM) i5-8500 CPU @ 3.00GHz



YAFU Version 2.02
Built with GCC 9
Using GMP-ECM 7.0.5-dev, Powered by GMP 6.2.1
Detected Intel(R) Core(TM) i5-8500 CPU @ 3.00GHz
Detected L1 = 32768 bytes, L2 = 9437184 bytes, CL = 64 bytes
Using 1 random witness for Rabin-Miller PRP checks
Cached 664579 primes; max prime is 9999991

===============================================================
======= Welcome to YAFU (Yet Another Factoring Utility) =======
======= [email redacted] =======
======= Type help at any time, or quit to quit =======
===============================================================

>> nfs: checking for job file - no job file found
nfs: checking for poly file - no poly file found
nfs: commencing nfs on c163: 4400263219768289455901391102252782697640926698321207262715052435471611732354471854022013442787765424467619673990669619452785804526944371659099920107307694926331905
nfs: searching for brent special forms...
nfs: input divides 1281979*2^520 + 1
gen: ========================================================
gen: considering the following polynomials:
gen: ========================================================

Error: M=1361129467683753853853498429727072845824 is not a root of f(x) % N
n = 615852095139018818180740532155742854813285752039357209617222174313731523072704248288595303399267379211703243385678043310396893565702501281889421988426549324889
f(x) = + 1281979*x^4 + 0*x^3 + 0*x^2 + 0*x^1 - -1*x^0
Remainder is 615852095139018818180740532155742854813285752039357209617222174313731523072704248288595303399267379211703243385678043310396893565702501281889421988426549324887

Error: M=20282409603651670423947251286016 is not a root of f(x) % N
n = 615852095139018818180740532155742854813285752039357209617222174313731523072704248288595303399267379211703243385678043310396893565702501281889421988426549324889
f(x) = + 1281979*x^5 + 0*x^4 + 0*x^3 + 0*x^2 + 0*x^1 - -1*x^0
Remainder is 615852095139018818180740532155742854813285752039357209617222174313731523072704248288595303399267379211703243385678043310396893565702501281889421988426549324887

nfs: no snfs polynomial with small coefficients found
nfs: failed to find snfs polynomial![/code]

Those remainders would suggest that YAFU is getting the sign of the constant term wrong. This is 2.02 but it doesn't look like anything relevant has changed in 2.03.

Also, I notice that the required ECM effort is not reduced when an SNFS special form is detected, necessitating a manual change to pretest_ratio.

Sorry if I'm becoming annoying, but the current "-silent" option doesn't act as before. I can (re)write my scripts around it (or use YAFU 1...), but the original YAFU performed thusly:[code]$ ./yafu "sigma(28,1)-28" -silent
28
$[/code]which was easy to capture in a script.

YAFU 2... performs in this manner:[code]$ ./yafu "sigma(28,1)-28" -silent

ans = 28

$[/code]Although I can parse these three lines, it is easier not having to.

Thanks for all your development work.

Thanks Charybdis for catching that silly sign error. Fixed now.
EdH: easy change; done.
Git updated, will re-upload windows binary when I get a chance.

Excellent!

Thanks for all the work!

[QUOTE=bsquared;579662]Thanks Charybdis for catching that silly sign error. Fixed now.
EdH: easy change; done.
Git updated, will re-upload windows binary when I get a chance.[/QUOTE]

Thank you!

[QUOTE=charybdis;579480]
Also, I notice that the required ECM effort is not reduced when an SNFS special form is detected, necessitating a manual change to pretest_ratio.[/QUOTE]

Any chance you'll fix this soon? Or is it a feature rather than a bug?

[QUOTE=charybdis;579680]Thank you!



Any chance you'll fix this soon? Or is it a feature rather than a bug?[/QUOTE]

I think it still works, but a potential gotcha is if -plan is set to something other than normal. If -plan is custom or something else besides normal, then the autofactorer respects that choice and doesn't fiddle with ecm effort.

Does that seem reasonable, or should ecm effort always be reduced from its current setting if a snfs form is detected?

Example:
[CODE]./yafu "factor(2^523*1281979+1)" -v -v -plan normal -threads 32


YAFU Version 2.02
Built with Intel Compiler 1910
Using GMP-ECM 7.0.4, Powered by GMP 6.2.0
Detected Intel(R) Xeon(R) Gold 6248 CPU @ 2.50GHz
Detected L1 = 32768 bytes, L2 = 28835840 bytes, CL = 64 bytes
Using 1 random witness for Rabin-Miller PRP checks
Cached 664579 primes; max prime is 9999991

===============================================================
======= Welcome to YAFU (Yet Another Factoring Utility) =======
======= bbuhrow@gmail.com =======
======= Type help at any time, or quit to quit =======
===============================================================

>> fac: check tune params contained invalid parameter(s), ignoring tune info.
fac: factoring 35202105758146315647211128818022261581127413586569658101720419483772893858835774832176107542302123395740957391925356955622286436215554973272799360858461559410655233
fac: using pretesting plan: normal
fac: check tune params contained invalid parameter(s), ignoring tune info.
fac: no tune info: using qs/gnfs crossover of 100 digits
fac: no tune info: using qs/snfs crossover of 75 digits
input from file = 587798871182819125651887557119241311895329541639294971678415636172181853499307568869458721586841379351
input to yafu = 35202105758146315647211128818022261581127413586569658101720419483772893858835774832176107542302123395740957391925356955622286436215554973272799360858461559410655233
div: primes less than 10000
div: found prime factor = 3
div: found prime factor = 491
div: found prime factor = 619
fmt: 1000000 iterations
98%fmt: performed 36 perfect square checks
rho: x^2 + 3, starting 1000 iterations on C158
rho: found prp9 factor = 812666563
rho: x^2 + 3, starting 1000 iterations on C149
rho: x^2 + 2, starting 1000 iterations on C149
rho: x^2 + 1, starting 1000 iterations on C149
fac: check tune params contained invalid parameter(s), ignoring tune info.
nfs: searching for brent special forms...
nfs: checking a*b^x +/- c for 32 <= x <= 1478
nfs: input divides 1281979*2^523 + 1
fac: ecm effort reduced from 45.85 to 35.66: input has snfs form
[/CODE]

Note I had to put -plan normal in the command line, as I usually run -plan deep (with AVXECM).

[QUOTE=bsquared;579685]Note I had to put -plan normal in the command line, as I usually run -plan deep (with AVXECM).[/QUOTE]

Ah, this must be it - the default yafu.ini has plan=deep. I think this is rather confusing, as I can't see anything in the documentation saying that I need to change this to plan=normal in order for the ECM effort to be reduced for SNFS numbers.

However the different plans behave in this situation, it ought to be clearly documented. Personally I'd have it so that each of the standard plans reduces the effort for SNFS, but plan=custom still uses the exact pretest ratio given, as someone may want to set their own for a specific SNFS number(s). Certainly there should be a reduction for whatever the default plan is.

[QUOTE=charybdis;579693]Ah, this must be it - the default yafu.ini has plan=deep. I think this is rather confusing, as I can't see anything in the documentation saying that I need to change this to plan=normal in order for the ECM effort to be reduced for SNFS numbers.

[/QUOTE]

You are correct, it is undocumented :redface:

[QUOTE=charybdis;579693]
However the different plans behave in this situation, it ought to be clearly documented. Personally I'd have it so that each of the standard plans reduces the effort for SNFS, but plan=custom still uses the exact pretest ratio given, as someone may want to set their own for a specific SNFS number(s). Certainly there should be a reduction for whatever the default plan is.[/QUOTE]

I like that idea.

[QUOTE=kruoli;577152]...[/QUOTE]

The current AVX2 build is not working on my AMD Ryzen 3800X. I guess it is likely the same problem as with the Threadripper. The non-AVX version works fine. I have not tested the current version on my Threadripper yet. I have not tested the old version on the 3800X. Would some of that help?

Instruction set of this CPU:
[CODE]For InfoType 0
CPUInfo[0] = 0xd
CPUInfo[1] = 0x68747541
CPUInfo[2] = 0x444d4163
CPUInfo[3] = 0x69746e65

For InfoType 1
CPUInfo[0] = 0x870f10
CPUInfo[1] = 0x8100800
CPUInfo[2] = 0xfed83203
CPUInfo[3] = 0x178bfbff

For InfoType 2
CPUInfo[0] = 0x0
CPUInfo[1] = 0x0
CPUInfo[2] = 0x0
CPUInfo[3] = 0x0

For InfoType 3
CPUInfo[0] = 0x0
CPUInfo[1] = 0x0
CPUInfo[2] = 0x0
CPUInfo[3] = 0x0

For InfoType 4
CPUInfo[0] = 0x0
CPUInfo[1] = 0x0
CPUInfo[2] = 0x0
CPUInfo[3] = 0x0

For InfoType 5
CPUInfo[0] = 0x0
CPUInfo[1] = 0x0
CPUInfo[2] = 0x0
CPUInfo[3] = 0x0

For InfoType 6
CPUInfo[0] = 0x0
CPUInfo[1] = 0x0
CPUInfo[2] = 0x1
CPUInfo[3] = 0x0

For InfoType 7
CPUInfo[0] = 0x0
CPUInfo[1] = 0x219c91a9
CPUInfo[2] = 0x400004
CPUInfo[3] = 0x0

For InfoType 8
CPUInfo[0] = 0x0
CPUInfo[1] = 0x0
CPUInfo[2] = 0x0
CPUInfo[3] = 0x0

For InfoType 9
CPUInfo[0] = 0x0
CPUInfo[1] = 0x0
CPUInfo[2] = 0x0
CPUInfo[3] = 0x0

For InfoType 10
CPUInfo[0] = 0x0
CPUInfo[1] = 0x0
CPUInfo[2] = 0x0
CPUInfo[3] = 0x0

For InfoType 11
CPUInfo[0] = 0x0
CPUInfo[1] = 0x0
CPUInfo[2] = 0x0
CPUInfo[3] = 0x0

For InfoType 12
CPUInfo[0] = 0x0
CPUInfo[1] = 0x0
CPUInfo[2] = 0x0
CPUInfo[3] = 0x0

For InfoType 13
CPUInfo[0] = 0x7
CPUInfo[1] = 0x340
CPUInfo[2] = 0x340
CPUInfo[3] = 0x0

For InfoType 80000000
CPUInfo[0] = 0x8000001e
CPUInfo[1] = 0x68747541
CPUInfo[2] = 0x444d4163
CPUInfo[3] = 0x69746e65

For InfoType 80000001
CPUInfo[0] = 0x870f10
CPUInfo[1] = 0x20000000
CPUInfo[2] = 0x4023f3
CPUInfo[3] = 0x2fd3fbff

For InfoType 80000002
CPUInfo[0] = 0x20444d41
CPUInfo[1] = 0x657a7952
CPUInfo[2] = 0x2037206e
CPUInfo[3] = 0x30303833

For InfoType 80000003
CPUInfo[0] = 0x2d382058
CPUInfo[1] = 0x65726f43
CPUInfo[2] = 0x6f725020
CPUInfo[3] = 0x73736563

For InfoType 80000004
CPUInfo[0] = 0x2020726f
CPUInfo[1] = 0x20202020
CPUInfo[2] = 0x20202020
CPUInfo[3] = 0x202020

For InfoType 80000005
CPUInfo[0] = 0xff40ff40
CPUInfo[1] = 0xff40ff40
CPUInfo[2] = 0x20080140
CPUInfo[3] = 0x20080140

For InfoType 80000006
CPUInfo[0] = 0x48006400
CPUInfo[1] = 0x68006400
CPUInfo[2] = 0x2006140
CPUInfo[3] = 0x1009140

For InfoType 80000007
CPUInfo[0] = 0x0
CPUInfo[1] = 0x1b
CPUInfo[2] = 0x0
CPUInfo[3] = 0x789

For InfoType 80000008
CPUInfo[0] = 0x3030
CPUInfo[1] = 0x2009005
CPUInfo[2] = 0x700f
CPUInfo[3] = 0x0

For InfoType 80000009
CPUInfo[0] = 0x0
CPUInfo[1] = 0x0
CPUInfo[2] = 0x0
CPUInfo[3] = 0x0

For InfoType 8000000a
CPUInfo[0] = 0x0
CPUInfo[1] = 0x0
CPUInfo[2] = 0x0
CPUInfo[3] = 0x0

For InfoType 8000000b
CPUInfo[0] = 0x0
CPUInfo[1] = 0x0
CPUInfo[2] = 0x0
CPUInfo[3] = 0x0

For InfoType 8000000c
CPUInfo[0] = 0x0
CPUInfo[1] = 0x0
CPUInfo[2] = 0x0
CPUInfo[3] = 0x0

For InfoType 8000000d
CPUInfo[0] = 0x0
CPUInfo[1] = 0x0
CPUInfo[2] = 0x0
CPUInfo[3] = 0x0

For InfoType 8000000e
CPUInfo[0] = 0x0
CPUInfo[1] = 0x0
CPUInfo[2] = 0x0
CPUInfo[3] = 0x0

For InfoType 8000000f
CPUInfo[0] = 0x0
CPUInfo[1] = 0x0
CPUInfo[2] = 0x0
CPUInfo[3] = 0x0

For InfoType 80000010
CPUInfo[0] = 0x0
CPUInfo[1] = 0x0
CPUInfo[2] = 0x0
CPUInfo[3] = 0x0

For InfoType 80000011
CPUInfo[0] = 0x0
CPUInfo[1] = 0x0
CPUInfo[2] = 0x0
CPUInfo[3] = 0x0

For InfoType 80000012
CPUInfo[0] = 0x0
CPUInfo[1] = 0x0
CPUInfo[2] = 0x0
CPUInfo[3] = 0x0

For InfoType 80000013
CPUInfo[0] = 0x0
CPUInfo[1] = 0x0
CPUInfo[2] = 0x0
CPUInfo[3] = 0x0

For InfoType 80000014
CPUInfo[0] = 0x0
CPUInfo[1] = 0x0
CPUInfo[2] = 0x0
CPUInfo[3] = 0x0

For InfoType 80000015
CPUInfo[0] = 0x0
CPUInfo[1] = 0x0
CPUInfo[2] = 0x0
CPUInfo[3] = 0x0

For InfoType 80000016
CPUInfo[0] = 0x0
CPUInfo[1] = 0x0
CPUInfo[2] = 0x0
CPUInfo[3] = 0x0

For InfoType 80000017
CPUInfo[0] = 0x0
CPUInfo[1] = 0x0
CPUInfo[2] = 0x0
CPUInfo[3] = 0x0

For InfoType 80000018
CPUInfo[0] = 0x0
CPUInfo[1] = 0x0
CPUInfo[2] = 0x0
CPUInfo[3] = 0x0

For InfoType 80000019
CPUInfo[0] = 0x0
CPUInfo[1] = 0x0
CPUInfo[2] = 0x0
CPUInfo[3] = 0x0

For InfoType 8000001a
CPUInfo[0] = 0x2
CPUInfo[1] = 0x0
CPUInfo[2] = 0x0
CPUInfo[3] = 0x0

For InfoType 8000001b
CPUInfo[0] = 0x0
CPUInfo[1] = 0x0
CPUInfo[2] = 0x0
CPUInfo[3] = 0x0

For InfoType 8000001c
CPUInfo[0] = 0x0
CPUInfo[1] = 0x0
CPUInfo[2] = 0x0
CPUInfo[3] = 0x0

For InfoType 8000001d
CPUInfo[0] = 0x4121
CPUInfo[1] = 0x1c0003f
CPUInfo[2] = 0x3f
CPUInfo[3] = 0x0

For InfoType 8000001e
CPUInfo[0] = 0x0
CPUInfo[1] = 0x100
CPUInfo[2] = 0x0
CPUInfo[3] = 0x0


CPU String: AuthenticAMD
Model = 1
Family = 15
Extended model = 7
Extended family = 8
CLFLUSH cache line size = 64
Logical Processor Count = 16
APIC Physical ID = 8

The following features are supported:
SSE3
Supplemental Streaming SIMD Extensions 3
L1 Context ID
CMPXCHG16B Instruction
SSE4.1 Extensions
SSE4.2 Extensions
AVX Extensions
PPOPCNT Instruction
x87 FPU On Chip
Virtual-8086 Mode Enhancement
Debugging Extensions
Page Size Extensions
Time Stamp Counter
RDMSR and WRMSR Support
Physical Address Extensions
Machine Check Exception
CMPXCHG8B Instruction
APIC On Chip
SYSENTER and SYSEXIT
Memory Type Range Registers
PTE Global Bit
Machine Check Architecture
Conditional Move/Compare Instruction
Page Attribute Table
36-bit Page Size Extension
CFLUSH Extension
MMX Technology
FXSAVE/FXRSTOR
SSE Extensions
SSE2 Extensions
Multithreading Technology
LAHF/SAHF in 64-bit mode
Core multi-processing legacy mode
AltMovCr8
LZCNT instruction
SSE4A (EXTRQ, INSERTQ, MOVNTSD, MOVNTSS)
Misaligned SSE mode
PREFETCH and PREFETCHW Instructions
SYSCALL/SYSRET in 64-bit mode
Execute Disable Bit
1GB page support
RDTSCP instruction
64 bit Technology
MOVU Optimization

CPU Brand String: AMD Ryzen 7 3800X 8-Core Processor
Cache Line Size = 64
L2 Associativity = 6
Cache Size = 512K
EAX=7 CPUID feature bits:
EAX=00000000
EBX=219c91a9
ECX=00400004
EDX=00000000


AVX2 Extensions


BMI2 Extensions


YAFU Version 2.03
Built with Microsoft Visual Studio 1928
Using GMP-ECM 7.0.4, Powered by MPIR 3.0.0
Detected AMD Ryzen 7 3800X 8-Core Processor
Detected L1 = 32768 bytes, L2 = 33554432 bytes, CL = 64 bytes
Using 1 random witness for Rabin-Miller PRP checks
Cached 664579 primes; max prime is 9999991[/CODE]

Edit: There is no error message. Instead of the command prompt, yafu simply exits without writing anything to screen. If I remove the settings file, yafu informs me about that file missing, but is still exiting right after that.

[QUOTE=kruoli;579776]The current AVX2 build is not working on my AMD Ryzen 3800X. I guess it is likely the same problem as with the Threadripper. The non-AVX version works fine. I have not tested the current version on my Threadripper yet. I have not tested the old version on the 3800X. Would some of that help?
[/QUOTE]

Apologies, I will come back to look at this... had forgotten about it.

From your description of the problem I would guess that there is an illegal instruction somewhere in the sieve of Eratosthenes code, since that is one of the first things that runs. It should be only using AVX2 and BMI2, both of which the cpu supports. If you were on linux I would ask you to run under a debugger, but obviously can't do that here. I'll look closer and let you know if there is something else to try.

Thanks. :smile:

[QUOTE=bsquared;579780]If you were on linux I would ask you to run under a debugger, but obviously can't do that here.[/QUOTE]

Maybe running it in WSL2 would work? I have not yet compiled it there but maybe that would be a possibility. Otherwise, my 5950X has a Linux installed on it, currently. But I have not tested any YAFU executable on it yet.

When doing poly select, Yafu displays the following for all threads:

[CODE]**** finished poly work in thread 3
nfs: best score is currently 0.000e+00[/CODE]

The best score is always listed as 0.000 after each thread completes. Just noting this behavior since Yafu finds the highest score at the final conclusion of poly select.

[QUOTE=kruoli;579782]Thanks. :smile:



Maybe running it in WSL2 would work? I have not yet compiled it there but maybe that would be a possibility. Otherwise, my 5950X has a Linux installed on it, currently. But I have not tested any YAFU executable on it yet.[/QUOTE]

WSL2 would work, yes. I'm a huge fan of WSL. It can be a bit of a chore getting all of the build tools and building everything but it can be done.

I use Ubuntu on WSL2. For that distro to get a good build environment I believe it's:
sudo apt update
sudo apt upgrade
sudo apt install build-essential



[QUOTE=richs;580304]When doing poly select, Yafu displays the following for all threads:

[CODE]**** finished poly work in thread 3
nfs: best score is currently 0.000e+00[/CODE]

The best score is always listed as 0.000 after each thread completes. Just noting this behavior since Yafu finds the highest score at the final conclusion of poly select.[/QUOTE]

I've seen that also, yes. But as you said it seems to find the correct poly in the end so I think it's Mostly Harmless. Still, it's on the list to track down someday.

I tried running it in Visual Studio and got an exception at 0x00007FF6B3ECD044 in yafu-mingw-avx2.exe: 0xC000001D: Illegal Instruction.

It highlights line 50 of tiny.c, maybe the [C]sqrt(...)[/C] is the problem here? It will take some time until I have it running under WSL, but maybe this helps?

The line number might differ if there were some changes after the .exe was built, since I used the latest git code.

Just got it!
It is [C]00007FF6B3ECD044 vcvtusi2sd xmm6,xmm6,ebx[/C]. :smile:

[QUOTE=kruoli;580349]Just got it!
It is [C]00007FF6B3ECD044 vcvtusi2sd xmm6,xmm6,ebx[/C]. :smile:[/QUOTE]
That's an AVX512F instruction: [url]https://www.felixcloutier.com/x86/vcvtusi2sd[/url]

[QUOTE=kruoli;580349]Just got it!
It is [C]00007FF6B3ECD044 vcvtusi2sd xmm6,xmm6,ebx[/C]. :smile:[/QUOTE]

That is a AVX512F instruction, weird. Thank you for tracking that down.

I didn't realize you were using the mingw executable. Do you have the same problem if you use the yafu-x64 version? That was built by visual studio and I would expect it to be more portable.

[QUOTE=kruoli;579776]The non-AVX version works fine.[/QUOTE]

:smile:

The mingw version was the only AVX2 version I saw. The version without mingw is running fine on all machines so far. It also is remarkably smaller.

[QUOTE=kruoli;580353]:smile:

The mingw version was the only AVX2 version I saw. The version without mingw is running fine on all machines so far. It also is remarkably smaller.[/QUOTE]

Ok, sounds good. Just use the -x64 version. I might just remove the mingw versions from git.

[extra info]
A long-running background project for yafu is to get all assembly optimizations working in visual studio, so I can forget about the mingw path. mingw was nice when that was the fastest option for windows, but now with WSL2 and better assembly support (via intrinsics) for visual studio, I'd like to move away from mingw.

updates
 

A couple updates, one related to a msieve change that I've just noticed.

1)
As of msieve 1023, gnfs cpu (and maybe gpu?) poly selection now defaults to a massive 8640000 seconds deadline per coefficient searched. That can be changed with a "poly_deadline" parameter, which I didn't know about before. Noticed it recently when trying to gnfs a c120 or so, and having it spend hours in multi-threaded poly select for a 30 minute job. The update now uses the poly_deadline parameter and it seems to work better.

Although, it finds [U]way [/U]fewer polys than before. The parameter tables changed in msieve 1023 as well, and some seem to have pretty strict minimum E-score requirements.

2)
When running snfs with an input poly file, yafu will do a quick search for a better skew value. So far it doesn't do anything with this info other than print it to the screen, but after some more testing I might automatically update the input poly with the improved skew, if one is found.

3)
I'm no longer supporting -psearch deep or -psearch wide for multi-threaded gnfs poly selection. Not sure if these were even used by anyone... I know I didn't use them. Now all searches are "fast", which was the default, and which divides the search time by the number of threads. -psearch {min | avg | good} can still be used to modify acceptable E-scores.* For small jobs I've found -psearch avg or even -psearch min to be faster, as any old poly will sieve almost as fast as another and you would like to get on with the sieving asap.

[edit]
* the -psearch min | avg capability is where conflicts might occur with the new msieve poly parameter tables. I need to do more testing to know for sure. But for that c120 job I did recently, it found [U]exactly one[/U] poly after 10 minutes of searching on 40 threads (over 6 thread-hours of searching). Specifying -psearch min won't do any good if msieve won't even return polys found near that score.

Latest yafu segfaults when resuming NFS. Here's the gdb output:

[code]>> nfs: checking for job file - job file found, testing for matching input
nfs: number in job file matches input
nfs: checking for data file
nfs: previous data file found
nfs: commencing search for last special-q
line 0 = 1631079863,1741:fb1cb3,26a433,4903:156d15,c5f,ec3,1387,a1d71,ce251,e01fb

line 1 = 1638952149,2035:19f8559,be9,11ab,3121,c775:38e243,13af,2e2d,3161,3491,27e51,e01fb

line 2 = 1736339753,1015:7f3ae3,2cde80d,116f,274e5:100019,2971ac5,4255,a3ff,af7f,e01fb

line 3 = 1733728719,1543:26a084d,18b5637,1999,48f7:305e33f,1d41f,61d11,6d3,e01fb

nfs: parsing special-q from .dat file
nfs: commencing nfs on c100: 1522605027922533360535618378132637429718068114961380688657908494580122963258952897654000350692006139
nfs: resumesieve; last_spq = 918011, nfs_phases = 0
nfs: found skew: 1108606.390000
nfs: found c[0]: -537120876901310626660353125
nfs: found c[1]: 20224876429498235072250
nfs: found c[2]: 13491534070563215
nfs: found c[3]: -19666557336
nfs: found c[4]: 8820
nfs: found Y0: -644590365547202992686312
nfs: found Y1: 11026585360387
nfs: parsed lpbr = 26, lpba = 26

Program received signal SIGSEGV, Segmentation fault.
parse_job_file (fobj=fobj@entry=0x5555578f9000, job=job@entry=0x7fffffffa1d0)
at factor/nfs/nfs_filemanip.c:1372
1372 job->snfs->sdifficulty = job->snfs->difficulty = 0;
(gdb) backtrace
#0 parse_job_file (fobj=fobj@entry=0x5555578f9000, job=job@entry=0x7fffffffa1d0) at factor/nfs/nfs_filemanip.c:1372
#1 0x00005555555da4cb in nfs (fobj=fobj@entry=0x5555578f9000) at factor/nfs/nfs.c:874
#2 0x000055555556a0b2 in feval (funcnum=funcnum@entry=71, nargs=1, metadata=metadata@entry=0x7fffffffb6c0) at top/cmdParser/calc.c:2857
#3 0x00005555555696f9 in calc (in=in@entry=0x7fffffffb500, metadata=metadata@entry=0x7fffffffb6c0) at top/cmdParser/calc.c:1943
#4 0x00005555555699b0 in calc_with_assignment (in=in@entry=0x5555578f7850, metadata=metadata@entry=0x7fffffffb6c0, force_quiet=force_quiet@entry=0)
at top/cmdParser/calc.c:1531
#5 0x0000555555569b8a in process_expression (input_exp=<optimized out>, metadata=0x7fffffffb6c0, force_quiet=0, no_convert_result=0) at top/cmdParser/calc.c:1477
#6 0x000055555555a878 in main (argc=<optimized out>, argv=<optimized out>) at top/driver.c:366[/code]

Despite the recent changes to make poly selection faster, it still continues up until the deadline for most 109-digit numbers:

[code]07/05/21 07:12:47, nfs: commencing nfs on c109: 1090856851194159102847462612480990401998890638794326582448210291834957096186057950134759387351816485448746449
07/05/21 07:12:47, nfs: commencing poly selection with 6 threads
07/05/21 07:12:47, nfs: setting deadline of 2964 seconds
07/05/21 07:12:47, nfs: expecting degree 4 poly E from 3.14e-09 to > 3.62e-09
07/05/21 07:12:47, nfs: searching for avg quality poly E > 3.26e-09
07/05/21 08:04:29, nfs: completed 146 ranges of size 60 in 3102.7585 seconds
07/05/21 08:04:29, nfs: best poly = # norm 3.444816e-10 alpha -7.184646 e 1.363e-09 rroots 3[/code]

Notice the huge difference between the expected E values and what we actually get. For numbers between 10^108 and 2^362 (≈9.39*10^108), yafu thinks msieve will use degree 4 but it actually uses degree 5. So an "average" quality polynomial never turns up and the search continues until the deadline.

[QUOTE=charybdis;582702]Despite the recent changes to make poly selection faster, it still continues up until the deadline for most 109-digit numbers:

[code]07/05/21 07:12:47, nfs: commencing nfs on c109: 1090856851194159102847462612480990401998890638794326582448210291834957096186057950134759387351816485448746449
07/05/21 07:12:47, nfs: commencing poly selection with 6 threads
07/05/21 07:12:47, nfs: setting deadline of 2964 seconds
07/05/21 07:12:47, nfs: expecting degree 4 poly E from 3.14e-09 to > 3.62e-09
07/05/21 07:12:47, nfs: searching for avg quality poly E > 3.26e-09
07/05/21 08:04:29, nfs: completed 146 ranges of size 60 in 3102.7585 seconds
07/05/21 08:04:29, nfs: best poly = # norm 3.444816e-10 alpha -7.184646 e 1.363e-09 rroots 3[/code]

Notice the huge difference between the expected E values and what we actually get. For numbers between 10^108 and 2^362 (≈9.39*10^108), yafu thinks msieve will use degree 4 but it actually uses degree 5. So an "average" quality polynomial never turns up and the search continues until the deadline.[/QUOTE]

This is good to know, I will have to add a check to see what degree is actually being used.

Also, the bug you previously reported has been found and fixed (thanks for the detailed report!). I still need to commit the changes... hopefully will get a chance tonight.

If Yafu has specific needs about configuring NFS polynomial, maybe it should add a configuration string of its own when running Msieve. That would let it control the polynomial degree and all the bounds used. The bounds and deadlines changed quite a while ago and reflected a lot of best practice here, but they can't cover every use case.

Version 2.04 uploaded
 

New version 2.04 is now available.

Includes two improvements to yafu's QS:

1) Now using the poly formulation Q(x) = (2ax + b)^2 - kN whenever possible (if kN == 1 mod 8). For ~85% of inputs this gives about a 10% speedup.
2) Found some new AVX512 optimizations to the bucket sort: linux systems (and WSL2 windows systems) that are AVX-512 capable should be about 15-20% faster (!)

With those two improvements my benchmark numbers now run from 21 to 30% faster. Including a c80 in well under a minute! (46 seconds, down from 62 seconds, on my i7-7800X)

The windows version doesn't get all of these improvements yet because visual studio doesn't like the compressstoreu instruction. I may need to update visual studio or file a bug report or something.

Anyway, happy factoring!

Segfault upon starting SNFS
 

I recently compiled a fresh build of YAFU, but am having issues when trying to factor via SNFS with a pre-made polynomial.

Log: [CODE]YAFU Version 2.03
Built with GCC 9
Using GMP-ECM 7.0.5-dev, Powered by GMP 6.2.1
Detected AMD Ryzen 5 5600X 6-Core Processor
Detected L1 = 32768 bytes, L2 = 33554432 bytes, CL = 64 bytes
Using 1 random witness for Rabin-Miller PRP checks
Cached 664579 primes; max prime is 9999991

===============================================================
======= Welcome to YAFU (Yet Another Factoring Utility) =======
======= bbuhrow@gmail.com =======
======= Type help at any time, or quit to quit =======
===============================================================

>> nfs(508155924947538816161101635487366611969955965840021547875500594140402111454201939923927956969296837060051327267616455978442987911081313892049188185868241575553249)
nfs: checking for job file - job file found, testing for matching input
input from file = 508155924947538816161101635487366611969955965840021547875500594140402111454201939923927956969296837060051327267616455978442987911081313892049188185868241575553249
input to yafu = 508155924947538816161101635487366611969955965840021547875500594140402111454201939923927956969296837060051327267616455978442987911081313892049188185868241575553249
input matches with multiple of 1
nfs: number in job file matches input
nfs: checking for data file
nfs: no data file found
nfs: commencing nfs on c162: 508155924947538816161101635487366611969955965840021547875500594140402111454201939923927956969296837060051327267616455978442987911081313892049188185868241575553249
nfs: resumesieve; last_spq = 0, nfs_phases = 0
nfs: found m: 50000000000000000000000000000000000000
nfs: found c[5]: 196
nfs: found c[0]: -5
nfs: found skew: 0.480000
nfs: found type: snfs
nfs: initializing snfs poly
nfs: parsed lpbr = 28, lpba = 28
nfs: detected snfs job but no snfs difficulty
nfs: using m and poly coefficients to compute difficulty
nfs: snfs difficulty: 39.991226
nfs: checking degree 5 poly
nfs: analyzing poly:
Segmentation fault[/CODE]

Content of nfs.job:
[CODE]n: 508155924947538816161101635487366611969955965840021547875500594140402111454201939923927956969296837060051327267616455978442987911081313892049188185868241575553249
m: 50000000000000000000000000000000000000
deg: 5
c5: 196
c0: -5
skew: 0.48
# Murphy_E = 3.279e-11
type: snfs
lss: 1
rlim: 10600000
alim: 10600000
lpbr: 28
lpba: 28
mfbr: 54
mfba: 54
rlambda: 2.5
alambda: 2.5[/CODE]

Another thing to note is that the SNFS difficulty calculation seems to be wrong when missing some coefficients.

I can take a look at where it's going wrong. In the meantime, if I comment out m: and put in the rational coefficients instead it works:

[CODE]n: 508155924947538816161101635487366611969955965840021547875500594140402111454201939923927956969296837060051327267616455978442987911081313892049188185868241575553249
# m: 50000000000000000000000000000000000000
deg: 5
c5: 196
c0: -5
Y1: -1
Y0: 50000000000000000000000000000000000000
skew: 0.48
type: snfs
lss: 1
rlim: 10600000
alim: 10600000
lpbr: 28
lpba: 28
mfbr: 54
mfba: 54
rlambda: 2.5
alambda: 2.5


[/CODE]


[CODE]nfs: commencing nfs on c162: 508155924947538816161101635487366611969955965840021547875500594140402111454201939923927956969296837060051327267616455978442987911081313892049188185868241575553249
nfs: resumesieve; last_spq = 0, nfs_phases = 0
nfs: found c[5]: 196
nfs: found c[0]: -5
nfs: found Y1: -1
nfs: found Y0: 50000000000000000000000000000000000000
nfs: found skew: 0.480000
nfs: found type: snfs
nfs: initializing snfs poly
nfs: parsed lpbr = 28, lpba = 28
nfs: detected snfs job but no snfs difficulty
nfs: using m and poly coefficients to compute difficulty
nfs: snfs difficulty: 39.991226
nfs: checking degree 5 poly
nfs: analyzing poly:
nfs: anorm = -2.388308e+32, rnorm = 4.180462e+44, size: 2.193000e-13, alpha = 1.196000e+00, murphyE = 3.279000e-11
gen: anorm: -2.39e+32, rnorm: 4.18e+44, ratio: 1.75e+12, log10(ratio) = 12.24
nfs: snfs skewed difficulty: 42.439853
nfs: optimizing skew
nfs: found better skew: 0.484800 with murphy score 3.281000e-11
nfs: found better skew: 0.489600 with murphy score 3.282000e-11
nfs: found better skew: 0.494400 with murphy score 3.284000e-11
nfs: found better skew: 0.499200 with murphy score 3.285000e-11
nfs: found better skew: 0.504000 with murphy score 3.286000e-11
nfs: found better skew: 0.508800 with murphy score 3.287000e-11
nfs: found better skew: 0.513600 with murphy score 3.289000e-11
nfs: found better skew: 0.518400 with murphy score 3.290000e-11
nfs: found better skew: 0.523200 with murphy score 3.291000e-11
nfs: found better skew: 0.528000 with murphy score 3.292000e-11
nfs: found better skew: 0.532800 with murphy score 3.293000e-11
nfs: found better skew: 0.537600 with murphy score 3.294000e-11
nfs: found better skew: 0.547200 with murphy score 3.295000e-11
nfs: found better skew: 0.552000 with murphy score 3.296000e-11
nfs: found better skew: 0.556800 with murphy score 3.297000e-11
nfs: found better skew: 0.561600 with murphy score 3.298000e-11
nfs: found better skew: 0.571200 with murphy score 3.299000e-11
nfs: found better skew: 0.580800 with murphy score 3.300000e-11
nfs: found better skew: 0.585600 with murphy score 3.301000e-11
nfs: found better skew: 0.600000 with murphy score 3.302000e-11
nfs: found better skew: 0.609600 with murphy score 3.303000e-11
nfs: found better skew: 0.624000 with murphy score 3.304000e-11
nfs: found better skew: 0.643200 with murphy score 3.305000e-11
nfs: guessing snfs difficulty 42 is roughly equal to gnfs difficulty 53
nfs: creating ggnfs job parameters for input of size 53
nfs: job file is missing params, filling them
nfs: continuing with sieving - could not determine last special q; using default startq
nfs: commencing rational side lattice sieving over range: 5300000 - 5302000
syscmd: ../../ggnfs-bin/gnfs-lasieve4I11e -v -f 5300000 -c 2000 -o rels0.dat -n 0 -r nfs.job
gnfs-lasieve4I11e (with asm64): L1_BITS=15, SVN $Revision: 399 $
Warning: lowering FB_bound to 5299999.
FBsize 702099+0 (deg 5), 367899+0 (deg 1)
total yield: 353, q=5300857 (0.03694 sec/rel) ^C
[/CODE]

Clearly having issues figuring out difficulty, but since the parameters are in there already that mostly doesn't matter. You can just tell it which siever to use and I think it will work, e.g.:

[CODE]./yafu "nfs(508155924947538816161101635487366611969955965840021547875500594140402111454201939923927956969296837060051327267616455978442987911081313892049188185868241575553249)" -v -v -siever 13[/CODE]

Windows Ver 2.04 SIQS Bug
 

Using Windows executable ver. 2.04, SIQS has problems:

[CODE]08/09/21 08:21:19, ****************************
08/09/21 08:21:19, Starting factorization of 105393989787970375262364798207451884611473765049956049673829221285271966197423217847983687608092010532144015094441669842637319335236412609289116384759967578759
08/09/21 08:21:19, using pretesting plan: normal
08/09/21 08:21:19, using tune info for qs/gnfs crossover
08/09/21 08:21:19, ****************************
08/09/21 08:21:19, rho: x^2 + 3, starting 1000 iterations on C159
08/09/21 08:21:19, rho: x^2 + 2, starting 1000 iterations on C159
08/09/21 08:21:19, rho: x^2 + 1, starting 1000 iterations on C159
08/09/21 08:21:20, pm1: starting B1 = 150K, B2 = gmp-ecm default on C159
08/09/21 08:21:20, current ECM pretesting depth: 0.00
08/09/21 08:21:20, scheduled 30 curves at B1=2000 toward target pretesting depth of 48.92
08/09/21 08:21:20, Finished 30 curves using GMP-ECM method on C159 input, B1=2k, B2=gmp-ecm default
08/09/21 08:21:20, current ECM pretesting depth: 15.18
08/09/21 08:21:20, scheduled 74 curves at B1=11000 toward target pretesting depth of 48.92
08/09/21 08:21:26, Finished 74 curves using GMP-ECM method on C159 input, B1=11k, B2=gmp-ecm default
08/09/21 08:21:26, current ECM pretesting depth: 20.24
08/09/21 08:21:26, scheduled 214 curves at B1=50000 toward target pretesting depth of 48.92
08/09/21 08:22:29, Finished 214 curves using GMP-ECM method on C159 input, B1=50k, B2=gmp-ecm default
08/09/21 08:22:29, pm1: starting B1 = 3750K, B2 = gmp-ecm default on C159
08/09/21 08:22:31, current ECM pretesting depth: 25.33
08/09/21 08:22:31, scheduled 430 curves at B1=250000 toward target pretesting depth of 48.92
08/09/21 08:32:02, Finished 430 curves using GMP-ECM method on C159 input, B1=250k, B2=gmp-ecm default
08/09/21 08:32:02, pm1: starting B1 = 15M, B2 = gmp-ecm default on C159
08/09/21 08:32:09, current ECM pretesting depth: 30.45
08/09/21 08:32:09, scheduled 904 curves at B1=1000000 toward target pretesting depth of 48.92
08/09/21 08:51:40, prp32 = 81818626235929905372894171191449 (curve 222 stg2 B1=1000000 sigma=3833225760 thread=0)
08/09/21 08:51:40, Finished 221 curves using GMP-ECM method on C159 input, B1=1M, B2=gmp-ecm default
08/09/21 08:51:40, current ECM pretesting depth: 31.68
08/09/21 08:51:40, scheduled 683 curves at B1=1000000 toward target pretesting depth of 39.08
08/09/21 09:06:41, prp30 = 287063003181080966701377441473 (curve 222 stg2 B1=1000000 sigma=2084237989 thread=0)
08/09/21 09:06:41, Finished 221 curves using GMP-ECM method on C127 input, B1=1M, B2=gmp-ecm default
08/09/21 09:06:41, final ECM pretested depth: 32.90
08/09/21 09:06:41, scheduler: switching to sieve method
08/09/21 09:06:42, starting SIQS on c97: 4487313770523153739495208002033098434359404539272558781592283264158439136945627929018162116601567
08/09/21 09:06:42, random seed: 380728400
08/09/21 09:06:42, ==== sieve params ====
08/09/21 09:06:42, n = 99 digits, 328 bits
08/09/21 09:06:42, factor base: 102912 primes (max prime = 2823973)
08/09/21 09:06:42, single large prime cutoff: 409476085 (145 * pmax)
08/09/21 09:06:42, double large prime range from 7974823504729 to 8562938075287819
08/09/21 09:06:42, DLP MFB = 1.85
08/09/21 09:06:42, allocating 9 large prime slices of factor base
08/09/21 09:06:42, buckets hold 2048 elements
08/09/21 09:06:42, large prime hashtables have 1622016 bytes
08/09/21 09:06:42, using AVX2 enabled 32k sieve core
08/09/21 09:06:42, sieve interval: 11 blocks of size 32768
08/09/21 09:06:42, polynomial A has ~ 13 factors
08/09/21 09:06:42, using multiplier of 103
08/09/21 09:06:42, using multiplier of 103
08/09/21 09:06:42, using Q2(x) polynomials for kN mod 8 = 1
08/09/21 09:06:42, using SPV correction of 21 bits, starting at offset 36
08/09/21 09:06:42, trial factoring cutoff at 98 bits
08/09/21 09:06:42, ==== sieving started ( 6 threads) ====
08/09/21 09:31:29, trial division touched 164355364 sieve locations out of 1512672657408
08/09/21 09:31:29, total reports = 164355364, total surviving reports = 43553883
08/09/21 09:31:29, total blocks sieved = 46163106, avg surviving reports per block = 0.94
08/09/21 09:31:29, dlp-ecm: 131 failures, 1685998 attempts, 34424793 outside range, 7038997 prp, 1342823 useful
08/09/21 09:31:29, 103416 relations found: 26955 full + 76461 from 1719963 partial, using 2098323 polys (1900 A polys)
08/09/21 09:31:29, on average, sieving found 0.83 rels/poly and 1174.44 rels/sec
08/09/21 09:31:29, trial division touched 164355364 sieve locations out of 1512672657408
08/09/21 09:31:29, ==== post processing stage (msieve-1.38) ====
08/09/21 09:31:29, QS elapsed time = 1487.4595 seconds.
08/09/21 09:31:30, begin singleton removal with 1746918 relations
08/09/21 09:31:31, reduce to 266460 relations in 12 passes
08/09/21 09:31:31, failed to read relation 8
08/09/21 09:31:31, failed to read relation 190

** numerous failed to read relation lines

08/09/21 09:31:35, failed to read relation 266199
08/09/21 09:31:35, recovered 263590 relations
08/09/21 09:31:35, recovered 247915 polynomials
08/09/21 09:31:35, attempting to build 100566 cycles
08/09/21 09:31:35, found 100566 cycles from 263590 relations in 6 passes
08/09/21 09:31:35, distribution of cycle lengths:
08/09/21 09:31:35, length 1 : 26563
08/09/21 09:31:35, length 2 : 18090
08/09/21 09:31:35, length 3 : 16887
08/09/21 09:31:35, length 4 : 13215
08/09/21 09:31:35, length 5 : 9817
08/09/21 09:31:35, length 6 : 6261
08/09/21 09:31:35, length 7 : 4166
08/09/21 09:31:35, length 9+: 5567
08/09/21 09:31:35, largest cycle: 25 relations
08/09/21 09:31:35, matrix is 102912 x 100566 (29.1 MB) with weight 6836076 (67.98/col)
08/09/21 09:31:35, sparse part has weight 6836076 (67.98/col)
08/09/21 09:31:36, filtering completed in 2 passes
08/09/21 09:31:36, matrix is 96687 x 94802 (28.1 MB) with weight 6606297 (69.69/col)
08/09/21 09:31:36, sparse part has weight 6606297 (69.69/col)
08/09/21 09:31:36, matrix must have more columns than rows
08/09/21 09:31:38, begin singleton removal with 1746918 relations
08/09/21 09:31:39, reduce to 266460 relations in 12 passes
08/09/21 09:31:39, failed to read relation 8
08/09/21 09:31:39, failed to read relation 190
[/CODE]

SIQS then repeats over and over until the process is killed.

Thanks, it was a very silly mistake on my part. I didn't do enough testing.

2.05 is now available.

Yafu bug?
 

I downloaded the most recent version 2.05 for Windows. That version is still crashing for me. When I try to run it as yafu-x64.exe, it will open to ">>" where you can enter a command such as factor(123456) but it crashes before I can enter anything.

Ver. 2.05 works fine (so far) on my Windows 10 i7 laptop where I had the SIQS bug with ver. 2.04.

[QUOTE=bsquared;585347]Thanks, it was a very silly mistake on my part. I didn't do enough testing.

2.05 is now available.[/QUOTE]I am being especially dumb today.

The sourceforge version is stuck at 1.34.

Where is 2.05 to be found?

Thanks, Paul

[URL="http://github.com/bbuhrow/yafu/blob/master/yafu-x64.exe"]Here[/URL] it is. :smile:

[QUOTE=johnadam74;585381]I downloaded the most recent version 2.05 for Windows. That version is still crashing for me. When I try to run it as yafu-x64.exe, it will open to ">>" where you can enter a command such as factor(123456) but it crashes before I can enter anything.[/QUOTE]

Can you give me any more info about your cpu (intel/amd model number)? If you can run with -v or -vproc that output would help.

[QUOTE=kruoli;585405][URL="http://github.com/bbuhrow/yafu/blob/master/yafu-x64.exe"]Here[/URL] it is. :smile:[/QUOTE]

Hey that's my line! :smile:

Hi Ben

I spent some time today aligning all the constituent parts of the YAFU Visual Studio 2019 build for windows X64 to use the Microsoft static runtime libraries and I now have a successful build of YAFU. I have tested it on Windows 11 (beta) with the Quadro T2000 GPU on my laptop and all seems to work as expected.

It is available here (yafu, ysieve and ytools):

[url]https://github.com/BrianGladman?tab=repositories[/url]

The build is in the build.vs subdirectory, not build.vc19 (which does not build), as I am in the process of moving it to Visual Studio 2022.

Sadly the build for the siqs_demo project fails because it cannot find these symbols:

1>calc.obj : error LNK2001: unresolved external symbol siqsbench
1>calc.obj : error LNK2001: unresolved external symbol smallmpqs
1>calc.obj : error LNK2001: unresolved external symbol SIQS
1>siqs_demo.obj : error LNK2001: unresolved external symbol get_computer_info

I would be grateful for your advice on where these should be available.

[QUOTE=kruoli;585405][URL="http://github.com/bbuhrow/yafu/blob/master/yafu-x64.exe"]Here[/URL] it is. :smile:[/QUOTE]Thanks!

I get a SIGSEGV with yafu 2.05 on a Ryzen 3950X under linux built with [CODE]make yafu NFS=1 USE_SSE41=1 USE_AVX2=1 USE_BMI2=1[/CODE] and [CODE]yafu "siqs(1131941884204194473862586294639558925416454742463976786637412462462312690253602905547214801)"[/CODE]The number was generated with rsa(300).

Thanks for the report and testing, I'll look into it. I won't be able to get a revision out until Sunday.

[QUOTE=Brian Gladman;585408]Hi Ben

I spent some time today aligning all the constituent parts of the YAFU Visual Studio 2019 build for windows X64 to use the Microsoft static runtime libraries and I now have a successful build of YAFU. I have tested it on Windows 11 (beta) with the Quadro T2000 GPU on my laptop and all seems to work as expected.

It is available here (yafu, ysieve and ytools):

[url]https://github.com/BrianGladman?tab=repositories[/url]

The build is in the build.vs subdirectory, not build.vc19 (which does not build), as I am in the process of moving it to Visual Studio 2022.

Sadly the build for the siqs_demo project fails because it cannot find these symbols:

1>calc.obj : error LNK2001: unresolved external symbol siqsbench
1>calc.obj : error LNK2001: unresolved external symbol smallmpqs
1>calc.obj : error LNK2001: unresolved external symbol SIQS
1>siqs_demo.obj : error LNK2001: unresolved external symbol get_computer_info

I would be grateful for your advice on where these should be available.[/QUOTE]

Fantastic thank you Brian! I think siqs demo just needs some project properties work. I'll look into that this weekend.

[QUOTE=Gimarel;585416]I get a SIGSEGV with yafu 2.05 on a Ryzen 3950X under linux built with [CODE]make yafu NFS=1 USE_SSE41=1 USE_AVX2=1 USE_BMI2=1[/CODE] and [CODE]yafu "siqs(1131941884204194473862586294639558925416454742463976786637412462462312690253602905547214801)"[/CODE][/QUOTE]

In case it's helpful in diagnosing the issue, I couldn't reproduce this crash on an i5-8500 with the same build flags.

[QUOTE=charybdis;585428]In case it's helpful in diagnosing the issue, I couldn't reproduce this crash on an i5-8500 with the same build flags.[/QUOTE]

Unable to reproduce on 5600X with same build flags as well.

P.S. YAFU 2.05 from the github repository's "yafu-x64.exe" was crashing upon starting a SIQS factorization. Unable to get logs for the next few days, but I am available to answer more questions if there are any regarding my setup.

[QUOTE=Gimarel;585416]I get a SIGSEGV with yafu 2.05 on a Ryzen 3950X under linux built with [CODE]make yafu NFS=1 USE_SSE41=1 USE_AVX2=1 USE_BMI2=1[/CODE][/QUOTE]

Further testing showed, that the number doesn't matter. yafu crashes every time with siqs(rsa(215)), most of the time with siqs(rsa(214)) but runs every time with siqs(rsa(213)).
Also note that yafu works if I omit USE_AVX2=1.

I'm using gcc-10 of debian bullseye.

Here's a complete log:[CODE]yafu "siqs(rsa(215))"

YAFU Version 2.05
Built with GCC 10
Using GMP-ECM 7.0.5-dev, Powered by GMP 6.2.1
Detected AMD Ryzen 9 3950X 16-Core Processor
Detected L1 = 32768 bytes, L2 = 67108864 bytes, CL = 64 bytes
Using 1 random witness for Rabin-Miller PRP checks
Cached 664579 primes; max prime is 9999991

===============================================================
======= Welcome to YAFU (Yet Another Factoring Utility) =======
======= bbuhrow@gmail.com =======
======= Type help at any time, or quit to quit =======
===============================================================

>>
starting SIQS on c65: 31635638050360383928410741313802727069876274264595430910292999519

==== sieve params ====
n = 67 digits, 221 bits
factor base: 6384 primes (max prime = 137117)
single large prime cutoff: 10283775 (75 * pmax)
allocating 3 large prime slices of factor base
buckets hold 2048 elements
large prime hashtables have 196608 bytes
using AVX2 enabled 32k sieve core
sieve interval: 4 blocks of size 32768
polynomial A has ~ 8 factors
using multiplier of 71
using Q2(x) polynomials for kN mod 8 = 1
using SPV correction of 21 bits, starting at offset 32
trial factoring cutoff at 75 bits

==== sieving in progress (1 thread): 6448 relations needed ====
==== Press ctrl-c to abort and save state ====
Segmentation fault[/CODE]gdb backtrace:
[CODE]#0 0x000055555558aee1 in nextRoots_32k_avx2 (sconf=<optimized out>, dconf=0x555557fa3710) at factor/qs/update_poly_roots_32k_avx2.c:1506
#1 0x0000555555575da6 in process_poly (vptr=vptr@entry=0x5555578fed60) at factor/qs/SIQS.c:1292
#2 0x000055555557d368 in SIQS (fobj=fobj@entry=0x5555578f5ef0) at factor/qs/SIQS.c:828
#3 0x000055555556c414 in feval (funcnum=funcnum@entry=59, nargs=nargs@entry=1, metadata=metadata@entry=0x7fffffffd030) at top/cmdParser/calc.c:2559
#4 0x000055555556e0c6 in calc (in=in@entry=0x7fffffffce90, metadata=metadata@entry=0x7fffffffd030) at top/cmdParser/calc.c:1946
#5 0x000055555556e364 in calc_with_assignment (in=in@entry=0x5555578fce60, metadata=metadata@entry=0x7fffffffd030, force_quiet=force_quiet@entry=0) at top/cmdParser/calc.c:1526
#6 0x000055555556a421 in process_expression (input_exp=<optimized out>, metadata=metadata@entry=0x7fffffffd030, force_quiet=0, no_convert_result=no_convert_result@entry=0) at top/cmdParser/calc.c:1472
#7 0x000055555555a850 in main (argc=<optimized out>, argv=<optimized out>) at top/driver.c:366[/CODE]Crashing instruction:

[CODE]│ 0x55555558aed3 <nextRoots_32k_avx2+10563> mov 0x28(%rsi),%r14 │
│ 0x55555558aed7 <nextRoots_32k_avx2+10567> vmovdqa (%rdi,%r15,4),%ymm3 │
│ 0x55555558aedd <nextRoots_32k_avx2+10573> mov 0x30(%rsi),%r13 │
│ >0x55555558aee1 <nextRoots_32k_avx2+10577> vmovdqa (%r14,%r15,4),%ymm1 │
│ 0x55555558aee7 <nextRoots_32k_avx2+10583> vpaddd %ymm3,%ymm1,%ymm1 │
│ 0x55555558aeeb <nextRoots_32k_avx2+10587> vmovdqa 0x0(%r13,%r15,4),%ymm2 │
│ 0x55555558aef2 <nextRoots_32k_avx2+10594> mov 0x20(%rsi),%rdi │
[/CODE]

[QUOTE=Gimarel;585452]Further testing showed, that the number doesn't matter. yafu crashes every time with siqs(rsa(215)), most of the time with siqs(rsa(214)) but runs every time with siqs(rsa(213)).
Also note that yafu works if I omit USE_AVX2=1.

I'm using gcc-10 of debian bullseye.
[/QUOTE]

Thanks for the detailed info. Looks like gcc-10 is having problems aligning some data, which comes into play once input numbers are big enough to start using avx2 inline assembly. There may be gcc options that force alignment, or you can not use avx2, as you discovered, which is probably the best option for now. I have not seen the same problems with icc or gcc-11.1.0 or gcc-7.3.0. Sorry I can't be of more help.

[QUOTE=Plutie;585429]Unable to reproduce on 5600X with same build flags as well.

P.S. YAFU 2.05 from the github repository's "yafu-x64.exe" was crashing upon starting a SIQS factorization. Unable to get logs for the next few days, but I am available to answer more questions if there are any regarding my setup.[/QUOTE]

[QUOTE=johnadam74;585381]I downloaded the most recent version 2.05 for Windows. That version is still crashing for me. When I try to run it as yafu-x64.exe, it will open to ">>" where you can enter a command such as factor(123456) but it crashes before I can enter anything.[/QUOTE]

Can either of you post the siqs output (or whatever output you get) with -v and -vproc?

[QUOTE=bsquared;585795]Thanks for the detailed info. Looks like gcc-10 is having problems aligning some data, which comes into play once input numbers are big enough to start using avx2 inline assembly. There may be gcc options that force alignment, or you can not use avx2, as you discovered, which is probably the best option for now. I have not seen the same problems with icc or gcc-11.1.0 or gcc-7.3.0. Sorry I can't be of more help.[/QUOTE]

This must be very specific to gcc-10: I was using 9.3.0 when I tried and failed to reproduce this. Looks like installing a second gcc version (with the necessary care, of course) would be an alternative solution to the problem.

[QUOTE=charybdis;585798]This must be very specific to gcc-10: I was using 9.3.0 when I tried and failed to reproduce this. Looks like installing a second gcc version (with the necessary care, of course) would be an alternative solution to the problem.[/QUOTE]
I'm getting the same SEGFAULT with gcc-9. I will try to install gcc-11, but this will take some time.

I also tried clang-11 but the build fails with:[CODE]clang-11 -g -DUSE_SSE2 -mbmi2 -mbmi -DUSE_BMI2 -DUSE_AVX2 -DUSE_SSE41 -mavx2 -DUSE_SSE41 -m64 -msse4.1 -DUSE_NFS -O3 -march=native -mtune=native -fomit-frame-pointer -Wall -I. -Iinclude -Itop/aprcl -Itop/cmdParser -Itop/ -I../../../msieve -I../ysieve -I../ytools -I../../ecm -I../gmp/include -I../gmp-ecm/include/ -c -o factor/qs/msieve/lanczos.o factor/qs/msieve/lanczos.c
In file included from factor/qs/msieve/lanczos.c:18:
In file included from include/lanczos.h:21:
In file included from include/qs_impl.h:20:
include/monty.h:145:19: error: invalid input constraint '0ULL' in asm
: "1"(c), "0ULL"(0), "r"(n));
^
1 error generated.
make: *** [Makefile:450: factor/qs/msieve/lanczos.o] Fehler 1
[/CODE]

[QUOTE=Gimarel;585855]I'm getting the same SEGFAULT with gcc-9. I will try to install gcc-11, but this will take some time.
[/QUOTE]

Weird. I have not changed anything in update_poly_roots_32k_avx2.c in over 5 months, according to github, and those were unrelated changes to where this error occurred. The core routine that produced the segfault hasn't changed in years. As a wild guess you could try changing -march=native to -march=znver1 or -march=znver2 and get rid of -mtune=native. Maybe the compiler is mis-identifying the exact cpu or mis-tuning the code.

[QUOTE=Gimarel;585855]

I also tried clang-11 but the build fails ...[/QUOTE]

I have never tried building with that compiler so not very surprising. The inline assembly doesn't port easily...

v2.06
 

Just checked in version 2.06. I updated the function where Gimeral's error was occurring. For me it is now faster on AVX2 systems, especially with the windows .exe, and hopefully also works for everyone.

Looking back over some historical benchmarks (time in seconds for sequence of inputs), 2.06 is a pretty big speedup for AVX2 systems, for either MSVC windows or linux builds. Still hoping it is also more stable across compilers/cpus.

AVX2 linux, icc (Xeon E5-2697 v3):
[CODE]
version c60 c65 c70 c75 c80 c85 c90 c95
v1.34.5 2.35 6.9 14.8 52.4 104.8 294 3132
v1.35.0 2.2 6.4 12.9 43.6 89.8 262 1037 2912
v2.05 1.83 5.66 11 37 76.6 229
v2.06 1.69 5.48 11.2 35.7 69.5 208 794 2210
[/CODE]

AVX2 Windows, MSVC19 (Xeon 6134):
[CODE]
version c60 c65 c70 c75 c80 c85
v1.34.5 2.54 7.42 15.1 53.8 111.4 311
v2.05 1.93 6.98 14.3 51.7 100.6 314.2
v2.06 1.89 6.11 12.2 41.5 82.1 240.5
[/CODE]

And for comparison, with all available instruction set enhancements (AVX512BW, AVX512VL, AVX512F):
[CODE]
version c60 c65 c70 c75 c80 c85 c90 c95
v2.06 1.16 3.44 6.64 21.9 44.5 135.1 516 1516
[/CODE]

I've just run the C108 cofactor of 73+34.59 through yafu 2.06, although I'm sure any of the previous versions would show the same behaviour.

[CODE]08/18/21 19:43:23,
08/18/21 19:43:23, ****************************
08/18/21 19:43:23, Starting factorization of 806612539887522076624435765094947314651498682479207276130902929847315087082262158953156473845821936013965643
08/18/21 19:43:23, using pretesting plan: normal
08/18/21 19:43:23, using tune info for qs/gnfs crossover
08/18/21 19:43:23, ****************************
08/18/21 19:43:23, rho: x^2 + 3, starting 1000 iterations on C108
08/18/21 19:43:23, prp11 = 40061753549
08/18/21 19:43:23, rho: x^2 + 3, starting 1000 iterations on C98
08/18/21 19:43:23, rho: x^2 + 2, starting 1000 iterations on C98
08/18/21 19:43:23, rho: x^2 + 1, starting 1000 iterations on C98
08/18/21 19:43:24, pm1: starting B1 = 150K, B2 = gmp-ecm default on C98
08/18/21 19:43:24, current ECM pretesting depth: 0.00
08/18/21 19:43:24, scheduled 30 curves at B1=2000 toward target pretesting depth of 30.15
08/18/21 19:43:24, Finished 30 curves using GMP-ECM method on C98 input, B1=2k, B2=gmp-ecm default
08/18/21 19:43:24, current ECM pretesting depth: 15.18
08/18/21 19:43:24, scheduled 74 curves at B1=11000 toward target pretesting depth of 30.15
08/18/21 19:43:25, Finished 74 curves using GMP-ECM method on C98 input, B1=11k, B2=gmp-ecm default
08/18/21 19:43:25, current ECM pretesting depth: 20.24
08/18/21 19:43:25, scheduled 214 curves at B1=50000 toward target pretesting depth of 30.15
08/18/21 19:43:29, Finished 214 curves using GMP-ECM method on C98 input, B1=50k, B2=gmp-ecm default
08/18/21 19:43:29, pm1: starting B1 = 3750K, B2 = gmp-ecm default on C98
08/18/21 19:43:30, current ECM pretesting depth: 25.33
08/18/21 19:43:30, scheduled 402 curves at B1=250000 toward target pretesting depth of 30.15
08/18/21 19:43:52, prp28 = 2606325622300954201341849509 (curve 284 stg2 B1=250000 sigma=3962908428 thread=11)
08/18/21 19:43:53, Finished 294 curves using GMP-ECM method on C98 input, B1=250k, B2=gmp-ecm default
08/18/21 19:43:53, final ECM pretested depth: 28.75
08/18/21 19:43:53, scheduler: switching to sieve method
08/18/21 19:43:53, starting SIQS on c70: 7725139683897973308307472537355787653622803183466786522414544405964523
08/18/21 19:43:53, random seed: 2108661816
08/18/21 19:43:53, prp70 = 7725139683897973308307472537355787653622803183466786522414544405964523
08/18/21 19:43:53, Total factoring time = 30.2247 seconds[/CODE]

My question is: Having finished the GMP-ECM method on C98 and now noticing what we are testing is C70, why not do a PRP test before starting SIQS and selecting a random seed, etc.?

[QUOTE=BudgieJane;586008]

My question is: Having finished the GMP-ECM method on C98 and now noticing what we are testing is C70, why not do a PRP test before starting SIQS and selecting a random seed, etc.?[/QUOTE]

No particular reason, but notice that it doesn't spend very long in SIQS. 0 seconds to be exact. Checking the input for various properties is the first thing siqs does. And also the first thing other routines do as well. It isn't part of the autofactorer loop because one could write something like this instead of factor, and then no primality test would be performed:

[CODE]
siqs(ecm(pm1(rho(trial(n,10000))), 100))
[/CODE]

While trying to do a 2.05 vs 2.06 benchmark, I discovered that the -batchfile option seems to be broken. When I run "yafu "siqs(@)" -batchfile in.bat", yafu quits with

[code]>> fopen error: No such file or directory
couldn't open R for reading[/code]

Happens on linux and windows. Old versions (pre v2) work properly.

PS. Thanks for all the excellent work over the last couple of months!

[QUOTE=charybdis;586017]While trying to do a 2.05 vs 2.06 benchmark, I discovered that the -batchfile option seems to be broken. When I run "yafu "siqs(@)" -batchfile in.bat", yafu quits with

[code]>> fopen error: No such file or directory
couldn't open R for reading[/code]

Happens on linux and windows. Old versions (pre v2) work properly.

PS. Thanks for all the excellent work over the last couple of months![/QUOTE]

Yes, I've noticed that as well but haven't got around to fixing it yet. Mostly because cat in.bat | yafu "siqs(@)" still works, somehow.

Also, fyi, yafu has a built-in siqs benchmark function:

./yafu "siqsbench"

Output is written to a bench.log file instead of factor.log.

This is what I run over and over again during testing.

[QUOTE=bsquared;586019]Also, fyi, yafu has a built-in siqs benchmark function:

./yafu "siqsbench"[/QUOTE]

Thank you for the tip! I'm seeing a >10% speedup at c90 and c95 :smile:

I'm having problems with version 2.06. It works OK on my new computer, running Windows 10 Pro, but it will not run on my old ones running Windows 7 Pro. It puts up the welcome message, waits something like half a minute, then quietly returns me to the command prompt:

[CODE]JANELT3 C:\Users\Jane\Documents\Maths\yafu\Versions\yafu-2.06 > yafu-x64


YAFU Version 2.06
Built with Microsoft Visual Studio 1922
Using GMP-ECM 7.0.4, Powered by MPIR 3.0.0
Detected Intel(R) Core(TM) i7-4710MQ CPU @ 2.50GHz
Detected L1 = 32768 bytes, L2 = 6291456 bytes, CL = 64 bytes
Using 1 random witness for Rabin-Miller PRP checks
Cached 664579 primes; max prime is 9999991

===============================================================
======= Welcome to YAFU (Yet Another Factoring Utility) =======
======= bbuhrow@gmail.com =======
======= Type help at any time, or quit to quit =======
===============================================================

>>
JANELT3 C:\Users\Jane\Documents\Maths\yafu\Versions\yafu-2.06 >[/CODE]

Is there something I ought to have somewhere on those old computers but which is missing, but the new computer does have it?

[QUOTE=BudgieJane;586247]I'm having problems with version 2.06. It works OK on my new computer, running Windows 10 Pro, but it will not run on my old ones running Windows 7 Pro. It puts up the welcome message, waits something like half a minute, then quietly returns me to the command prompt:

Is there something I ought to have somewhere on those old computers but which is missing, but the new computer does have it?[/QUOTE]

It works fine on my Windows 7 Pro x64.
[CODE]
C:\yafu\yafu_2.06>yafu-x64.exe


YAFU Version 2.06
Built with Microsoft Visual Studio 1922
Using GMP-ECM 7.0.4, Powered by MPIR 3.0.0
Detected Intel(R) Xeon(R) CPU E5-2687W v4 @ 3.00GHz
Detected L1 = 32768 bytes, L2 = 31457280 bytes, CL = 64 bytes
Using 1 random witness for Rabin-Miller PRP checks
Cached 664579 primes; max prime is 9999991

===============================================================
======= Welcome to YAFU (Yet Another Factoring Utility) =======
======= bbuhrow@gmail.com =======
======= Type help at any time, or quit to quit =======
===============================================================

>> factor(10^19+49)

fac: factoring 10000000000000000049
fac: using pretesting plan: normal
fac: no tune info: using qs/gnfs crossover of 100 digits
fac: no tune info: using qs/snfs crossover of 75 digits
div: primes less than 10000
fmt: 1000000 iterations
rho: x^2 + 3, starting 1000 iterations on C20
Total factoring time = 0.0400 seconds


***factors found***

PRP10 = 8532383917
PRP10 = 1172005397

ans = 1

>>
[/CODE]
I used the program Dependency Walker to see what dll's are linked/used by yafu. The ones I think you might be missing are VCOMP140.DLL and VCRUNTIME140.DLL.

These are included with the Microsoft Visual C++ Redistributable packages from Microsoft. You can find links to the latest here (I'd recommend both the 32-bit and 64-bit):
[url]https://support.microsoft.com/en-us/topic/the-latest-supported-visual-c-downloads-2647da03-1eea-4433-9aff-95f26a218cc0[/url]

[QUOTE=WraithX;586255]It works fine on my Windows 7 Pro x64.
[CODE]
...
[/CODE]
I used the program Dependency Walker to see what dll's are linked/used by yafu. The ones I think you might be missing are VCOMP140.DLL and VCRUNTIME140.DLL.

These are included with the Microsoft Visual C++ Redistributable packages from Microsoft. You can find links to the latest here (I'd recommend both the 32-bit and 64-bit):
[url]https://support.microsoft.com/en-us/topic/the-latest-supported-visual-c-downloads-2647da03-1eea-4433-9aff-95f26a218cc0[/url][/QUOTE]

No, I've got them. Dependency Walker says what are missing are these:
[CODE]API-MS-WIN-CORE-WINRT-ERROR-L1-1-0.DLL
API-MS-WIN-CORE-WINRT-L1-1-0.DLL
API-MS-WIN-CORE-WINRT-ROBUFFER-L1-1-0.DLL
API-MS-WIN-CORE-WINRT-STRING-L1-1-0.DLL
DCOMP.DLL
IESHIMS.DLL[/CODE]
and I searched the web for one of them and came up with [url]https://stackoverflow.com/questions/17023419/windows-7-64-bit-dll-problems[/url] which I've been looking at without much luck. I've also tried installing vc_redist.x64.exe, again no luck. About the only good thing that has come out of my fiddling with all this is that it has installed edge on my Win-7 machine (so much for lack of further support for Windoze 7!). I think the time has come to upgrade to Win-10 Pro for my development machine (now where can I get a decent one dirt cheap?)

[QUOTE=BudgieJane;586247]I'm having problems with version 2.06. It works OK on my new computer, running Windows 10 Pro, but it will not run on my old ones running Windows 7 Pro. It puts up the welcome message, waits something like half a minute, then quietly returns me to the command prompt[/QUOTE]I also just tried v2.06 (from [url=https://github.com/bbuhrow/yafu/archive/refs/heads/master.zip]master.zip[/url] downloaded an hour ago) on my i7-3930K on Win7pro64 where [c]yafu-x64.exe[/c] also fails. The first time I ran it it took a few (maybe 5) seconds before the crash dialog came up, subsquent runs in comes up near-immediately:[code]Problem signature:
Problem Event Name: APPCRASH
Application Name: yafu-x64.exe
Application Version: 0.0.0.0
Application Timestamp: 611c3335
Fault Module Name: yafu-x64.exe
Fault Module Version: 0.0.0.0
Fault Module Timestamp: 611c3335
Exception Code: c000001d
Exception Offset: 0000000000001300
OS Version: 6.1.7601.2.1.0.256.48
Locale ID: 1033
Additional Information 1: e63c
Additional Information 2: e63cb477893153aa77789ca6de3c6a1b
Additional Information 3: b40b
Additional Information 4: b40bbb931625d5f5f8d166d47cac51f6[/code]
[url=https://www.dependencywalker.com/]Dependency Walker[/url] shows the same list of missing DLLs that [i]BudgieJane[/i] [url=https://www.mersenneforum.org/showthread.php?p=586394]listed[/url].
edit: [url=https://social.msdn.microsoft.com/Forums/en-US/a28331ae-19a3-4a34-b3ba-1e8fd4430375/missing-apimswincore-dlls]this thread[/url] may contain relevant details.

If there is a setting in visual studio 2019 where I can link these things statically then I'd do that, but I don't know how at the moment.

I don't have access to any win7 systems to test on.

Here is a link to a zip file containing a statically linked YAFU x64 binary that might be worth a try:

[url]https://drive.google.com/file/d/1RaZuOfO-2L-InyHQc29pph0OvuYBS_Yy/view?usp=sharing[/url]

for those having DLL issues. I have to admit it seems unlikely to offer a solution.

[QUOTE=Brian Gladman;586412]Here is a link to a zip file containing a statically linked YAFU x64 binary that might be worth a try ... for those having DLL issues. I have to admit it seems unlikely to offer a solution.[/QUOTE]I tried it, it crashed the same way as the original.

[QUOTE=James Heinrich;586413]I tried it, it crashed the same way as the original.[/QUOTE]

I am not surprised since my build (and I suspect all current YAFU builds) use Windows SDK v10.

To get a working Windows 7 version all of yafu, mpir, gmp-ecm, ggnfs, pthreads and its other dependencies would all have to be rebuilt using Windows SDK 8.1 and this would be considerable undertaking.

Version 2.01 works OK on my Win-7 machine.

I am missing the same dll files as Budgie and James, but yafu 2.06 works fine on my Windows 7 Pro x64 computer.

I tried yafu-x64.exe from [url]https://github.com/bbuhrow/yafu[/url]
I tried yafu-x64.exe from master.zip from [url]https://github.com/bbuhrow/yafu/archive/refs/heads/master.zip[/url]
I tried the statically linked yafu-x64.exe that Brian shared

All of them work for me.

I was going to guess a possible instruction set issue, but I see that Budgie's i7-4710MQ has the same extensions as my E5-2687W v4. (except mine has TSX which is missing from Budgie's, but I wouldn't guess that's important here)

James's C000001D could make sense since his processor doesn't support as many instruction sets as Budgie's or mine. His processor is missing AVX2 and FMA3 (and TSX). Maybe this is contributing?

I found this online about C000001D. I'm not sure if this narrows down what might be going wrong, but maybe it can help with troubleshooting.
C000001D STATUS_ILLEGAL_INSTRUCTION EXCEPTION_ILLEGAL_INSTRUCTION

Budgie, can you run yafu-x64.exe and then after it crashes/stops, can you check your Windows Event Viewer -> Windows Logs -> Application log (or maybe System log) to see if the error is recorded in there? Maybe that will give us more information on what's going wrong?

Log Name: Application
Source: Application Error
Date: 24/08/2021 21:45:39
Event ID: 1005
Task Category: (100)
Level: Error
Keywords: Classic
User: N/A
Computer: JaneLT3
Description:
Windows cannot access the file for one of the following reasons: there is a problem with the network connection, the disk that the file is stored on, or the storage drivers installed on this computer; or the disk is missing. Windows closed the program yafu-x64.exe because of this error.

Program: yafu-x64.exe
File:

The error value is listed in the Additional Data section.
User Action
1. Open the file again. This situation might be a temporary problem that corrects itself when the program runs again.
2. If the file still cannot be accessed and
- It is on the network, your network administrator should verify that there is not a problem with the network and that the server can be contacted.
- It is on a removable disk, for example, a floppy disk or CD-ROM, verify that the disk is fully inserted into the computer.
3. Check and repair the file system by running CHKDSK. To run CHKDSK, click Start, click Run, type CMD, and then click OK. At the command prompt, type CHKDSK /F, and then press ENTER.
4. If the problem persists, restore the file from a backup copy.
5. Determine whether other files on the same disk can be opened. If not, the disk might be damaged. If it is a hard disk, contact your administrator or computer hardware vendor for further assistance.

Additional Data
Error value: 00000000
Disk type: 0
Event Xml:
<Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event">
<System>
<Provider Name="Application Error" />
<EventID Qualifiers="49152">1005</EventID>
<Level>2</Level>
<Task>100</Task>
<Keywords>0x80000000000000</Keywords>
<TimeCreated SystemTime="2021-08-24T20:45:39.000000000Z" />
<EventRecordID>664519</EventRecordID>
<Channel>Application</Channel>
<Computer>JaneLT3</Computer>
<Security />
</System>
<EventData>
<Data>
</Data>
<Data>yafu-x64.exe</Data>
<Data>00000000</Data>
<Data>0</Data>
</EventData>
</Event>

Log Name: Application
Source: Application Error
Date: 24/08/2021 21:45:39
Event ID: 1000
Task Category: (100)
Level: Error
Keywords: Classic
User: N/A
Computer: JaneLT3
Description:
Faulting application name: yafu-x64.exe, version: 0.0.0.0, time stamp: 0x611c3335
Faulting module name: yafu-x64.exe, version: 0.0.0.0, time stamp: 0x611c3335
Exception code: 0xc000001d
Fault offset: 0x0000000000002403
Faulting process id: 0x4d4
Faulting application start time: 0x01d79928fdf3fa53
Faulting application path: C:\Users\Jane\Documents\Maths\yafu\Versions\yafu-2.06\yafu-x64.exe
Faulting module path: C:\Users\Jane\Documents\Maths\yafu\Versions\yafu-2.06\yafu-x64.exe
Report Id: 3d352f22-051c-11ec-8f66-0cd292d9c1cc
Event Xml:
<Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event">
<System>
<Provider Name="Application Error" />
<EventID Qualifiers="0">1000</EventID>
<Level>2</Level>
<Task>100</Task>
<Keywords>0x80000000000000</Keywords>
<TimeCreated SystemTime="2021-08-24T20:45:39.000000000Z" />
<EventRecordID>664518</EventRecordID>
<Channel>Application</Channel>
<Computer>JaneLT3</Computer>
<Security />
</System>
<EventData>
<Data>yafu-x64.exe</Data>
<Data>0.0.0.0</Data>
<Data>611c3335</Data>
<Data>yafu-x64.exe</Data>
<Data>0.0.0.0</Data>
<Data>611c3335</Data>
<Data>c000001d</Data>
<Data>0000000000002403</Data>
<Data>4d4</Data>
<Data>01d79928fdf3fa53</Data>
<Data>C:\Users\Jane\Documents\Maths\yafu\Versions\yafu-2.06\yafu-x64.exe</Data>
<Data>C:\Users\Jane\Documents\Maths\yafu\Versions\yafu-2.06\yafu-x64.exe</Data>
<Data>3d352f22-051c-11ec-8f66-0cd292d9c1cc</Data>
</EventData>
</Event>

Don't know if you want to see this also:

[QUOTE=Brian Gladman;586412]Here is a link to a zip file containing a statically linked YAFU x64 binary that might be worth a try:

[url]https://drive.google.com/file/d/1RaZuOfO-2L-InyHQc29pph0OvuYBS_Yy/view?usp=sharing[/url]

for those having DLL issues. I have to admit it seems unlikely to offer a solution.[/QUOTE]

I got a system error: The program can't start because nvcuda.dll is missing from your computer. Try reinstalling the program to fix this problem.

[QUOTE=BudgieJane;586438]I got a system error: The program can't start because nvcuda.dll is missing from your computer. Try reinstalling the program to fix this problem.[/QUOTE]

It seems that I have missed a DLL dependency in the build.

I have run through all the library dependencies again to check they are static and rebuilt it here:

[url]https://drive.google.com/file/d/1L9SGu0_rv_CwdPofShq_zRqk1-d5SckP/view?usp=sharing[/url]

There are so many dependencies in building YAFU so its still possible that I have still missed a DLL dependency somewhere (in this case it should work if CUDA 11.4 is installed on your host since the DLL dependency would then be found).

[QUOTE=James Heinrich;586413]I tried it, it crashed the same way as the original.[/QUOTE]

[QUOTE=BudgieJane;586425]Version 2.01 works OK on my Win-7 machine.[/QUOTE]

[QUOTE=WraithX;586429]I am missing the same dll files as Budgie and James, but yafu 2.06 works fine on my Windows 7 Pro x64 computer.
[/QUOTE]

I don't know how we have entered dll hell and I don't know how to get out of it, especially given that I have been unable to reproduce the problem on any windows system I have access to (win10 enterprise, win10 home, on a variety of cpus).

I have gone through the effort over the last few months to make sure my windows build system was fully updated to the latest SDK and toolset for MSVC 19. I don't recall if that was done prior to the early releases such as 2.01, which is perhaps why that one works for BudgieJane. I suspect that Brian is correct and a full rebuild with an earlier SDK could be a solution. But that doesn't explain why some people with Win7 systems are able to use 2.06., so there must be a solution from a user perspective too. Just don't know what it is yet.

I think I'm a particularly oddball case in that I'm using both an old OS and a (very) old CPU (no AVX2 for example).
I don't know where to get a copy of v2.01 (that apparently work for other Win7 users), if someone wants to send me a copy I can confirm if it runs on my system or not.

[URL="http://github.com/bbuhrow/yafu/blob/d6cf245f72a7aadf68dea89ef5ff18396418c378/yafu-x64.exe"]Here[/URL] you go! :smile:

[QUOTE=James Heinrich;586481]I think I'm a particularly oddball case in that I'm using both an old OS and a (very) old CPU (no AVX2 for example).
I don't know where to get a copy of v2.01 (that apparently work for other Win7 users), if someone wants to send me a copy I can confirm if it runs on my system or not.[/QUOTE]

That would certainly mean that my build would fail with an illegal instruction exception since I build MPIR with AVX2 assembler support.

[QUOTE=James Heinrich;586481]I don't know where to get a copy of v2.01 (that apparently work for other Win7 users), if someone wants to send me a copy I can confirm if it runs on my system or not.[/QUOTE][QUOTE=kruoli;586482][URL="http://github.com/bbuhrow/yafu/blob/d6cf245f72a7aadf68dea89ef5ff18396418c378/yafu-x64.exe"]Here[/URL] you go! :smile:[/QUOTE]Thanks! But it crashes the same way all the others do.

Is YAFU command line only? If so, maybe it can be built with msys?

[QUOTE=rogue;586503]Is YAFU command line only? If so, maybe it can be built with msys?[/QUOTE]

Yes it does, but while it seems to work for me, people have reported problems/crashes there as well.

Given the availability nowadays of WSL2 and a much better visual studio implementation as of v2.06, I am actually in the process of abandoning the mingw64/msys2 build option and code from yafu. All these different options are getting to be too much for me to maintain.