When running the current build on GIT on an Ivy Bridge processor, I get an invalid instruction error (MULX, since Ivy Bridge does not support BMI(2)) at 0x000000013F571B43. This happens when the prompt ([C]>> [/C]) is already displayed. Is the processor too old to be supported out of the box?

2.07 looping
 

I've just had an incidence of version 2.07 looping. I'm factoring a C95 cofactor of 91+67.70, and it finds a PRP12 pretty quickly.
[CODE]11/09/21 10:56:48,
11/09/21 10:56:48, ****************************
11/09/21 10:56:48, Starting factorization of 37326054197207092012449090827705952368469419408554473227653125359479846855729858064360761261
11/09/21 10:56:48, using pretesting plan: noecm
11/09/21 10:56:48, no tune info: using qs/gnfs crossover of 95 digits
11/09/21 10:56:48, no tune info: using qs/snfs crossover of 75 digits
11/09/21 10:56:48, ****************************
11/09/21 10:56:48, rho: x^2 + 3, starting 1000 iterations on C92
11/09/21 10:56:48, rho: x^2 + 2, starting 1000 iterations on C92
11/09/21 10:56:48, prp12 = 129399203081
11/09/21 10:56:48, rho: x^2 + 2, starting 1000 iterations on C81
11/09/21 10:56:48, rho: x^2 + 1, starting 1000 iterations on C81
11/09/21 10:56:49, pm1: starting B1 = 150K, B2 = gmp-ecm default on C81
11/09/21 10:56:49, final ECM pretested depth: 0.00
11/09/21 10:56:49, scheduler: switching to sieve method
11/09/21 10:56:49, starting SIQS on c81: 288456600260838603397898547740484692177664798616755193922608276433886354497755781
11/09/21 10:56:49, random seed: 12023120550948929971
11/09/21 10:57:29, ==== sieve params ====
11/09/21 10:57:29, n = 82 digits, 273 bits
11/09/21 10:57:29, factor base: 49712 primes (max prime = 1290539)
11/09/21 10:57:29, single large prime cutoff: 122601205 (95 * pmax)
11/09/21 10:57:29, double large prime range from 1665490910521 to 362485408947117
11/09/21 10:57:29, DLP MFB = 1.80
11/09/21 10:57:29, allocating 7 large prime slices of factor base
11/09/21 10:57:29, buckets hold 2048 elements
11/09/21 10:57:29, large prime hashtables have 802816 bytes
11/09/21 10:57:29, using AVX2 enabled 32k sieve core
11/09/21 10:57:29, sieve interval: 7 blocks of size 32768
11/09/21 10:57:29, polynomial A has ~ 10 factors
11/09/21 10:57:29, using multiplier of 29
11/09/21 10:57:29, using multiplier of 29
11/09/21 10:57:29, using Q2(x) polynomials for kN mod 8 = 1
11/09/21 10:57:29, using SPV correction of 21 bits, starting at offset 34
11/09/21 10:57:29, trial factoring cutoff at 85 bits
11/09/21 10:57:29, ==== sieving started ( 4 threads) ====
11/09/21 10:58:27, trial division touched 12767107 sieve locations out of 51825213440
11/09/21 10:58:27, total reports = 12767107, total surviving reports = 3209794
11/09/21 10:58:27, total blocks sieved = 1581580, avg surviving reports per block = 2.03
11/09/21 10:58:27, dlp-ecm: 1 failures, 211956 attempts, 1466779 outside range, 1303807 prp, 204221 useful
11/09/21 10:58:27, 50298 relations found: 19524 full + 30774 from 411949 partial, using 112970 polys (437 A polys)
11/09/21 10:58:27, on average, sieving found 3.82 rels/poly and 4377.39 rels/sec
11/09/21 10:58:27, trial division touched 12767107 sieve locations out of 51825213440
11/09/21 10:58:27, ==== post processing stage (msieve-1.38) ====
11/09/21 10:58:27, QS elapsed time = 98.5686 seconds.
11/09/21 10:58:28, begin singleton removal with 431473 relations
11/09/21 10:58:28, reduce to 94979 relations in 9 passes
11/09/21 10:58:29, recovered 94979 relations
11/09/21 10:58:29, recovered 64291 polynomials
11/09/21 10:58:29, attempting to build 50298 cycles
11/09/21 10:58:29, found 50298 cycles from 94979 relations in 4 passes
11/09/21 10:58:29, distribution of cycle lengths:
11/09/21 10:58:29, length 1 : 19524
11/09/21 10:58:29, length 2 : 14882
11/09/21 10:58:29, length 3 : 8517
11/09/21 10:58:29, length 4 : 4253
11/09/21 10:58:29, length 5 : 1830
11/09/21 10:58:29, length 6 : 768
11/09/21 10:58:29, length 7 : 322
11/09/21 10:58:29, length 9+: 202
11/09/21 10:58:29, largest cycle: 15 relations
11/09/21 10:58:29, matrix is 49712 x 50298 (9.2 MB) with weight 2012082 (40.00/col)
11/09/21 10:58:29, sparse part has weight 2012082 (40.00/col)
11/09/21 10:58:29, filtering completed in 4 passes
11/09/21 10:58:29, matrix is 39980 x 40044 (7.5 MB) with weight 1648559 (41.17/col)
11/09/21 10:58:29, sparse part has weight 1648559 (41.17/col)
11/09/21 10:58:29, saving the first 48 matrix rows for later
11/09/21 10:58:29, matrix is 39932 x 40044 (6.4 MB) with weight 1394921 (34.83/col)
11/09/21 10:58:29, sparse part has weight 1275284 (31.85/col)
11/09/21 10:58:29, matrix includes 64 packed rows
11/09/21 10:58:29, using block size 16017 for processor cache size 6144 kB
11/09/21 10:58:29, commencing Lanczos iteration
11/09/21 10:58:29, memory use: 5.5 MB
11/09/21 10:58:33, lanczos halted after 633 iterations (dim = 39928)
11/09/21 10:58:33, recovered 17 nontrivial dependencies
11/09/21 10:58:34, Lanczos elapsed time = 5.3160 seconds.
11/09/21 10:58:34, Sqrt elapsed time = 0.8240 seconds.
11/09/21 10:58:34, SIQS elapsed time = 104.7100 seconds.
11/09/21 10:58:34,
[/CODE]

At this point it tries again, with a different random seed
[CODE]11/09/21 10:58:34, final ECM pretested depth: 0.00
11/09/21 10:58:34, scheduler: switching to sieve method
11/09/21 10:58:34, starting SIQS on c81: 288456600260838603397898547740484692177664798616755193922608276433886354497755781
11/09/21 10:58:34, random seed: 16728249449343881367
11/09/21 10:58:54, ==== sieve params ====
11/09/21 10:58:54, n = 82 digits, 273 bits
11/09/21 10:58:54, factor base: 49712 primes (max prime = 1290539)
11/09/21 10:58:54, single large prime cutoff: 122601205 (95 * pmax)
11/09/21 10:58:54, double large prime range from 1665490910521 to 362485408947117
11/09/21 10:58:54, DLP MFB = 1.80
11/09/21 10:58:54, using AVX2 enabled 32k sieve core
11/09/21 10:58:54, sieve interval: 7 blocks of size 32768
11/09/21 10:58:54, polynomial A has ~ 10 factors
11/09/21 10:58:54, using multiplier of 29
11/09/21 10:58:54, using multiplier of 29
11/09/21 10:58:54, using Q2(x) polynomials for kN mod 8 = 1
11/09/21 10:58:54, using SPV correction of 21 bits, starting at offset 34
11/09/21 10:58:54, trial factoring cutoff at 85 bits
11/09/21 10:58:54, ==== sieving started ( 4 threads) ====
11/09/21 10:58:54, trial division touched 0 sieve locations out of 0
11/09/21 10:58:54, total reports = 0, total surviving reports = 0
11/09/21 10:58:54, total blocks sieved = 0, avg surviving reports per block = -nan(ind)
11/09/21 10:58:54, dlp-ecm: 0 failures, 0 attempts, 0 outside range, 0 prp, 0 useful
11/09/21 10:58:54, 50299 relations found: 19524 full + 30775 from 411950 partial, using 0 polys (-1 A polys)
11/09/21 10:58:54, on average, sieving found inf rels/poly and 21100.86 rels/sec
11/09/21 10:58:54, trial division touched 0 sieve locations out of 0
11/09/21 10:58:54, ==== post processing stage (msieve-1.38) ====
11/09/21 10:58:54, QS elapsed time = 20.4612 seconds.
11/09/21 10:58:54, begin singleton removal with 431473 relations
11/09/21 10:58:54, reduce to 94980 relations in 9 passes
11/09/21 10:58:55, recovered 94980 relations
11/09/21 10:58:55, recovered 64292 polynomials
11/09/21 10:58:55, attempting to build 50298 cycles
11/09/21 10:58:55, found 50298 cycles from 94980 relations in 4 passes
11/09/21 10:58:55, distribution of cycle lengths:
11/09/21 10:58:55, length 1 : 19524
11/09/21 10:58:55, length 2 : 14882
11/09/21 10:58:55, length 3 : 8517
11/09/21 10:58:55, length 4 : 4253
11/09/21 10:58:55, length 5 : 1830
11/09/21 10:58:55, length 6 : 768
11/09/21 10:58:55, length 7 : 322
11/09/21 10:58:55, length 9+: 202
11/09/21 10:58:55, largest cycle: 15 relations
11/09/21 10:58:56, matrix is 49712 x 50298 (9.2 MB) with weight 2012093 (40.00/col)
11/09/21 10:58:56, sparse part has weight 2012093 (40.00/col)
11/09/21 10:58:56, filtering completed in 4 passes
11/09/21 10:58:56, matrix is 39980 x 40044 (7.5 MB) with weight 1648559 (41.17/col)
11/09/21 10:58:56, sparse part has weight 1648559 (41.17/col)
11/09/21 10:58:56, saving the first 48 matrix rows for later
11/09/21 10:58:56, matrix is 39932 x 40044 (6.4 MB) with weight 1394921 (34.83/col)
11/09/21 10:58:56, sparse part has weight 1275284 (31.85/col)
11/09/21 10:58:56, matrix includes 64 packed rows
11/09/21 10:58:56, using block size 16017 for processor cache size 6144 kB
11/09/21 10:58:56, commencing Lanczos iteration
11/09/21 10:58:56, memory use: 5.5 MB
11/09/21 10:58:59, lanczos halted after 633 iterations (dim = 39928)
11/09/21 10:58:59, recovered 17 nontrivial dependencies
11/09/21 10:59:00, Lanczos elapsed time = 5.2600 seconds.
11/09/21 10:59:00, Sqrt elapsed time = 0.7970 seconds.
11/09/21 10:59:00, SIQS elapsed time = 26.5175 seconds.
11/09/21 10:59:00,
11/09/21 10:59:00,
11/09/21 10:59:00, final ECM pretested depth: 0.00
11/09/21 10:59:00, scheduler: switching to sieve method
11/09/21 10:59:00, starting SIQS on c81: 288456600260838603397898547740484692177664798616755193922608276433886354497755781
11/09/21 10:59:00, random seed: 3384743676930672059
11/09/21 10:59:21, ==== sieve params ====
11/09/21 10:59:21, n = 82 digits, 273 bits
11/09/21 10:59:21, factor base: 49712 primes (max prime = 1290539)
11/09/21 10:59:21, single large prime cutoff: 122601205 (95 * pmax)
11/09/21 10:59:21, double large prime range from 1665490910521 to 362485408947117
11/09/21 10:59:21, DLP MFB = 1.80
11/09/21 10:59:21, using AVX2 enabled 32k sieve core
11/09/21 10:59:21, sieve interval: 7 blocks of size 32768
11/09/21 10:59:21, polynomial A has ~ 10 factors
11/09/21 10:59:21, using multiplier of 29
11/09/21 10:59:21, using multiplier of 29
11/09/21 10:59:21, using Q2(x) polynomials for kN mod 8 = 1
11/09/21 10:59:21, using SPV correction of 21 bits, starting at offset 34
11/09/21 10:59:21, trial factoring cutoff at 85 bits
11/09/21 10:59:21, ==== sieving started ( 4 threads) ====
11/09/21 10:59:21, trial division touched 0 sieve locations out of 0
11/09/21 10:59:21, total reports = 0, total surviving reports = 0
11/09/21 10:59:21, total blocks sieved = 0, avg surviving reports per block = -nan(ind)
11/09/21 10:59:21, dlp-ecm: 0 failures, 0 attempts, 0 outside range, 0 prp, 0 useful
11/09/21 10:59:21, 50299 relations found: 19524 full + 30775 from 411950 partial, using 0 polys (-1 A polys)
11/09/21 10:59:21, on average, sieving found inf rels/poly and 21060.69 rels/sec
11/09/21 10:59:21, trial division touched 0 sieve locations out of 0
11/09/21 10:59:21, ==== post processing stage (msieve-1.38) ====
11/09/21 10:59:21, QS elapsed time = 20.4872 seconds.
11/09/21 10:59:21, begin singleton removal with 431473 relations
11/09/21 10:59:21, reduce to 94980 relations in 9 passes
11/09/21 10:59:22, recovered 94980 relations
11/09/21 10:59:22, recovered 64292 polynomials
11/09/21 10:59:22, attempting to build 50298 cycles
11/09/21 10:59:22, found 50298 cycles from 94980 relations in 4 passes
11/09/21 10:59:22, distribution of cycle lengths:
11/09/21 10:59:22, length 1 : 19524
11/09/21 10:59:22, length 2 : 14882
11/09/21 10:59:22, length 3 : 8517
11/09/21 10:59:22, length 4 : 4253
11/09/21 10:59:22, length 5 : 1830
11/09/21 10:59:22, length 6 : 768
11/09/21 10:59:22, length 7 : 322
11/09/21 10:59:22, length 9+: 202
11/09/21 10:59:22, largest cycle: 15 relations
11/09/21 10:59:22, matrix is 49712 x 50298 (9.2 MB) with weight 2012093 (40.00/col)
11/09/21 10:59:22, sparse part has weight 2012093 (40.00/col)
11/09/21 10:59:22, filtering completed in 4 passes
11/09/21 10:59:22, matrix is 39980 x 40044 (7.5 MB) with weight 1648559 (41.17/col)
11/09/21 10:59:22, sparse part has weight 1648559 (41.17/col)
11/09/21 10:59:22, saving the first 48 matrix rows for later
11/09/21 10:59:22, matrix is 39932 x 40044 (6.4 MB) with weight 1394921 (34.83/col)
11/09/21 10:59:22, sparse part has weight 1275284 (31.85/col)
11/09/21 10:59:22, matrix includes 64 packed rows
11/09/21 10:59:22, using block size 16017 for processor cache size 6144 kB
11/09/21 10:59:23, commencing Lanczos iteration
11/09/21 10:59:23, memory use: 5.5 MB
11/09/21 10:59:26, lanczos halted after 633 iterations (dim = 39928)
11/09/21 10:59:26, recovered 17 nontrivial dependencies
11/09/21 10:59:27, Lanczos elapsed time = 5.3170 seconds.
11/09/21 10:59:27, Sqrt elapsed time = 0.7500 seconds.
11/09/21 10:59:27, SIQS elapsed time = 26.5545 seconds.
11/09/21 10:59:27,
11/09/21 10:59:27,
11/09/21 10:59:27, final ECM pretested depth: 0.00
11/09/21 10:59:27, scheduler: switching to sieve method
11/09/21 10:59:27, starting SIQS on c81: 288456600260838603397898547740484692177664798616755193922608276433886354497755781
11/09/21 10:59:27, random seed: 3034725368991286559
11/09/21 10:59:47, ==== sieve params ====
11/09/21 10:59:47, n = 82 digits, 273 bits
11/09/21 10:59:47, factor base: 49712 primes (max prime = 1290539)
11/09/21 10:59:47, single large prime cutoff: 122601205 (95 * pmax)
11/09/21 10:59:47, double large prime range from 1665490910521 to 362485408947117
11/09/21 10:59:47, DLP MFB = 1.80
11/09/21 10:59:47, using AVX2 enabled 32k sieve core
11/09/21 10:59:47, sieve interval: 7 blocks of size 32768
11/09/21 10:59:47, polynomial A has ~ 10 factors
11/09/21 10:59:47, using multiplier of 29
11/09/21 10:59:47, using multiplier of 29
11/09/21 10:59:47, using Q2(x) polynomials for kN mod 8 = 1
11/09/21 10:59:47, using SPV correction of 21 bits, starting at offset 34
11/09/21 10:59:47, trial factoring cutoff at 85 bits
11/09/21 10:59:47, ==== sieving started ( 4 threads) ====
11/09/21 10:59:47, trial division touched 0 sieve locations out of 0
11/09/21 10:59:47, total reports = 0, total surviving reports = 0
11/09/21 10:59:47, total blocks sieved = 0, avg surviving reports per block = -nan(ind)
11/09/21 10:59:47, dlp-ecm: 0 failures, 0 attempts, 0 outside range, 0 prp, 0 useful
11/09/21 10:59:47, 50299 relations found: 19524 full + 30775 from 411950 partial, using 0 polys (-1 A polys)
11/09/21 10:59:47, on average, sieving found inf rels/poly and 21098.80 rels/sec
11/09/21 10:59:47, trial division touched 0 sieve locations out of 0
11/09/21 10:59:47, ==== post processing stage (msieve-1.38) ====
11/09/21 10:59:47, QS elapsed time = 20.4502 seconds.
11/09/21 10:59:47, begin singleton removal with 431473 relations
11/09/21 10:59:48, reduce to 94980 relations in 9 passes
11/09/21 10:59:48, recovered 94980 relations
11/09/21 10:59:48, recovered 64292 polynomials
11/09/21 10:59:48, attempting to build 50298 cycles
11/09/21 10:59:48, found 50298 cycles from 94980 relations in 4 passes
11/09/21 10:59:48, distribution of cycle lengths:
11/09/21 10:59:48, length 1 : 19524
11/09/21 10:59:48, length 2 : 14882
11/09/21 10:59:48, length 3 : 8517
11/09/21 10:59:48, length 4 : 4253
11/09/21 10:59:48, length 5 : 1830
11/09/21 10:59:48, length 6 : 768
11/09/21 10:59:48, length 7 : 322
11/09/21 10:59:48, length 9+: 202
11/09/21 10:59:48, largest cycle: 15 relations
11/09/21 10:59:49, matrix is 49712 x 50298 (9.2 MB) with weight 2012093 (40.00/col)
11/09/21 10:59:49, sparse part has weight 2012093 (40.00/col)
11/09/21 10:59:49, filtering completed in 4 passes
11/09/21 10:59:49, matrix is 39980 x 40044 (7.5 MB) with weight 1648559 (41.17/col)
11/09/21 10:59:49, sparse part has weight 1648559 (41.17/col)
11/09/21 10:59:49, saving the first 48 matrix rows for later
11/09/21 10:59:49, matrix is 39932 x 40044 (6.4 MB) with weight 1394921 (34.83/col)
11/09/21 10:59:49, sparse part has weight 1275284 (31.85/col)
11/09/21 10:59:49, matrix includes 64 packed rows
11/09/21 10:59:49, using block size 16017 for processor cache size 6144 kB
11/09/21 10:59:49, commencing Lanczos iteration
11/09/21 10:59:49, memory use: 5.5 MB
11/09/21 10:59:52, lanczos halted after 633 iterations (dim = 39928)
11/09/21 10:59:52, recovered 17 nontrivial dependencies
11/09/21 10:59:53, Lanczos elapsed time = 5.2990 seconds.
11/09/21 10:59:53, Sqrt elapsed time = 0.8030 seconds.
11/09/21 10:59:53, SIQS elapsed time = 26.5515 seconds.
11/09/21 10:59:53,
11/09/21 10:59:53,
11/09/21 10:59:53, final ECM pretested depth: 0.00
11/09/21 10:59:53, scheduler: switching to sieve method
11/09/21 10:59:53, starting SIQS on c81: 288456600260838603397898547740484692177664798616755193922608276433886354497755781
11/09/21 10:59:53, random seed: 8235070506173952707
11/09/21 11:00:14, ==== sieve params ====
11/09/21 11:00:14, n = 82 digits, 273 bits
11/09/21 11:00:14, factor base: 49712 primes (max prime = 1290539)
11/09/21 11:00:14, single large prime cutoff: 122601205 (95 * pmax)
11/09/21 11:00:14, double large prime range from 1665490910521 to 362485408947117
11/09/21 11:00:14, DLP MFB = 1.80
11/09/21 11:00:14, using AVX2 enabled 32k sieve core
11/09/21 11:00:14, sieve interval: 7 blocks of size 32768
11/09/21 11:00:14, polynomial A has ~ 10 factors
11/09/21 11:00:14, using multiplier of 29
11/09/21 11:00:14, using multiplier of 29
11/09/21 11:00:14, using Q2(x) polynomials for kN mod 8 = 1
11/09/21 11:00:14, using SPV correction of 21 bits, starting at offset 34
11/09/21 11:00:14, trial factoring cutoff at 85 bits
11/09/21 11:00:14, ==== sieving started ( 4 threads) ====
11/09/21 11:00:14, trial division touched 0 sieve locations out of 0
11/09/21 11:00:14, total reports = 0, total surviving reports = 0
11/09/21 11:00:14, total blocks sieved = 0, avg surviving reports per block = -nan(ind)
11/09/21 11:00:14, dlp-ecm: 0 failures, 0 attempts, 0 outside range, 0 prp, 0 useful
11/09/21 11:00:14, 50299 relations found: 19524 full + 30775 from 411950 partial, using 0 polys (-1 A polys)
11/09/21 11:00:14, on average, sieving found inf rels/poly and 21075.09 rels/sec
11/09/21 11:00:14, trial division touched 0 sieve locations out of 0
11/09/21 11:00:14, ==== post processing stage (msieve-1.38) ====
11/09/21 11:00:14, QS elapsed time = 20.4742 seconds.
11/09/21 11:00:14, begin singleton removal with 431473 relations
11/09/21 11:00:14, reduce to 94980 relations in 9 passes
11/09/21 11:00:15, recovered 94980 relations
11/09/21 11:00:15, recovered 64292 polynomials
11/09/21 11:00:15, attempting to build 50298 cycles
11/09/21 11:00:15, found 50298 cycles from 94980 relations in 4 passes
11/09/21 11:00:15, distribution of cycle lengths:
11/09/21 11:00:15, length 1 : 19524
11/09/21 11:00:15, length 2 : 14882
11/09/21 11:00:15, length 3 : 8517
11/09/21 11:00:15, length 4 : 4253
11/09/21 11:00:15, length 5 : 1830
11/09/21 11:00:15, length 6 : 768
11/09/21 11:00:15, length 7 : 322
11/09/21 11:00:15, length 9+: 202
11/09/21 11:00:15, largest cycle: 15 relations
11/09/21 11:00:15, matrix is 49712 x 50298 (9.2 MB) with weight 2012093 (40.00/col)
11/09/21 11:00:15, sparse part has weight 2012093 (40.00/col)
11/09/21 11:00:15, filtering completed in 4 passes
11/09/21 11:00:15, matrix is 39980 x 40044 (7.5 MB) with weight 1648559 (41.17/col)
11/09/21 11:00:15, sparse part has weight 1648559 (41.17/col)
11/09/21 11:00:15, saving the first 48 matrix rows for later
11/09/21 11:00:15, matrix is 39932 x 40044 (6.4 MB) with weight 1394921 (34.83/col)
11/09/21 11:00:15, sparse part has weight 1275284 (31.85/col)
11/09/21 11:00:15, matrix includes 64 packed rows
11/09/21 11:00:15, using block size 16017 for processor cache size 6144 kB
11/09/21 11:00:16, commencing Lanczos iteration
11/09/21 11:00:16, memory use: 5.5 MB
11/09/21 11:00:19, lanczos halted after 633 iterations (dim = 39928)
11/09/21 11:00:19, recovered 17 nontrivial dependencies
11/09/21 11:00:20, Lanczos elapsed time = 5.1600 seconds.
11/09/21 11:00:20, Sqrt elapsed time = 0.8010 seconds.
11/09/21 11:00:20, SIQS elapsed time = 26.4345 seconds.
11/09/21 11:00:20,
[/CODE]

and so on. Having not found any more factors I stopped the process, then started it afresh with the C81. It immediately (well 27 seconds later) presented me with three beautiful bouncing factors.

[CODE]11/09/21 11:13:26,
11/09/21 11:13:26, ****************************
11/09/21 11:13:26, Starting factorization of 288456600260838603397898547740484692177664798616755193922608276433886354497755781
11/09/21 11:13:26, using pretesting plan: noecm
11/09/21 11:13:26, no tune info: using qs/gnfs crossover of 95 digits
11/09/21 11:13:26, no tune info: using qs/snfs crossover of 75 digits
11/09/21 11:13:26, ****************************
11/09/21 11:13:26, starting SIQS on c81: 288456600260838603397898547740484692177664798616755193922608276433886354497755781
11/09/21 11:13:26, random seed: 8066514638846999927
11/09/21 11:13:47, ==== sieve params ====
11/09/21 11:13:47, n = 82 digits, 273 bits
11/09/21 11:13:47, factor base: 49712 primes (max prime = 1290539)
11/09/21 11:13:47, single large prime cutoff: 122601205 (95 * pmax)
11/09/21 11:13:47, double large prime range from 1665490910521 to 362485408947117
11/09/21 11:13:47, DLP MFB = 1.80
11/09/21 11:13:47, using AVX2 enabled 32k sieve core
11/09/21 11:13:47, sieve interval: 7 blocks of size 32768
11/09/21 11:13:47, polynomial A has ~ 10 factors
11/09/21 11:13:47, using multiplier of 29
11/09/21 11:13:47, using multiplier of 29
11/09/21 11:13:47, using Q2(x) polynomials for kN mod 8 = 1
11/09/21 11:13:47, using SPV correction of 21 bits, starting at offset 34
11/09/21 11:13:47, trial factoring cutoff at 85 bits
11/09/21 11:13:47, ==== sieving started ( 4 threads) ====
11/09/21 11:13:47, trial division touched 0 sieve locations out of 0
11/09/21 11:13:47, total reports = 0, total surviving reports = 0
11/09/21 11:13:47, total blocks sieved = 0, avg surviving reports per block = -nan(ind)
11/09/21 11:13:47, dlp-ecm: 0 failures, 0 attempts, 0 outside range, 0 prp, 0 useful
11/09/21 11:13:47, 50299 relations found: 19524 full + 30775 from 411950 partial, using 0 polys (-1 A polys)
11/09/21 11:13:47, on average, sieving found inf rels/poly and 20714.87 rels/sec
11/09/21 11:13:47, trial division touched 0 sieve locations out of 0
11/09/21 11:13:47, ==== post processing stage (msieve-1.38) ====
11/09/21 11:13:47, QS elapsed time = 20.8292 seconds.
11/09/21 11:13:47, begin singleton removal with 431473 relations
11/09/21 11:13:47, reduce to 94980 relations in 9 passes
11/09/21 11:13:48, recovered 94980 relations
11/09/21 11:13:48, recovered 64292 polynomials
11/09/21 11:13:48, attempting to build 50298 cycles
11/09/21 11:13:48, found 50298 cycles from 94980 relations in 4 passes
11/09/21 11:13:48, distribution of cycle lengths:
11/09/21 11:13:48, length 1 : 19524
11/09/21 11:13:48, length 2 : 14882
11/09/21 11:13:48, length 3 : 8517
11/09/21 11:13:48, length 4 : 4253
11/09/21 11:13:48, length 5 : 1830
11/09/21 11:13:48, length 6 : 768
11/09/21 11:13:48, length 7 : 322
11/09/21 11:13:48, length 9+: 202
11/09/21 11:13:48, largest cycle: 15 relations
11/09/21 11:13:48, matrix is 49712 x 50298 (9.2 MB) with weight 2012093 (40.00/col)
11/09/21 11:13:48, sparse part has weight 2012093 (40.00/col)
11/09/21 11:13:49, filtering completed in 4 passes
11/09/21 11:13:49, matrix is 39980 x 40044 (7.5 MB) with weight 1648559 (41.17/col)
11/09/21 11:13:49, sparse part has weight 1648559 (41.17/col)
11/09/21 11:13:49, saving the first 48 matrix rows for later
11/09/21 11:13:49, matrix is 39932 x 40044 (6.4 MB) with weight 1394921 (34.83/col)
11/09/21 11:13:49, sparse part has weight 1275284 (31.85/col)
11/09/21 11:13:49, matrix includes 64 packed rows
11/09/21 11:13:49, using block size 16017 for processor cache size 6144 kB
11/09/21 11:13:49, commencing Lanczos iteration
11/09/21 11:13:49, memory use: 5.5 MB
11/09/21 11:13:52, lanczos halted after 633 iterations (dim = 39928)
11/09/21 11:13:52, recovered 17 nontrivial dependencies
11/09/21 11:13:52, prp18 = 988178592293402021
11/09/21 11:13:53, prp19 = 1346028033112095481
11/09/21 11:13:53, prp45 = 216865733067462219031336345962688918881760681
11/09/21 11:13:53, Lanczos elapsed time = 5.6540 seconds.
11/09/21 11:13:53, Sqrt elapsed time = 0.3800 seconds.
11/09/21 11:13:53, SIQS elapsed time = 26.8635 seconds.
11/09/21 11:13:53,
11/09/21 11:13:53,
11/09/21 11:13:53, Total factoring time = 27.0275 seconds
[/CODE]

Sorry this is a bit long, but I thought someone might like to see what was going on.

[B]bsquared[/B], is maximal digits count in version 2.07 - c1020?

[QUOTE=thyrex;593611][B]bsquared[/B], is maximal digits count in version 2.07 - c1020?[/QUOTE]

In theory, no, but plenty of weird stuff might happen with inputs near or larger than 1024 digits. Not a corner of the code I test very well.

Strange error (0xc0000005) when using Studio Kamada poly
 

When I try to factor 78888_142 (from Studio Kamada's near-repdigit tables), I get this crash:

[code]Faulting application name: yafu.exe, version: 0.0.0.0, time stamp: 0x611c3335
Faulting module name: yafu.exe, version: 0.0.0.0, time stamp: 0x611c3335
Exception code: 0xc0000005
Fault offset: 0x000000000015e3d9
Faulting process id: 0x1384
Faulting application start time: 0x01d7e15f4ab93ee3
Faulting application path: C:\Numbers\yafu-master\yafu.exe
Faulting module path: C:\Numbers\yafu-master\yafu.exe
Report Id: ceacc9fa-0596-4f6d-a151-a56041b94d89
Faulting package full name:
Faulting package-relative application ID: [/code]I used the poly that was supplied on the website, and put it in nfs.job: [URL]https://stdkmd.net/nrr/c.cgi?q=78888_142[/URL]

Why is it crashing? Is there something wrong with the poly? The only thing that was output to factor.log was this:

[code]11/24/21 13:15:42, nfs: commencing nfs on c137: 39628160596972006667354298974490180923204420136195848397615791252691924205059098424741546252872762571726970680519332067911281143827227471[/code]Here's what was output to the command prompt:

[code]C:\Numbers\yafu-master>yafu "snfs(71*10^142-8,39628160596972006667354298974490180923204420136195848397615791252691924205059098424741546252872762571726970680519332067911281143827227471)"
Applying tune_info entry for WIN64 - Intel(R) Core(TM) i5-9300H CPU @ 2.40GHz


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) 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 =======
===============================================================

>> nfs: checking for job file - job file found, testing for matching input
input from file = 39628160596972006667354298974490180923204420136195848397615791252691924205059098424741546252872762571726970680519332067911281143827227471
input to yafu = 709999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999992
input matches with multiple of 17916552
nfs: number in job file matches input
nfs: checking for data file
nfs: no data file found
nfs: commencing nfs on c137: 39628160596972006667354298974490180923204420136195848397615791252691924205059098424741546252872762571726970680519332067911281143827227471
nfs: resumesieve; last_spq = 0, nfs_phases = 0
nfs: found m: 100000000000000000000000000000000000
nfs: found c[4]: 1775
nfs: found c[0]: -2
nfs: found skew: 0.180000
nfs: found type: snfs
nfs: initializing snfs poly
nfs: parsed lpbr = 26, lpba = 26
nfs: detected snfs job but no snfs difficulty
nfs: using m and poly coefficients to compute difficulty
nfs: snfs difficulty: 38.249198
nfs: checking degree 4 poly
nfs: analyzing poly:[/code]

The same with Linux binary (seg fault), but I got it worked when I didn't set initial poly and let YAFU choose it for me.


I think m param is a problem in auto-generated poly at Kamada's site. It works when I replace
[CODE]m: 100000000000000000000000000000000000[/CODE]
to

[CODE]Y1: -1
Y0: 100000000000000000000000000000000000
[/CODE]

Is there any way to check if a number that is inputted for factoring is already listed in the factored.dat file, and if so verify the listed factors and if they are valid automatically output them without starting the factoring from scratch?

Strange SIQS-related crash. What's causing it?
 

Why does this number crash YAFU 2.06?

[code]72201646132199873461502083685639136119064441143576829474934045444051626750298129[/code]Here's the output to cmd:

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


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) 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 =======
===============================================================

>> fac: factoring 72201646132199873461502083685639136119064441143576829474934045444051626750298129
fac: using pretesting plan: deep
fac: using tune info for qs/gnfs crossover
input from file = 2204163746040422113335335630634510483693477785822927479792844125899447775787592580144299824908196479
input to yafu = 72201646132199873461502083685639136119064441143576829474934045444051626750298129
div: primes less than 10000
fmt: 1000000 iterations
93%fmt: performed 23 perfect square checks
rho: x^2 + 3, starting 1000 iterations on C80
rho: x^2 + 2, starting 1000 iterations on C80
rho: x^2 + 1, starting 1000 iterations on C80
nfs: searching for brent special forms...

<snip>

nfs: snfs form detection took 0.934170 seconds
nfs: couldn't find special form
pm1: starting B1 = 150K, B2 = gmp-ecm default on C80
pm1: Process took 0.0170 seconds.
pm1: found c36 factor = 256618303712888684191205903598313519
fac: setting target pretesting digits to 15.00
fac: estimated sum of completed work is t0.00
fac: work done at B1=2000: 0 curves, max work = 30 curves
fac: 30 more curves at B1=2000 needed to get to t15.00

Composite result found, starting re-factorization
fac: factoring 256618303712888684191205903598313519
fac: using pretesting plan: normal
fac: no tune info: using qs/gnfs crossover of 95 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 C36
rho: x^2 + 2, starting 1000 iterations on C36
rho: x^2 + 1, starting 1000 iterations on C36

starting SIQS on c36: 256618303712888684191205903598313519

C:\Numbers\yafu-master>[/code]factor.log:

[code]01/11/22 17:09:26,
01/11/22 17:09:26, ****************************
01/11/22 17:09:26, Starting factorization of 72201646132199873461502083685639136119064441143576829474934045444051626750298129
01/11/22 17:09:26, using pretesting plan: deep
01/11/22 17:09:26, using tune info for qs/gnfs crossover
01/11/22 17:09:26, ****************************
01/11/22 17:09:26, rho: x^2 + 3, starting 1000 iterations on C80
01/11/22 17:09:26, rho: x^2 + 2, starting 1000 iterations on C80
01/11/22 17:09:26, rho: x^2 + 1, starting 1000 iterations on C80
01/11/22 17:09:27, pm1: starting B1 = 150K, B2 = gmp-ecm default on C80
01/11/22 17:09:27, c36 = 256618303712888684191205903598313519
01/11/22 17:09:27, current ECM pretesting depth: 0.00
01/11/22 17:09:27, scheduled 30 curves at B1=2000 toward target pretesting depth of 15.00
01/11/22 17:09:27, prp45 = 281358130295261309435186241678306806768864191
01/11/22 17:09:27,
01/11/22 17:09:27, ****************************
01/11/22 17:09:27, Starting factorization of 256618303712888684191205903598313519
01/11/22 17:09:27, using pretesting plan: normal
01/11/22 17:09:27, no tune info: using qs/gnfs crossover of 95 digits
01/11/22 17:09:27, no tune info: using qs/snfs crossover of 75 digits
01/11/22 17:09:27, ****************************
01/11/22 17:09:27, rho: x^2 + 3, starting 1000 iterations on C36
01/11/22 17:09:27, rho: x^2 + 2, starting 1000 iterations on C36
01/11/22 17:09:27, rho: x^2 + 1, starting 1000 iterations on C36
01/11/22 17:09:27, final ECM pretested depth: 0.00
01/11/22 17:09:27, scheduler: switching to sieve method
01/11/22 17:09:27, starting SIQS on c36: 256618303712888684191205903598313519
01/11/22 17:09:27, random seed: 3836357694855539672
[/code]Error message (Event Viewer):

[code]Faulting application name: yafu.exe, version: 0.0.0.0, time stamp: 0x611c3335
Faulting module name: yafu.exe, version: 0.0.0.0, time stamp: 0x611c3335
Exception code: 0xc0000005
Fault offset: 0x000000000000be19
Faulting process id: 0x27fc
Faulting application start time: 0x01d80737e57dff6c
Faulting application path: C:\Numbers\yafu-master\yafu.exe
Faulting module path: C:\Numbers\yafu-master\yafu.exe
Report Id: dfd85e6a-3fcc-4269-b47c-a3f8a2a1eece
Faulting package full name:
Faulting package-relative application ID: [/code]

v2.08
 

Version 2.08 now available with a few bugfixes.

[QUOTE=Stargate38;597688]Why does this number crash YAFU 2.06?

[code]72201646132199873461502083685639136119064441143576829474934045444051626750298129[/code][/QUOTE]

Thanks, this should be fixed now in version 2.08.

[QUOTE=bsquared;599720]Version 2.08 now available with a few bugfixes.



Thanks, this should be fixed now in version 2.08.[/QUOTE]

I downloaded 2.08 and I've got the same problem I had with 2.07 when that was first available, in that it would appear that the Windows .exe file is missing a few bytes:

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


YAFU Version 2.08
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
Could not parse yafu.ini from C:\Users\Jane\Documents\Maths\yafu\Versions\yafu-2.08

===============================================================
======= 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.08 >[/CODE]

[QUOTE=bsquared;575505]It has been so long since a new windows executable and trunk code update have been released that I thought I might as well bump the version number to 2.....[/QUOTE]

I used to be able to run the older versions, but this, I doubt I would ever learn how. It searches for things I have no idea about. The help documentation may be helpful, but I cannot find it. Oh well. No big deal.

New Bug ?
 

Hello, we tested the number N with YAFU, YAFU can not finished this tasks.


N=factor((6414^13+17)*29848923566697359898432276895208549089323990314369)


The version is these here: [URL]https://github.com/bbuhrow/yafu/blob/master/bin/x64/Release/yafu-x64.exe[/URL]

[QUOTE]
poly_stage1_run done
**** finished poly work in thread 4
elapsed time: 21.6177 seconds (148 second deadline); poly select done
nfs: commencing algebraic side lattice sieving over range: 887500 - 890000
nfs: commencing algebraic side lattice sieving over range: 870000 - 872500
nfs: commencing algebraic side lattice sieving over range: 880000 - 882500
nfs: commencing algebraic side lattice sieving over range: 872500 - 875000
nfs: commencing algebraic side lattice sieving over range: 882500 - 885000
nfs: commencing algebraic side lattice sieving over range: 875000 - 877500
nfs: commencing algebraic side lattice sieving over range: 885000 - 887500
nfs: commencing algebraic side lattice sieving over range: 877500 - 880000
Der Befehl ".." ist entweder falsch geschrieben oder
konnte nicht gefunden werden.
Der
konnte nicht gefunden werden.
Der Befehl ".." ist entweder falsch geschrieben oder
konnte nicht gefunden werden.
Der Befehl ".." ist entweder falsch geschrieben oder
konnte nicht gefunden werden.
Der Befehl ".." ist entweder falsch geschrieben oder
konnte nicht gefunden werden.
Der Befehl ".." ist entweder falsch geschrieben oder
konnte nicht gefunden werden.
Der Befehl ".." ist entweder falsch geschrieben oder
konnte nicht gefunden werden.
nfs: could not open output file, possibly bad path to siever
nfs: could not open output file, possibly bad path to siever
nfs: could not open output file, possibly bad path to siever
nfs: could not open output file, possibly bad path to siever
nfs: could not open output file, possibly bad path to siever
nfs: could not open output file, possibly bad path to siever
nfs: could not open output file, possibly bad path to siever
nfs: could not open output file, possibly bad path to siever
fopen error: No such file or directory
could not open rels0.dat for reading

E:\YAFU_2022>
[/QUOTE]





greetings

[QUOTE=Cybertronic;601659]Hello, we tested the number N with YAFU, YAFU can not finished this tasks.[/QUOTE]Do you have these settings properly configured in [c]yafu.ini[/c]?[quote]ggnfs_dir=E:\YAFU_2022\ggnfs-bin\
ecm_path=E:\YAFU_2022\ecm\ecm.exe[/quote]And of course have the [url=https://download.mersenne.ca/GGNFS]GGNFS[/url] and [url=https://download.mersenne.ca/GMP-ECM]ECM[/url] files where you have it configured?

Ah ! You mean, YAFU need this helperprograms and it was not found ? Okay thx!

For what it's worth I just tried it in both v1.34.5 and v2.07 and it worked fine:[code]prp50 = 29848923566697359898432276895208549089323990314369
prp50 = 31093987719382384075336599461075903930020102201361[/code]

After upgrading to the current git version from 2.05, I got a way lower QS/NFS (98.4 to 93.1 digits) crossover. It does not look like NFS got magically faster, but QS slower. Unfortunately, I overwrote my old build. Stupid me.

Instead, after observing the above, I tried to build the current version with clang (AOCC version). Is there any chance we could figure out how to do this? At least gmp, msieve, ytools and ysieve built without problems. The first problem occured while compiling yafu and was:
[CODE]include/monty.h:145:19: error: invalid input constraint '0ULL' in asm
: "1"(c), "0ULL"(0), "r"(n));[/CODE]
I am not sure what clang is expecting instead here.

I committed a fix for the ULL issue, a silly copy/paste thing that I'm surprised gcc/icc doesn't flag. As for it being slower, are you building with the right options for your cpu? If you have AVX-512 then use:
NFS=1 USE_AVX2=1 USE_BMI2=1 SKYLAKEX=1

Since I am on Zen 3, I only built with AVX2 and BMI2. It also stated "using AVX2 enabled 32k sieve core" etc. I double checked and rebuilt with the parameters you suggested (ommiting the last one), and got a crossover of 93.0 bits this time.

When editing some files in vim, it occured to me that a lot of lines (e.g. the Makefile) end with [C]^M[/C], but it seems to be handled alright.

The next error is in ecm.c, where it states:
[CODE]factor/gmp-ecm/ecm.c:825:17: error: non-void function 'ecm_do_one_curve' should return a value [-Wreturn-type]
return;[/CODE]
In my local copy, I assumed [C]return NULL;[/C] here. Now it built! :smile: Interestingly, it gets detected as [I]Built with GCC 4[/I].
Unfortunately, I get a segmentation fault when I am in the first SIQS of tuning. I rebuilt with [C]-g[/C] and got ([C]gdb[/C] and [C]bt[/C]):
[Code]Program received signal SIGSEGV, Segmentation fault.
0x0000000000357844 in __gmpn_divrem_1 ()
(gdb) bt
#0 0x0000000000357844 in __gmpn_divrem_1 ()
#1 0x0000000000001832 in ?? ()
#2 0x0000000000001832 in ?? ()
#3 0x0000000002f207d0 in ?? ()
#4 0x0000000000001831 in ?? ()
#5 0x00000000003555bf in __gmpz_tdiv_q_ui ()
#6 0x000000000029ab1e in tdiv_LP_avx2 (report_num=<optimized out>, parity=<optimized out>, bnum=<optimized out>, sconf=<optimized out>, dconf=<optimized out>) at factor/qs/tdiv_large.c:604
#7 0x01cf01ce01cd01cc in ?? ()
#8 0x01d301d201d101d0 in ?? ()
#9 0x01d701d601d501d4 in ?? ()
#10 0x01db01da01d901d8 in ?? ()
#11 0x01df01de01dd01dc in ?? ()
#12 0x01e301e201e101e0 in ?? ()
#13 0x01e701e601e501e4 in ?? ()
#14 0x01eb01ea01e901e8 in ?? ()
#15 0x01ef01ee01ed01ec in ?? ()
#16 0x0000000200000002 in ?? ()
#17 0x0000000000355506 in __gmpz_tdiv_q_2exp ()
#18 0x000000000028f7db in process_poly (vptr=<optimized out>, vptr@entry=0x2c17c90) at factor/qs/SIQS.c:1108
#19 0x000000000028f00e in SIQS (fobj=fobj@entry=0x25a2ef0) at factor/qs/SIQS.c:828
#20 0x0000000000276d21 in factor_tune (inobj=0x25a2ef0) at factor/tune.c:140
#21 0x00000000002839b4 in feval (funcnum=funcnum@entry=72, nargs=<optimized out>, nargs@entry=0, metadata=<optimized out>, metadata@entry=0x7fffffffce60) at top/cmdParser/calc.c:2869
#22 0x000000000028194a in calc (in=in@entry=0x7fffffffccd0, metadata=<optimized out>, metadata@entry=0x7fffffffce60) at top/cmdParser/calc.c:1946
#23 0x0000000000280822 in calc_with_assignment (in=in@entry=0x25aa5e0, metadata=<optimized out>, metadata@entry=0x7fffffffce60, force_quiet=force_quiet@entry=0) at top/cmdParser/calc.c:1526
#24 0x000000000028069e in process_expression (input_exp=<optimized out>, metadata=<optimized out>, metadata@entry=0x7fffffffce60, force_quiet=<optimized out>, no_convert_result=<optimized out>, no_convert_result@entry=0)
at top/cmdParser/calc.c:1472
#25 0x000000000027404d in main (argc=<optimized out>, argv=<optimized out>) at top/driver.c:390[/Code]
Weird, it comes from GMP? I ran [C]make check[/C] there and all went fine.

The increase in SIQS time is giving me a headache:
I found old logs and picked 188859359342907532180448190281668092516979292823033816845808258496473426383608039973872193 (c90) as my example. The log stated 27.8 s in SIQS phase, I retried with the options as explained and the current GIT version and got 60.8 s. I retried with all GIT versions that identified as v2.05 and all segmentation faulted (see below why it might).

Conflicting processes can be ruled out by restarts and [C]htop[/C] run as root.

I cannot say for sure that I had BMI2 and also AVX2 enabled in my original build. But it would seem strange that this increased my performance. There is one single thing that changed, my Debian version, with that the GCC version. The log file that I have found was executed on Debian 11, so this alone is not the problem. But GCC 10 might be (as hinted to before in this thread). For example, my v2.05 versions built with GCC 10 were crashing in SIQS, my old GCC 8 version never crashed (in SIQS).

[QUOTE=kruoli;601815]The increase in SIQS time is giving me a headache:
I found old logs and picked 188859359342907532180448190281668092516979292823033816845808258496473426383608039973872193 (c90) as my example. The log stated 27.8 s in SIQS phase, I retried with the options as explained and the current GIT version and got 60.8 s. I retried with all GIT versions that identified as v2.05 and all segmentation faulted (see below why it might).

Conflicting processes can be ruled out by restarts and [C]htop[/C] run as root.

I cannot say for sure that I had BMI2 and also AVX2 enabled in my original build. But it would seem strange that this increased my performance. There is one single thing that changed, my Debian version, with that the GCC version. The log file that I have found was executed on Debian 11, so this alone is not the problem. But GCC 10 might be (as hinted to before in this thread). For example, my v2.05 versions built with GCC 10 were crashing in SIQS, my old GCC 8 version never crashed (in SIQS).[/QUOTE]

With gcc-11.1.0 on a Xeon 6254 for the sieving portion of siqs with 16 threads I get:
54 seconds with SSE2 (this is default)
49 seconds with SSE4.1
40 seconds with AVX/BMI2
29 seconds with AVX-512

linear algebra then adds about 8 seconds to all of these. The various instruction set flags do make a difference. With your timing you must be using a lot of threads, so LA might take an appreciable amount of time compared to sieving. It's a stretch, but are you comparing sieve time to total time between these measurements?

This is basically the same as with version 2.05, as far as I can see. I can't see how it would be different on a Zen 3, but crazier things have happened in yafu before. I don't have an AMD to test on, so thanks for bearing with me.

This weekend I'll install clang and work on the build.

Thank you!

There was another difference I oversaw: I had [C]-O3[/C] in my recent builds. I reverted this to [C]-O2[/C] and now the SIQS times are fine again!
[CODE]Elapsed time: 23.8909 sec
QS elapsed time = 23.8910 seconds.
[...]
SIQS elapsed time = 28.9506 seconds.[/CODE]
That's better than before!

Regarding [C]^M[/C], this seems to be [C]\r[/C] in some files. So there are files that contain mixed line ends. It should be quick to convert all files to [C]\n[/C] only.

[QUOTE=kruoli;601886]Thank you!

There was another difference I oversaw: I had [C]-O3[/C] in my recent builds. I reverted this to [C]-O2[/C] and now the SIQS times are fine again!
[CODE]Elapsed time: 23.8909 sec
QS elapsed time = 23.8910 seconds.
[...]
SIQS elapsed time = 28.9506 seconds.[/CODE]
That's better than before!

Regarding [C]^M[/C], this seems to be [C]\r[/C] in some files. So there are files that contain mixed line ends. It should be quick to convert all files to [C]\n[/C] only.[/QUOTE]

Great news, thanks!

I vaguely recall having issues like this with -O3 in the past, which is why it defaults to -O2, but I would not have thought of that as a culprit. Glad you found it.

When running YAFU2 (recent GIT version) with aliqueit, I need to run a script that checks for [I]running 0 auto-increasing ecm curves...[/I] in the output. Are you interested in finding a workaround for these? When I was "present" when something like this occured, it seemed always like a msieve problem (SIQS postprocessing was not able to finish or some other problem).

I have had similar occurrences on occasion and traced them to rare SIQS crashes. I've only briefly seen the actual messages from YAFU due to the way my scripts run, but the messages seemed to be a row vs. column matrix issue. I haven't pursued it much, because I set Msieve to run if YAFU fails (in aliqueit.ini). Now, if Aliqueit doesn't find any returned factors from YAFU (via factor.log), it runs Msieve. That has seemed to take care of it for me. But, I'm not using the -y YAFU switch, which might change things.

[QUOTE=BudgieJane;600227]I downloaded 2.08 and I've got the same problem I had with 2.07 when that was first available, in that it would appear that the Windows .exe file is missing a few bytes ...[/QUOTE]

I have bought myself a new laptop, and this one runs Windows 10 rather than Windows 7 that my old laptop was running. The good news is that Yafu 2.08 no longer crashes. However, there is some bad news:

[CODE]JANELT5 C:\Users\Jane\Documents\APLapps\Numbers > ..\..\Maths\yafu\Versions\yafu-2.08\yafu-x64


YAFU Version 2.08
Built with Microsoft Visual Studio 1922
Using GMP-ECM 7.0.4, Powered by MPIR 3.0.0
Detected 11th Gen Intel(R) Core(TM) i5-11300H @ 3.10GHz
Detected L1 = 49152 bytes, L2 = 8388608 bytes, CL = 64 bytes
Using 1 random witness for Rabin-Miller PRP checks
Cached 664579 primes; max prime is 9999991
Could not parse yafu.ini from C:\Users\Jane\Documents\APLapps\Numbers
[/CODE]

Which is all very well, but Yafu.ini is definitely there, and I can read it, as this shows:

[CODE]JANELT5 C:\Users\Jane\Documents\APLapps\Numbers > type yafu.ini
% This is yafu.ini from JaneLT5 as amended by tune. It is in C:\Users\Jane\Documents\APLapps\Numbers\
B1pm1=100000
B1pp1=20000
B1ecm=11000
rhomax=1000
threads=4
pretest_ratio=0.20
ggnfs_dir=..\..\Maths\ggnfs-x64\
ecm_path=..\..\Maths\ecm\ecm.exe
ext_ecm=10000
%tune_info=Intel(R) Core(TM) i7-4710MQ CPU @ 2.50GHz,WIN64,2.61946e-005,0.196468,0.240753,0.106352,95.27,2450.77
%tune_info=Intel(R) Core(TM) i7-4710MQ CPU @ 2.50GHz,WIN64,2.52059e-06,0.2279,6.39174,0.080593,100.104,42
tune_info=Intel(R) Core(TM) i5-11300H @ 3.10GHz,WIN64,2.52059e-06,0.2279,6.39174,0.080593,100.104,42

JANELT5 C:\Users\Jane\Documents\APLapps\Numbers >[/CODE]

Can anyone see where I might have made an error in the .ini file? I don't think I have, because it works OK with Yafu v.2.07.

Anyway, I ran tune, and it's obvious that I got the cpu-string wrong, because tune has ignored my tune_info (which was a copy of the previous version with what I thought was the proper cpu_string) and it has added another line to the file (which is the proof that it can read and write the file, even if it can't parse it, as shown above).

[CODE]tune_info=Intel(R) Core(TM) i5-11300H @ 3.10GHz,WIN64,2.52059e-06,0.2279,6.39174,0.080593,100.104,42
tune_info=11th Gen Intel(R) Core(TM) i5-11300H @ 3.10GHz,WIN64,7.11117e-06,0.200817,6.67832,0.0763865,110.525,42[/CODE]

So, what's going on here? I would like to run the latest version. As usual, if you want any more information, just ask.

[QUOTE=BudgieJane;602488]Can anyone see where I might have made an error in the .ini file?[/QUOTE]No. I tried it myself, and replicated what you got with [c]Could not parse yafu.ini[/c] using my 2.07 yafu.ini, but worked with the shipping version. So I went through it line by line, checking each change that might make it not parse. And none of them broke it.

Edit: Aha! I found the problem line. But I don't understand it.
If you comment out the [c]v[/c] on the verbosity line then it can't parse. Leave the single uncommented [c]v[/c] there and it parses.

[QUOTE=James Heinrich;602491]No. I tried it myself, and replicated what you got with [c]Could not parse yafu.ini[/c] using my 2.07 yafu.ini, but worked with the shipping version. So I went through it line by line, checking each change that might make it not parse. And none of them broke it.

Edit: Aha! I found the problem line. But I don't understand it.
If you comment out the [c]v[/c] on the verbosity line then it can't parse. Leave the single uncommented [c]v[/c] there and it parses.[/QUOTE]

I found the problem. For some dumb reason I surrounded the getcwd() command with a check for verbosity>0. So you have to have at least one -v for it to parse the .ini. :doh!:

Hopefully that workaround is good enough for now; I can get the exe updated soon, hopefully.

[QUOTE=bsquared;602532]I found the problem. For some dumb reason I surrounded the getcwd() command with a check for verbosity>0. So you have to have at least one -v for it to parse the .ini. :doh!:

Hopefully that workaround is good enough for now; I can get the exe updated soon, hopefully.[/QUOTE]

Actually, I'm wrong, you have to have one -v for it to *say* that it parsed the .ini file. It will parse it correctly regardless of what it says, it's just a reporting problem.

[QUOTE=bsquared;602535]Actually, I'm wrong, you have to have one -v for it to *say* that it parsed the .ini file. It will parse it correctly regardless of what it says, it's just a reporting problem.[/QUOTE]

So the workaround is to do nothing. I can live with that.

Thank you.

So, in general, I discovered, completely by trial and error, that when YAFU crashes on a particular number, it will usually work if you increase rhomax enough in yafu.ini.

I use a value of 1000 by default, but occasionally come across numbers that will crash yafu until I increase it to 10000, 20000 or even 100000. I usually use yafu to look for long aliquot sequences, and seldom factor numbers larger than about 100 digits.

As a novice, I don't know what that setting actually does, besides making factoring take a bit longer, but for fellow novices, I thought it was worth mentioning.

I would like to find some documentation as to how to use it. :confused:

With the current version, I still get [C]matrix must have more columns than rows[/C] in SIQS sometimes.
Example:
[CODE]starting SIQS on c81: 422751689472424067829539206601508400436611125331139179502143148987658541073541313
random seed: 17192571071955053739[/CODE]

[QUOTE=storm5510;602761]I would like to find some documentation as to how to use it. :confused:[/QUOTE]

Do you mean [URL="http://github.com/bbuhrow/yafu/blob/master/docfile.txt"]this[/URL]?

[QUOTE=kruoli;603743]Do you mean [URL="http://github.com/bbuhrow/yafu/blob/master/docfile.txt"]this[/URL]?[/QUOTE]

That would be it. I have problems navigating [I]Github[/I] for some reason.

Just a suggestion that would be (very) useful to me, perhaps others: output results in JSON format. I'm thinking something along the lines of:[code]{
"input-expression":"2^123/17",
"input-decimal:"625519056839960410778262146014279800",
"factors-prime":["2","2","2","3","3","5","5","7","11","13","31","41","61","151","241","331","1321"],
"factors-composite":["281406274007041"],
"ecm-curves":{"2000":30, "11000":74, "50000":216, "250000":432},
"ecm-levels":{"t15":38.02, "t20":11.32, "t25":1.06, "t30":0.07, "sum":25.34},
"time-start":"2022-04-25 16:25:34",
"time-end":"2022-04-25 18:34:56",
"runtime":{"total":7762.123, "ecm":762.456, "pm1":16.95, "siqs":7654.32}
}[/code](most of the above is made up for demonstration purposes)
The idea being to make a consistent, easily-parsable output format that can contain all the relevant information in one place. Undoubtedly there are some other values that can/should be included, the beauty is they can be added (or be missing) without breaking any parsing.
Obviously this output is only sane when an assignment is completed and can't be output during runtime as is done to factor.log but it would be an additional output.

While James's suggestion might be a lot of work, I find it tremendeous! Especially the example is really neat in regards to which data might/can be included.

A lot of this info is fairly easily available at the end of a factorization:
[CODE]

cat factor.json
{
"input-expression":"factor(2^351-1)",
"input-decimal":"4586997231980143023221641790604173881593129978336562247475177678773845752176969616140037106220251373109247",
"factors-prime":["7","73","79","937","6553","8191","86113","29121769","7830118297","571890896913727","93715008807883087","150832426800173710177","446473","121369"],
"factors-composite":["262657"],
"ecm-levels" : [],
"runtime" : ["total":0.4672, "ecm":0.0000, "pm1":0.0133, "pp1":0.0000, "siqs":0.0421, "nfs":0.0000],
}
{
"input-expression":"factor(2^371-1)",
"input-decimal":"4809815209520810450717656262224562232065397860164239095208531909697964083434718092213655548692006303809402830847",
"factors-prime":["127","743","2969","6361","69431","20394401","63781899287","204712366597949333831","145980337155634444285232523876979318451464756266456641329"],
"ecm-levels" : ["t15":43.89,"t20":12.78,"t25":1.18,"t30":0.07],
"runtime" : ["total":3.3807, "ecm":1.8949, "pm1":0.5183, "pp1":0.0000, "siqs":0.0000, "nfs":0.0000],
}
[/CODE]

That's what I have so far. All I know about JSON comes from looking at James's post, so keep that in mind. I'm basically just copying the formatting I saw. If something is broken let me know. The good thing is that this is an extra file, and won't break anything else. I can keep looking for low-hanging fruit to add to the output.

[QUOTE=bsquared;605248]That's what I have so far. All I know about JSON comes from looking at James's post[/QUOTE]That's great! :max:

Wikipedia of course has a decent rough overview of [url=https://en.wikipedia.org/wiki/JSON#Syntax]JSON syntax[/url].
And looking at that I see I made a mistake in my example: arrays (with no explicit keys, such as the list of factors) are specified with square brackets, but objects (in my example used as arrays with named keys) should be specified with curly braces.
So "ecm-curves", "ecm-levels", "runtime" should change from [c][square][/c] to [c]{curly}[/c]. Sorry about that.


edit: I'm not sure why [c]"factors-composite":["262657"],[/c] shows in your first example since that's prime. Or perhaps this was just a hand-edited example?

[QUOTE=James Heinrich;605249]That's great! :max:

Wikipedia of course has a decent rough overview of [url=https://en.wikipedia.org/wiki/JSON#Syntax]JSON syntax[/url].
And looking at that I see I made a mistake in my example: arrays (with no explicit keys, such as the list of factors) are specified with square brackets, but objects (in my example used as arrays with named keys) should be specified with curly braces.
So "ecm-curves", "ecm-levels", "runtime" should change from [c][square][/c] to [c]{curly}[/c]. Sorry about that.


edit: I'm not sure why [c]"factors-composite":["262657"],[/c] shows in your first example since that's prime. Or perhaps this was just a hand-edited example?[/QUOTE]

Thanks for the fix! I'm reading the syntax page but I will likely rely heavily on users to tell me when things are broken. The composite example was actually a bug... it's now fixed.

[CODE]
cat factor.json
{
"input-expression":"factor(2^351-1)",
"input-decimal":"4586997231980143023221641790604173881593129978336562247475177678773845752176969616140037106220251373109247",
"input-argument-string":"factor(2^351-1) -v ",
"factors-prime":["7","73","79","937","6553","8191","86113","262657","29121769","7830118297","571890896913727","93715008807883087","150832426800173710177","446473","121369"],
"pm1-curves" : {"150000":1},
"runtime" : {"total":0.5976, "ecm":0.0000, "pm1":0.0149, "pp1":0.0000, "siqs":0.0418, "nfs":0.0000},
"time-start" : "2022-05-04 13:26:58",
"time-end" : "2022-05-04 13:26:59",
}
{
"input-expression":"factor(2^371-1)",
"input-decimal":"4809815209520810450717656262224562232065397860164239095208531909697964083434718092213655548692006303809402830847",
"input-argument-string":"factor(2^371-1) -v -plan deep ",
"factors-prime":["127","743","2969","6361","69431","20394401","63781899287","204712366597949333831","145980337155634444285232523876979318451464756266456641329"],
"pm1-curves" : {"150000":1},
"ecm-curves" : {"2000":48,"11000":96,"50000":214},
"ecm-levels" : {"t15":40.03,"t20":11.50,"t25":1.06,"t30":0.07},
"runtime" : {"total":1.4576, "ecm":0.4515, "pm1":0.0472, "pp1":0.0000, "siqs":0.0000, "nfs":0.0000},
"time-start" : "2022-05-04 13:27:07",
"time-end" : "2022-05-04 13:27:08",
}
[/CODE]

[QUOTE=bsquared;605251]I will likely rely heavily on users to tell me when things are broken.[/QUOTE]I'm also not a JSON expert, I just find it a very useful, widely-supported, easy-to-craft, interchange format. :smile:

I found another mistake in my example: entries are comma-separated (and whitespace is ignored) but you can't have a null entry, specifically the last entry should not have a trailing comma.
Maybe you could make [c]"yafu-version":"2.3.xyz"[/c] the last entry.

One other potential thing to watch for is the [i]possible[/i] need to [url=https://stackoverflow.com/questions/983451]escape special characters[/url] that might appear in the [c]input-argument-string[/c] or elsewhere, perhaps you might run into a [c]"[/c] in the argument string for example?

I'm liking this quite a bit, hopefully it can be useful!

[CODE]
{
"input-expression":"factor(2^523-1)",
"input-decimal":"27459190640522438859927603196325572869077741200573221637577853836742172733590624208490238562645818219909185245565923432148487951998866575250296113164460228607",
"input-argument-string":"factor(2^523-1) -v -threads 32 -snfs_xover 70 -plan light ",
"factors-prime":["160188778313202118610543685368878688932828701136501444932217468039063","171417691861249198128317096534322116476165056718630345094896620367860006486977101859504089"],
"pm1-curves" : {"150000":1,"3750000":1},
"ecm-curves" : {"2000":256,"11000":256,"50000":256,"250000":256},
"ecm-levels" : {"t15":117.64,"t20":47.95,"t25":6.49,"t30":0.68,"t35":0.06},
"runtime" : {"total":1729.3813, "ecm":3.6256, "pm1":1.1629, "pp1":0.0000, "siqs":0.0000, "nfs-total":1720.8274, "nfs-poly":0.0000, "nfs-sieve":989.4496, "nfs-filter":405.3591, "nfs-la":175.4860, "nfs-sqrt":52.9520},
"time-start" : "2022-05-05 09:20:43",
"time-end" : "2022-05-05 09:49:33",
"info":{"compiler":"INTEL 2021","ECM-version":"7.0.4","GMP-version":"6.2.0","yafu-version":"2.08"}
}
[/CODE]

[QUOTE=bsquared;605289]I'm liking this quite a bit, hopefully it can be useful![/QUOTE]Looking great so far!

One thing from my example I don't see in your output (yet) is [c]ecm-levels.sum[/c]. It can be calculated by the user of course, but easier (for us) if you can include it in the output.

Hi,

to validate your JSON output, you can use the following website:
[URL="https://jsonlint.com/"]jsonlint.com[/URL]
or
[URL="https://jsonformatter.curiousconcept.com/"]jsonformatter[/URL]

=> ex: No comma at the end of the last line...

Enjoy.

[QUOTE=James Heinrich;604810]Just a suggestion that would be (very) useful to me, perhaps others: output results in JSON format. I'm thinking something along the lines of:[code]{
"input-expression":"2^123/17",
"input-decimal:"625519056839960410778262146014279800",
"factors-prime":["2","2","2","3","3","5","5","7","11","13","31","41","61","151","241","331","1321"],
"factors-composite":["281406274007041"],
"ecm-curves":{"2000":30, "11000":74, "50000":216, "250000":432},
"ecm-levels":{"t15":38.02, "t20":11.32, "t25":1.06, "t30":0.07, "sum":25.34},
"time-start":"2022-04-25 16:25:34",
"time-end":"2022-04-25 18:34:56",
"runtime":{"total":7762.123, "ecm":762.456, "pm1":16.95, "siqs":7654.32}
}[/code](most of the above is made up for demonstration purposes)
The idea being to make a consistent, easily-parsable output format that can contain all the relevant information in one place. Undoubtedly there are some other values that can/should be included, the beauty is they can be added (or be missing) without breaking any parsing.
Obviously this output is only sane when an assignment is completed and can't be output during runtime as is done to factor.log but it would be an additional output.[/QUOTE]

I would find it very useful, too.

I've just had a strange occurrence when factoring the C85 remnant of 225[SUP]90[/SUP]+8[SUP]90[/SUP]. Yafu finds the PRP14 and PRP15 factors in the ECM step, and then it carries on for a bit longer, until it suddenly stops running.

The log file has this:
[QUOTE]05/16/22 19:55:21, ****************************
05/16/22 19:55:21, Starting factorization of 6527241453816375542948001004083718646817094158516423588057982342841754799177671410161
05/16/22 19:55:21, using pretesting plan: normal
05/16/22 19:55:21, using tune info for qs/gnfs crossover
05/16/22 19:55:21, ****************************
05/16/22 19:55:21, rho: x^2 + 3, starting 1000 iterations on C85
05/16/22 19:55:21, rho: x^2 + 2, starting 1000 iterations on C85
05/16/22 19:55:21, rho: x^2 + 1, starting 1000 iterations on C85
05/16/22 19:55:22, pm1: starting B1 = 150K, B2 = gmp-ecm default on C85
05/16/22 19:55:22, current ECM pretesting depth: 0.00
05/16/22 19:55:22, scheduled 30 curves at B1=2000 toward target pretesting depth of 26.15
05/16/22 19:55:22, ecm: commencing 32 curves using AVX-ECM method on 6527241453816375542948001004083718646817094158516423588057982342841754799177671410161, B1=2k, B2=200k
05/16/22 19:55:22, ecm: finished 0 curves using AVX-ECM method on C85 input, B1=2k, B2=200k
05/16/22 19:55:22, prp15 = 340173882495361 (curve=3 stg=2 B1=2000 B2=200000 sigma=946092225 thread=0 vecpos=3)
05/16/22 19:55:22, prp14 = 26837982613801 (curve=6 stg=2 B1=2000 B2=200000 sigma=2888843093 thread=0 vecpos=6)
05/16/22 19:55:22, current ECM pretesting depth: 0.00
05/16/22 19:55:22, scheduled 30 curves at B1=2000 toward target pretesting depth of 17.54
05/16/22 19:55:22, ecm: commencing 32 curves using AVX-ECM method on 714955224866063780799923493058663443052770449650856853001, B1=2k, B2=200k
[/QUOTE]

Another file (the app's output, redirected) has this
[QUOTE]...
ecm: found prp15 factor = 340173882495361

ecm: found prp14 factor = 26837982613801
fac: setting target pretesting digits to 17.54
fac: estimated sum of completed work is t0.00
fac: work done at B1=2000: 0 curves, max work = 30 curves
fac: 30 more curves at B1=2000 needed to get to t17.54
process id is 21132
commencing parallel ecm on 714955224866063780799923493058663443052770449650856853001 with 4 threads
Mersenne input 2^282 - 1 determined to be faster by REDC
ECM has been configured with DIGITBITS = 52, VECLEN = 8, GMP_LIMB_BITS = 64
Choosing MAXBITS = 416, NWORDS = 4, NBLOCKS = 1 based on input size 189
configuring avx-ecm with 4 threads
Input has 189 bits, using 4 threads (8 curves/thread)
Processing in batches of 100000000 primes
Using 416-bit mul/sqr core
Initialization took 0.0055 seconds.
found 18061 primes in range [0 : 201000]
ecm: 32/32 curves on C57 @ B1=2000, B2=100*B1
[/QUOTE]

and that was all I got (I was running the program as a system call from another program, so I suppose any error message may well have been destroyed by that program recovering gracefully from the error).

Any suggestions will be warmly welcomed.

There is a fix for this in the latest source. Looks like I will need to make another windows executable.

[QUOTE=bsquared;605946]There is a fix for this in the latest source. Looks like I will need to make another windows executable.[/QUOTE]

That would be nice. Thank you.

[B]bsquared[/B], is current version from [url]https://github.com/bbuhrow/yafu[/url] (both yafu-x64.exe) don't work on Windows 10 Pro 21H2 ?

[QUOTE]This version of yafu-x64.exe is not compatible with the version of Windows running on this computer. Check your system information, and then contact software developer.[/QUOTE]

Is your OS and/or CPU 32-bit or 64-bit? If it's 32-bit, no 64-bit exe will work on it.

64-bit.

But I see "unsupported 16-bit application" in header of dialog error window. And size of .exe is around 125Kb only

File with 2.07 version has size above 2Mb

[QUOTE=thyrex;606834]But I see "unsupported 16-bit application" in header of dialog error window. And size of .exe is around 125Kb only. File with 2.07 version has size above 2Mb[/QUOTE]Maybe your download failed. The file available at [url]https://github.com/bbuhrow/yafu/blob/master/bin/x64/Release/yafu-x64.exe[/url] is (currently) 2,582,528 bytes.

When I try to build yafu under Ubuntu with [C]make NFS=1 USE_SSE41=1 USE_AVX=1[/C] it quits with:

[CODE]gcc -g -m64 -DUSE_SSE2 -DUSE_AVX2 -DUSE_SSE41 -mavx2 -DUSE_SSE41 -msse4.1 -DUSE_NFS -O2 -fomit-frame-pointer -Wall -I. -Iinclude -Itop/aprcl -Itop/cmdParser -Itop/ -I../ysieve -I../ytools -I/usr/local/include -I../msieve/zlib top/driver.o top/test.o factor/tune.o factor/autofactor.o top/cmdParser/cmdOptions.o top/cmdParser/calc.o -o yafu -lysiqs -lyecm -lynfs -L. -L../ysieve -L../ytools -L/usr/local/include -L../msieve/ -lmsieve -lecm /usr/lib/x86_64-linux-gnu/libgmp.a -lytools -lysieve -lpthread -lm -ldl
/usr/bin/ld: ./libysiqs.a(SIQS.o): in function `siqs_static_init':
/home/bur/Math/yafu/factor/qs/SIQS.c:2309: undefined reference to `nextRoots_32k_avx2_intrin'
/usr/bin/ld: ../msieve//libmsieve.a(savefile.o): in function `savefile_open':
savefile.c:(.text+0x142): undefined reference to `gzopen64'
/usr/bin/ld: savefile.c:(.text+0x266): undefined reference to `gzopen64'
/usr/bin/ld: savefile.c:(.text+0x2a1): undefined reference to `gzopen64'
/usr/bin/ld: ../msieve//libmsieve.a(savefile.o): in function `savefile_close':
savefile.c:(.text+0x341): undefined reference to `gzclose'
/usr/bin/ld: ../msieve//libmsieve.a(savefile.o): in function `savefile_write_line':
savefile.c:(.text+0x461): undefined reference to `gzputs'
/usr/bin/ld: ../msieve//libmsieve.a(savefile.o): in function `savefile_flush':
savefile.c:(.text+0x4e4): undefined reference to `gzputs'
/usr/bin/ld: ../msieve//libmsieve.a(savefile.o): in function `savefile_eof':
savefile.c:(.text+0x371): undefined reference to `gzeof'
/usr/bin/ld: ../msieve//libmsieve.a(savefile.o): in function `savefile_read_line':
savefile.c:(.text+0x3f0): undefined reference to `gzgets'
/usr/bin/ld: ../msieve//libmsieve.a(savefile.o): in function `savefile_rewind':
savefile.c:(.text+0x521): undefined reference to `gzrewind'
collect2: error: ld returned 1 exit status
make: *** [Makefile:368: yafu] Error 1[/CODE]

Omitting the [C]USE_AVX2=1[/C] flag, then it builds successfully.

I've got another of those "it won't factor it" jobbies in Yafu 2.08. For some reason it won't go into QS/SIQS.

[CODE]
06/20/22 16:15:39,
06/20/22 16:15:39, ****************************
06/20/22 16:15:39, Starting factorization of 7036874796802706717792076127030118075734377553821445738998743574873144601450291676951142421607390370359561
06/20/22 16:15:39, using pretesting plan: deep
06/20/22 16:15:39, using tune info for qs/gnfs crossover
06/20/22 16:15:39, ****************************
06/20/22 16:15:39, div: found prime factor = 137
06/20/22 16:15:39, div: found prime factor = 433
06/20/22 16:15:39, rho: x^2 + 3, starting 1000 iterations on C102
06/20/22 16:15:39, rho: x^2 + 2, starting 1000 iterations on C102
06/20/22 16:15:39, rho: x^2 + 1, starting 1000 iterations on C102
06/20/22 16:15:39, pm1: starting B1 = 150K, B2 = gmp-ecm default on C102
06/20/22 16:15:39, current ECM pretesting depth: 0.00
06/20/22 16:15:39, scheduled 30 curves at B1=2000 toward target pretesting depth of 34.00
06/20/22 16:15:39, ecm: commencing 32 curves using AVX-ECM method on 118623671158657249840563647393505134366149888805337835488254472697242875228844619560545884621085119441, B1=2k, B2=200k
06/20/22 16:15:39, ecm: finished 32 curves using AVX-ECM method on C102 input, B1=2k, B2=200k
06/20/22 16:15:39, current ECM pretesting depth: 15.19
06/20/22 16:15:39, scheduled 74 curves at B1=11000 toward target pretesting depth of 34.00
06/20/22 16:15:41, Finished 74 curves using GMP-ECM method on C102 input, B1=11k, B2=gmp-ecm default
06/20/22 16:15:41, current ECM pretesting depth: 20.24
06/20/22 16:15:41, scheduled 214 curves at B1=50000 toward target pretesting depth of 34.00
06/20/22 16:15:52, Finished 214 curves using GMP-ECM method on C102 input, B1=50k, B2=gmp-ecm default
06/20/22 16:15:52, pm1: starting B1 = 3750K, B2 = gmp-ecm default on C102
06/20/22 16:15:53, current ECM pretesting depth: 25.33
06/20/22 16:15:53, scheduled 430 curves at B1=250000 toward target pretesting depth of 34.00
06/20/22 16:17:25, Finished 430 curves using GMP-ECM method on C102 input, B1=250k, B2=gmp-ecm default
06/20/22 16:17:25, pm1: starting B1 = 15M, B2 = gmp-ecm default on C102
06/20/22 16:17:28, current ECM pretesting depth: 30.45
06/20/22 16:17:28, scheduled 643 curves at B1=1000000 toward target pretesting depth of 34.00
06/20/22 16:28:35, Finished 643 curves using GMP-ECM method on C102 input, B1=1M, B2=gmp-ecm default
06/20/22 16:28:35, final ECM pretested depth: 34.01
06/20/22 16:28:35, c102 cofactor = 118623671158657249840563647393505134366149888805337835488254472697242875228844619560545884621085119441
06/20/22 16:28:35, Total factoring time = 776.2737 seconds
[/CODE]

I thought this was fixed.

The next stage for this number must to be GNFS

No, a C102 can easily be solved by QS. It's not the ideal method, but shouldn't be more than 2-3x slower than GNFS.

[QUOTE=thyrex;608258]The next stage for this number must to be GNFS[/QUOTE]

According to tune_info the crossover point is 112:
[CODE]tune_info=11th Gen Intel(R) Core(TM) i5-11300H @ 3.10GHz,WIN64,8.83142e-06,0.197336,12.9645,0.0695818,111.146,42[/CODE]