[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]

I think I want to run away and hide. I found the reason why nvcuda.dll is missing from my computer: it's because my Win-7 computer does not have a NVIDIA graphics card. Extract from the specification:
Graphics Card: INTEL® HD GRAPHICS MEDIA ACCELERATOR 4600

So that explains why Brian's verson won't run.

[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]

Here's a copy of what I'm using.

[QUOTE=BudgieJane;586517]my Win-7 computer does not have a NVIDIA graphics card[/QUOTE]My computer doesn't have an NVIDIA card in it either (AMD RX480 now). But it used to in the past so it's got some copies of nvcuda.dll from 2015 still lurking in there.

[QUOTE=bsquared;586475]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.[/QUOTE]

I have come to a decision. All this new stuff will not run on my Win-7 machines, so I am giving up with those and I am going to use only my new Win-10-Pro machine. If I must run something on these old machines, I shall go back to version 1.34, which I was running until recently.

There is aboslutely NO WAY that I will expect anybody to prepare versions of their software that will run on 7-year-old machines that do not have the latest SDK and toolset together with the required hardware.

I would like to thank Ben for all his work so far, and would like to say thank-you in advance for future developments.

[QUOTE=bsquared;586505]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.[/QUOTE]

I think it is important to support other platforms. If interested I could build and test on OS X.

[QUOTE=rogue;586525]I think it is important to support other platforms. If interested I could build and test on OS X.[/QUOTE]

I just mean that I don't plan to keep building/testing on msys2 and won't be releasing any more windows executables that are produced by mingw64/msys2. I will always have a windows executable - it will just be produced by MSVC going forward. And WSL2 is another option running yafu on windows.

If you want to try to build and test on OS X please do! I will support you if I can. I've also had people express interest in getting yafu to run on apple's M1 arm-based processor. But with the heavy reliance on x86/x64 assembly code I have slim hopes of that working any time soon.

[QUOTE=BudgieJane;586520]
I would like to thank Ben for all his work so far, and would like to say thank-you in advance for future developments.[/QUOTE]

It's my pleasure, thank you. And please keep letting me know about issues; I may not always have an answer but it's how I learn. And nothing will get better if I don't know there is a problem.

[QUOTE=bsquared;586551]I just mean that I don't plan to keep building/testing on msys2 and won't be releasing any more windows executables that are produced by mingw64/msys2. I will always have a windows executable - it will just be produced by MSVC going forward. And WSL2 is another option running yafu on windows.

If you want to try to build and test on OS X please do! I will support you if I can. I've also had people express interest in getting yafu to run on apple's M1 arm-based processor. But with the heavy reliance on x86/x64 assembly code I have slim hopes of that working any time soon.[/QUOTE]

What is the best way for me to contact you? PM? e-mail? Discord? Something else?

PM will work for now.

I have a problem with the output file yafu generates. It contains the input number and factors in the format:

(input#)/factor1/factor2/factor3

Apparently factordb is unable to read this format. It's not hard to change it to input#=factor1*factor2*factor3 which factordb can read, but I wonder if it's possible to have yafu output the factors in a different way?

I can't get CUDA Poly selection to work.

[code]searching leading coefficients from 8942 to 9192
using GPU 0 (NVIDIA GeForce GTX 1650)
selected card has CUDA arch 7.5
using GPU 0 (NVIDIA GeForce GTX 1650)
selected card has CUDA arch 7.5
using GPU 0 (NVIDIA GeForce GTX 1650)
selected card has CUDA arch 7.5
using GPU 0 (NVIDIA GeForce GTX 1650)
selected card has CUDA arch 7.5
using GPU 0 (NVIDIA GeForce GTX 1650)
selected card has CUDA arch 7.5
using GPU 0 (NVIDIA GeForce GTX 1650)
selected card has CUDA arch 7.5
using GPU 0 (NVIDIA GeForce GTX 1650)
error: GPU sort engine not found at "C:\Numbers\aliqueit112\cub\sort_engine.dll"
using GPU 0 (NVIDIA GeForce GTX 1650)
selected card has CUDA arch 7.5
error: GPU sort engine not found at "C:\Numbers\aliqueit112\cub\sort_engine.dll"
error: GPU sort engine not found at "C:\Numbers\aliqueit112\cub\sort_engine.dll"
error: GPU sort engine not found at "C:\Numbers\aliqueit112\cub\sort_engine.dll"
selected card has CUDA arch 7.5
error: GPU sort engine not found at "C:\Numbers\aliqueit112\cub\sort_engine.dll"
error: GPU sort engine not found at "C:\Numbers\aliqueit112\cub\sort_engine.dll"[/code]Anyone know where to get that Sort_engine.dll? I tried a version that I found on this forum, but YAFU gave me this:

[code]searching leading coefficients from 9442 to 9692
using GPU 0 (NVIDIA GeForce GTX 1650)
selected card has CUDA arch 7.5
using GPU 0 (NVIDIA GeForce GTX 1650)
selected card has CUDA arch 7.5
using GPU 0 (NVIDIA GeForce GTX 1650)
selected card has CUDA arch 7.5
using GPU 0 (NVIDIA GeForce GTX 1650)
selected card has CUDA arch 7.5
using GPU 0 (NVIDIA GeForce GTX 1650)
deadline: 8640000 CPU-seconds per coefficient
using GPU 0 (NVIDIA GeForce GTX 1650)
selected card has CUDA arch 7.5
using GPU 0 (NVIDIA GeForce GTX 1650)
selected card has CUDA arch 7.5
using GPU 0 (NVIDIA GeForce GTX 1650)
selected card has CUDA arch 7.5
selected card has CUDA arch 7.5
deadline: 8640000 CPU-seconds per coefficient
deadline: 8640000 CPU-seconds per coefficient
deadline: 8640000 CPU-seconds per coefficient
deadline: 8640000 CPU-seconds per coefficient
deadline: 8640000 CPU-seconds per coefficient
deadline: 8640000 CPU-seconds per coefficient
deadline: 8640000 CPU-seconds per coefficient
error (line 1128): CUDA_ERROR_FILE_NOT_FOUND
error (line 1128): CUDA_ERROR_FILE_NOT_FOUND[/code]YAFU Info:

[code]YAFU Version 2.06
Built with Microsoft Visual C/C++ 1929
Using GMP-ECM 7.0.5-dev, 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[/code]Number I'm trying to factor:

[code]48459122254139394182129172328473262875134312328758582582515084646652819439706917682551935490060136608549891[/code]

Anyone know what file is missing when it says "CUDA_ERROR_FILE_NOT_FOUND"? I think error messages should be made more specific/verbose.

[QUOTE=Stargate38;587072]I can't get CUDA Poly selection to work.

Anyone know what file is missing when it says "CUDA_ERROR_FILE_NOT_FOUND"? I think error messages should be made more specific/verbose.[/QUOTE]

I think the msieve sort engine is missing, here is a link to a zip file containing it:

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

I assume that the directory 'cub' containing sort_engine.dll has to be in the directory holding the yafu executable file.

[QUOTE=Stargate38;587072]I can't get CUDA Poly selection to work.

[code]searching leading coefficients from 8942 to 9192
using GPU 0 (NVIDIA GeForce GTX 1650)
selected card has CUDA arch 7.5
using GPU 0 (NVIDIA GeForce GTX 1650)
selected card has CUDA arch 7.5
using GPU 0 (NVIDIA GeForce GTX 1650)
selected card has CUDA arch 7.5
using GPU 0 (NVIDIA GeForce GTX 1650)
selected card has CUDA arch 7.5
using GPU 0 (NVIDIA GeForce GTX 1650)
selected card has CUDA arch 7.5
using GPU 0 (NVIDIA GeForce GTX 1650)
selected card has CUDA arch 7.5
using GPU 0 (NVIDIA GeForce GTX 1650)
error: GPU sort engine not found at "C:\Numbers\aliqueit112\cub\sort_engine.dll"
using GPU 0 (NVIDIA GeForce GTX 1650)
selected card has CUDA arch 7.5
error: GPU sort engine not found at "C:\Numbers\aliqueit112\cub\sort_engine.dll"
error: GPU sort engine not found at "C:\Numbers\aliqueit112\cub\sort_engine.dll"
error: GPU sort engine not found at "C:\Numbers\aliqueit112\cub\sort_engine.dll"
selected card has CUDA arch 7.5
error: GPU sort engine not found at "C:\Numbers\aliqueit112\cub\sort_engine.dll"
error: GPU sort engine not found at "C:\Numbers\aliqueit112\cub\sort_engine.dll"[/code]Anyone know where to get that Sort_engine.dll? I tried a version that I found on this forum, but YAFU gave me this:

[code]searching leading coefficients from 9442 to 9692
using GPU 0 (NVIDIA GeForce GTX 1650)
selected card has CUDA arch 7.5
using GPU 0 (NVIDIA GeForce GTX 1650)
selected card has CUDA arch 7.5
using GPU 0 (NVIDIA GeForce GTX 1650)
selected card has CUDA arch 7.5
using GPU 0 (NVIDIA GeForce GTX 1650)
selected card has CUDA arch 7.5
using GPU 0 (NVIDIA GeForce GTX 1650)
deadline: 8640000 CPU-seconds per coefficient
using GPU 0 (NVIDIA GeForce GTX 1650)
selected card has CUDA arch 7.5
using GPU 0 (NVIDIA GeForce GTX 1650)
selected card has CUDA arch 7.5
using GPU 0 (NVIDIA GeForce GTX 1650)
selected card has CUDA arch 7.5
selected card has CUDA arch 7.5
deadline: 8640000 CPU-seconds per coefficient
deadline: 8640000 CPU-seconds per coefficient
deadline: 8640000 CPU-seconds per coefficient
deadline: 8640000 CPU-seconds per coefficient
deadline: 8640000 CPU-seconds per coefficient
deadline: 8640000 CPU-seconds per coefficient
deadline: 8640000 CPU-seconds per coefficient
error (line 1128): CUDA_ERROR_FILE_NOT_FOUND
error (line 1128): CUDA_ERROR_FILE_NOT_FOUND[/code]YAFU Info:

[code]YAFU Version 2.06
Built with Microsoft Visual C/C++ 1929
Using GMP-ECM 7.0.5-dev, 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[/code]Number I'm trying to factor:

[code]48459122254139394182129172328473262875134312328758582582515084646652819439706917682551935490060136608549891[/code]

Anyone know what file is missing when it says "CUDA_ERROR_FILE_NOT_FOUND"? I think error messages should be made more specific/verbose.[/QUOTE]

Which version of msieve are you using? I would recommend you download the updated source code from [url]https://sourceforge.net/p/msieve/code/HEAD/tree/trunk/[/url] and build it yourself from the build.cuda.vs directory.

Edit: This is more of something you should attempt if the solution above from Brian Gladman doesn't work for you.

I'm using the most recent YAFU 2.x executable (from BSquared's GitHub), with internal poly selection. Brian Gladman's solution didn't work completely (still getting "error (line 1128): CUDA_ERROR_FILE_NOT_FOUND").

EDIT: I redownloaded YAFU from the GitHub repo, and it's working now. Must've downloaded the version that BudgieJane attached on post #196.

[QUOTE=Stargate38;587088]I'm using the most recent YAFU 2.x executable (from BSquared's GitHub), with internal poly selection. Brian Gladman's solution didn't work completely (still getting "error (line 1128): CUDA_ERROR_FILE_NOT_FOUND").

EDIT: I redownloaded YAFU from the GitHub repo, and it's working now. Must've downloaded the version that BudgieJane attached on post #196.[/QUOTE]

I think CUDA_ERROR_FILE_NOT_FOUND refers to the stage1_core_sm**.ptx file; it is supposed to be next to the executable. The sort_engine.dll file should be in a directory called cub beneath the executable.

[QUOTE=bsquared;587090]I think CUDA_ERROR_FILE_NOT_FOUND refers to the stage1_core_sm**.ptx file; it is supposed to be next to the executable. The sort_engine.dll file should be in a directory called cub beneath the executable.[/QUOTE]

Here are my files from a working msieve (as a zip file):

[url]https://drive.google.com/file/d/1055dDkjQtyz08VfO6-jQbyagPSxIaxy2/view?usp=sharing[/url]

Having issues building w/ AVX512 support.



This command, which seems like it should work by itself from a glance at the Makefile, is exiting with many errors. [CODE]make ICELAKE=1 -j72[/CODE]

[CODE]./libysiqs.a(SIQS.o): In function `process_poly':
/root/yafu/factor/qs/SIQS.c:1282: undefined reference to `nextRoots_32k_avx2_small'
./libysiqs.a(SIQS.o): In function `siqs_static_init':
/root/yafu/factor/qs/SIQS.c:2153: undefined reference to `tdiv_medprimes_32k_avx2'
/root/yafu/factor/qs/SIQS.c:2164: undefined reference to `resieve_medprimes_32k_avx512bw'
/root/yafu/factor/qs/SIQS.c:2165: undefined reference to `med_sieveblock_32k_avx512bw'
/root/yafu/factor/qs/SIQS.c:2209: undefined reference to `resieve_medprimes_32k_avx2'
/root/yafu/factor/qs/SIQS.c:2210: undefined reference to `tdiv_medprimes_32k_avx2'
/root/yafu/factor/qs/SIQS.c:2212: undefined reference to `med_sieveblock_32k_avx2'
/root/yafu/factor/qs/SIQS.c:2241: undefined reference to `nextRoots_32k_avx2_intrin'
/root/yafu/factor/qs/SIQS.c:2256: undefined reference to `nextRoots_32k_sse41'
/root/yafu/factor/qs/SIQS.c:2257: undefined reference to `med_sieveblock_32k_sse41'
/root/yafu/factor/qs/SIQS.c:2164: undefined reference to `resieve_medprimes_32k_avx512bw'
/root/yafu/factor/qs/SIQS.c:2165: undefined reference to `med_sieveblock_32k_avx512bw'
/root/yafu/factor/qs/SIQS.c:2176: undefined reference to `resieve_medprimes_32k_avx2'
/root/yafu/factor/qs/SIQS.c:2178: undefined reference to `med_sieveblock_32k_avx2'
/root/yafu/factor/qs/SIQS.c:2249: undefined reference to `nextRoots_32k_avx2'
/root/yafu/factor/qs/SIQS.c:2176: undefined reference to `resieve_medprimes_32k_avx2'
/root/yafu/factor/qs/SIQS.c:2178: undefined reference to `med_sieveblock_32k_avx2'
collect2: error: ld returned 1 exit status
Makefile:415: recipe for target 'yafu' failed
make: *** [yafu] Error 1
[/CODE]
Running make with these arguments has fixed most of the undefined references, but some still remain.[CODE]make ICELAKE=1 SKYLAKEX=1 USE_AVX2=1 USE_BMI2=1 NFS=1 -j72[/CODE][CODE]./libysiqs.a(SIQS.o): In function `siqs_static_init':
/root/yafu/factor/qs/SIQS.c:2164: undefined reference to `resieve_medprimes_32k_avx512bw'
/root/yafu/factor/qs/SIQS.c:2165: undefined reference to `med_sieveblock_32k_avx512bw'
/root/yafu/factor/qs/SIQS.c:2164: undefined reference to `resieve_medprimes_32k_avx512bw'
/root/yafu/factor/qs/SIQS.c:2165: undefined reference to `med_sieveblock_32k_avx512bw'
collect2: error: ld returned 1 exit status
Makefile:415: recipe for target 'yafu' failed
make: *** [yafu] Error 1
[/CODE]


Any help would be greatly appreciated, thank you!

[QUOTE=Plutie;587121]Having issues building w/ AVX512 support.


Running make with these arguments has fixed most of the undefined references, but some still remain.[CODE]make ICELAKE=1 SKYLAKEX=1 USE_AVX2=1 USE_BMI2=1 NFS=1 -j72[/CODE][CODE]./libysiqs.a(SIQS.o): In function `siqs_static_init':
/root/yafu/factor/qs/SIQS.c:2164: undefined reference to `resieve_medprimes_32k_avx512bw'
/root/yafu/factor/qs/SIQS.c:2165: undefined reference to `med_sieveblock_32k_avx512bw'
/root/yafu/factor/qs/SIQS.c:2164: undefined reference to `resieve_medprimes_32k_avx512bw'
/root/yafu/factor/qs/SIQS.c:2165: undefined reference to `med_sieveblock_32k_avx512bw'
collect2: error: ld returned 1 exit status
Makefile:415: recipe for target 'yafu' failed
make: *** [yafu] Error 1
[/CODE]


Any help would be greatly appreciated, thank you![/QUOTE]

Can you verify that when building files and linking you actually see these flags being passed:

gcc -g -DUSE_SSE2 -DUSE_BMI2 -DUSE_AVX2 -DUSE_AVX512F -DUSE_AVX512BW -DSKYLAKEX -DIFMA -march=icelake-client ...

Particularly, the -DUSE_AVX512BW flag.

Actually, I think you just have to do a clean with the flags specified:

make clean ICELAKE=1 SKYLAKEX=1 USE_AVX2=1 USE_BMI2=1 NFS=1

then remake. If the relevant file (med_sieve_32k_avx2.c) was compiled before without -DUSE_AVX512BW then make won't re-build it just because a new flag is specified, the old object file first has to be removed (or source file touched).

[QUOTE=bsquared;587126]Can you verify that when building files and linking you actually see these flags being passed:

gcc -g -DUSE_SSE2 -DUSE_BMI2 -DUSE_AVX2 -DUSE_AVX512F -DUSE_AVX512BW -DSKYLAKEX -DIFMA -march=icelake-client ...

Particularly, the -DUSE_AVX512BW flag.

Actually, I think you just have to do a clean with the flags specified:

make clean ICELAKE=1 SKYLAKEX=1 USE_AVX2=1 USE_BMI2=1 NFS=1

then remake. If the relevant file (med_sieve_32k_avx2.c) was compiled before without -DUSE_AVX512BW then make won't re-build it just because a new flag is specified, the old object file first has to be removed (or source file touched).[/QUOTE]


Sorry for the delay. Tried that, still isn't working. (also realized that the CPU in this system isn't actually ice lake, but skylake-x). Tried rebuilding after the clean with [CODE]make SKYLAKEX=1 NFS=1[/CODE]This didn't work either, and here are the flags being passed to gcc.

[CODE]gcc-8 -g -DUSE_SSE2 -DUSE_BMI2 -DUSE_AVX2 -DUSE_AVX512F -DUSE_AVX512BW -DSKYLAKEX[/CODE]

[QUOTE=Plutie;587250]Sorry for the delay. Tried that, still isn't working. (also realized that the CPU in this system isn't actually ice lake, but skylake-x). Tried rebuilding after the clean with [CODE]make SKYLAKEX=1 NFS=1[/CODE]This didn't work either, and here are the flags being passed to gcc.

[CODE]gcc-8 -g -DUSE_SSE2 -DUSE_BMI2 -DUSE_AVX2 -DUSE_AVX512F -DUSE_AVX512BW -DSKYLAKEX[/CODE][/QUOTE]

It may seem redundant, but after a clean try this:

make SKYLAKEX=1 USE_AVX2=1 USE_BMI2=1 NFS=1

That is the build line I use all the time; if it doesn't work you can post or PM me the errors. I am working to make builds easier, thanks for your patience.

That worked, thank you!

[QUOTE=bsquared;587090]I think CUDA_ERROR_FILE_NOT_FOUND refers to the stage1_core_sm**.ptx file; it is supposed to be next to the executable. The sort_engine.dll file should be in a directory called cub beneath the executable.[/QUOTE]

See [url]https://mersenneforum.org/showpost.php?p=587018&postcount=50[/url] for details of what I found out about the latest msieve version.

Pure AVX2 build is broken:

make yafu COMPILER=gcc USE_AVX2=1 USE_BMI2=1

(NFS is intentionally disabled)

Linking fails with bunch of references to AVX-512 code.

[code]
./libyecm.a(avx_ecm_main.o): In function `vec_ecm_main':
/home/stream/work/yafu/yafu/factor/avx-ecm/avx_ecm_main.c:585: undefined reference to `vecmulmod52_fixed832_bfips'
/home/stream/work/yafu/yafu/factor/avx-ecm/avx_ecm_main.c:586: undefined reference to `vecsqrmod52_fixed832_bfips'
/home/stream/work/yafu/yafu/factor/avx-ecm/avx_ecm_main.c:587: undefined reference to `vec_simul_addsub52_fixed1040'
/home/stream/work/yafu/yafu/factor/avx-ecm/avx_ecm_main.c:578: undefined reference to `vecmulmod52_fixed624_bfips'
/home/stream/work/yafu/yafu/factor/avx-ecm/avx_ecm_main.c:579: undefined reference to `vecsqrmod52_fixed624_bfips'
/home/stream/work/yafu/yafu/factor/avx-ecm/avx_ecm_main.c:580: undefined reference to `vec_simul_addsub52_fixed1040'
/home/stream/work/yafu/yafu/factor/avx-ecm/avx_ecm_main.c:571: undefined reference to `vecmulmod52_fixed416_bfips'
/home/stream/work/yafu/yafu/factor/avx-ecm/avx_ecm_main.c:572: undefined reference to `vecsqrmod52_fixed416_bfips'
/home/stream/work/yafu/yafu/factor/avx-ecm/avx_ecm_main.c:573: undefined reference to `vec_simul_addsub52_fixed1040'
/home/stream/work/yafu/yafu/factor/avx-ecm/avx_ecm_main.c:592: undefined reference to `vecmulmod52_fixed1040_bfips'
/home/stream/work/yafu/yafu/factor/avx-ecm/avx_ecm_main.c:593: undefined reference to `vecsqrmod52_fixed1040_bfips'
/home/stream/work/yafu/yafu/factor/avx-ecm/avx_ecm_main.c:594: undefined reference to `vec_simul_addsub52_fixed1040'
[/code]

Revision 536 will compile but something must have changed in Revision 537 to break the code?

I'm back home now and able to test v2.06 on my Win10/i8-8100 machine.
It works, but I've noticed a couple things (which entirely could be me doing something wrong).

1) ECM runs as a single thread of yafu-x64.exe
I don't care if ECM runs within yafu or spawns external ecm.exe as long as it uses the appropriate number of threads.
Relevant yafu.ini entries:
[c]threads=4[/c]
[c]ecm_path=c:\users\user\desktop\yafu2\ecm\ecm.exe[/c]
If I specify an [i]invalid[/i] path for ecm.exe then it appropriately tells me "ecm: ECM executable does not exist at c:\invalid\path\ecm.exe" and "using internal single threaded ECM...", but even when the path to ecm.exe is valid it appears to be using the internal, single-threaded ECM (with no warning).

2) Number of witnesses for PRP is always "1" no even if I set something like [c]nprp=20[/c] in yafu.ini

3) Increased verbosity doesn't seem to work (at least in yafu.ini). The description says "Note that more v's increase the verbosity" but if I specify [c]v v[/c] it tells me "invalid option v v" and spews the list of valid options and exits

[QUOTE=stream;587689]Pure AVX2 build is broken:

make yafu COMPILER=gcc USE_AVX2=1 USE_BMI2=1

(NFS is intentionally disabled)

Linking fails with bunch of references to AVX-512 code.

[code]
./libyecm.a(avx_ecm_main.o): In function `vec_ecm_main':
/home/stream/work/yafu/yafu/factor/avx-ecm/avx_ecm_main.c:585: undefined reference to `vecmulmod52_fixed832_bfips'
/home/stream/work/yafu/yafu/factor/avx-ecm/avx_ecm_main.c:586: undefined reference to `vecsqrmod52_fixed832_bfips'
/home/stream/work/yafu/yafu/factor/avx-ecm/avx_ecm_main.c:587: undefined reference to `vec_simul_addsub52_fixed1040'
/home/stream/work/yafu/yafu/factor/avx-ecm/avx_ecm_main.c:578: undefined reference to `vecmulmod52_fixed624_bfips'
/home/stream/work/yafu/yafu/factor/avx-ecm/avx_ecm_main.c:579: undefined reference to `vecsqrmod52_fixed624_bfips'
/home/stream/work/yafu/yafu/factor/avx-ecm/avx_ecm_main.c:580: undefined reference to `vec_simul_addsub52_fixed1040'
/home/stream/work/yafu/yafu/factor/avx-ecm/avx_ecm_main.c:571: undefined reference to `vecmulmod52_fixed416_bfips'
/home/stream/work/yafu/yafu/factor/avx-ecm/avx_ecm_main.c:572: undefined reference to `vecsqrmod52_fixed416_bfips'
/home/stream/work/yafu/yafu/factor/avx-ecm/avx_ecm_main.c:573: undefined reference to `vec_simul_addsub52_fixed1040'
/home/stream/work/yafu/yafu/factor/avx-ecm/avx_ecm_main.c:592: undefined reference to `vecmulmod52_fixed1040_bfips'
/home/stream/work/yafu/yafu/factor/avx-ecm/avx_ecm_main.c:593: undefined reference to `vecsqrmod52_fixed1040_bfips'
/home/stream/work/yafu/yafu/factor/avx-ecm/avx_ecm_main.c:594: undefined reference to `vec_simul_addsub52_fixed1040'
[/code][/QUOTE]

Thanks, it's fixed now.

Those new function make avx-ecm about 10% faster below 1040 bits, but I had forgotten to add stubs for non-avx-512 builds.

[QUOTE=James Heinrich;587752]I'm back home now and able to test v2.06 on my Win10/i8-8100 machine.
It works, but I've noticed a couple things (which entirely could be me doing something wrong).

1) ECM runs as a single thread of yafu-x64.exe
I don't care if ECM runs within yafu or spawns external ecm.exe as long as it uses the appropriate number of threads.
Relevant yafu.ini entries:
[c]threads=4[/c]
[c]ecm_path=c:\users\user\desktop\yafu2\ecm\ecm.exe[/c]
If I specify an [i]invalid[/i] path for ecm.exe then it appropriately tells me "ecm: ECM executable does not exist at c:\invalid\path\ecm.exe" and "using internal single threaded ECM...", but even when the path to ecm.exe is valid it appears to be using the internal, single-threaded ECM (with no warning).
[/QUOTE]

This is something I can fix, but in the meantime use -ext_ecm X on the command line or .ini file, where X is the B1 crossover point to start using external ecm (something like 50000 works well).

[SIZE="1"]The problem is that this value is set really big when avx-ecm is available during compilation. I need to add a check that it is also available at runtime...[/SIZE]


[QUOTE=James Heinrich;587752]
2) Number of witnesses for PRP is always "1" no even if I set something like [c]nprp=20[/c] in yafu.ini
[/QUOTE]

I will fix this. However for most factoring jobs aprcl is used instead of gmp's prp function and aprcl doesn't use or need the witnesses option.

[QUOTE=James Heinrich;587752]
3) Increased verbosity doesn't seem to work (at least in yafu.ini). The description says "Note that more v's increase the verbosity" but if I specify [c]v v[/c] it tells me "invalid option v v" and spews the list of valid options and exits[/QUOTE]

Put the v's on separate lines in the .ini file. Each line is interpreted as one option.

[QUOTE=bsquared;587763]The problem is that this value is set really big when avx-ecm is available during compilation. I need to add a check that it is also available at runtime...[/QUOTE]I was able to use your suggested config setting to spawn the external ecm.exe, but I'm not certain how it's supposed to work with the internal ECM -- is that not multithreaded? Is there something I'm missing to be able to use the built-in ECM but make use of available threads?

[QUOTE=bsquared;587763]Put the v's on separate lines in the .ini file. Each line is interpreted as one option.[/QUOTE]This wasn't obvious to me, perhaps an amendment to the .ini file to make that clearer would help.

On my installations, I always use [C]prefer_gmpecm[/C] and this works as intended, also with 2.06.

[QUOTE=James Heinrich;587772]I was able to use your suggested config setting to spawn the external ecm.exe, but I'm not certain how it's supposed to work with the internal ECM -- is that not multithreaded? Is there something I'm missing to be able to use the built-in ECM but make use of available threads?

This wasn't obvious to me, perhaps an amendment to the .ini file to make that clearer would help.[/QUOTE]

Before ecm version 7 only single threads were allowed, so yafu does a check on the ecm version linked in during compile. I'm pretty sure I'm linking with version 7.0.4 in the executable I provide but it's possible there is a bug in detecting that version. I'll look it over.

Yes I'll add some text to the .ini file description.

[QUOTE=kruoli;587775]On my installations, I always use [C]prefer_gmpecm[/C] and this works as intended, also with 2.06.[/QUOTE]

That should only matter if you have AVX-512, in which case yafu will default to using AVX-ECM.

edit: I saw this was reported earlier and should be fixed?

I pulled the newest version and did a [C]make clean[/C] and [C]make NFS=1 USE_SSE41=1 USE_AVX2=1[/C] and building quits with the following error:

[QUOTE]/usr/bin/ld: ./libyecm.a(avx_ecm_main.o): in function `vec_ecm_main':
/home/florian/Math/yafu/factor/avx-ecm/avx_ecm_main.c:592: undefined reference to `vecmulmod52_fixed1040_bfips'
/usr/bin/ld: /home/florian/Math/yafu/factor/avx-ecm/avx_ecm_main.c:593: undefined reference to `vecsqrmod52_fixed1040_bfips'
/usr/bin/ld: /home/florian/Math/yafu/factor/avx-ecm/avx_ecm_main.c:594: undefined reference to `vec_simul_addsub52_fixed1040'
[... lots of similar lines][/QUOTE]

I also tried your previous suggestion to use the [C]USE_BMI2=1[/C] flag. And I used the flags during [C]make clean[/C].

Do you know why I still run into the problem?

[QUOTE=bur;587804]

Do you know why I still run into the problem?[/QUOTE]

Because for some reason my push/commit didn't take... I'm still learning this whole git thing... :redface: I'll try again tonight.

I wouldn't have noticed this except for some error checking in my automated parsing of factor.log[code]09/13/21 08:12:06, ****************************
09/13/21 08:12:06, Starting factorization of 11745986472276496655662247734956521108703066873589956247227553585499089637967910706104797828678082669016193648910144450016469882935490998359642649527365479
09/13/21 08:12:06, using pretesting plan: deep
09/13/21 08:12:06, using specified qs/gnfs crossover of 100 digits
09/13/21 08:12:06, using specified qs/snfs crossover of 75 digits
09/13/21 08:12:06, ****************************
09/13/21 08:12:06, rho: x^2 + 3, starting 1000 iterations on C155
09/13/21 08:12:06, prp5 = 91291
09/13/21 08:12:06, rho: x^2 + 3, starting 1000 iterations on C150
09/13/21 08:12:06, prp7 = 7805879
09/13/21 08:12:06, rho: x^2 + 3, starting 1000 iterations on C143
09/13/21 08:12:06, rho: x^2 + 2, starting 1000 iterations on C143
09/13/21 08:12:07, rho: x^2 + 1, starting 1000 iterations on C143
09/13/21 08:12:07, pm1: starting B1 = 150K, B2 = gmp-ecm default on C143
09/13/21 08:12:07, current ECM pretesting depth: 0.00
09/13/21 08:12:07, scheduled 30 curves at B1=2000 toward target pretesting depth of 47.67
09/13/21 08:12:07, Finished 30 curves using GMP-ECM method on C143 input, B1=2k, B2=gmp-ecm default
09/13/21 08:12:07, current ECM pretesting depth: 15.18
09/13/21 08:12:07, scheduled 74 curves at B1=11000 toward target pretesting depth of 47.67
09/13/21 08:12:10, Finished 74 curves using GMP-ECM method on C143 input, B1=11k, B2=gmp-ecm default
09/13/21 08:12:10, current ECM pretesting depth: 20.24
09/13/21 08:12:10, scheduled 214 curves at B1=50000 toward target pretesting depth of 47.67
09/13/21 08:12:11, prp26 = 23304102950704118347000297 (curve 2 stg2 B1=50000 sigma=3874399757 thread=1)
09/13/21 08:12:11, Finished 4 curves using GMP-ECM method on C143 input, B1=50k, B2=gmp-ecm default
09/13/21 08:12:11, current ECM pretesting depth: 20.34
09/13/21 08:12:11, scheduled 210 curves at B1=50000 toward target pretesting depth of 39.00
09/13/21 08:12:22, Finished 210 curves using GMP-ECM method on C117 input, B1=50k, B2=gmp-ecm default
09/13/21 08:12:22, pm1: starting B1 = 3750K, B2 = gmp-ecm default on C117
09/13/21 08:12:23, current ECM pretesting depth: 25.33
09/13/21 08:12:23, scheduled 430 curves at B1=250000 toward target pretesting depth of 39.00
09/13/21 08:13:47, Finished 430 curves using GMP-ECM method on C117 input, B1=250k, B2=gmp-ecm default
09/13/21 08:13:47, pm1: starting B1 = 15M, B2 = gmp-ecm default on C117
09/13/21 08:13:50, current ECM pretesting depth: 30.45
09/13/21 08:13:50, scheduled 904 curves at B1=1000000 toward target pretesting depth of 39.00
09/13/21 08:25:10, Finished 904 curves using GMP-ECM method on C117 input, B1=1M, B2=gmp-ecm default
09/13/21 08:25:10, current ECM pretesting depth: 35.56
09/13/21 08:25:10, scheduled 1619 curves at B1=3000000 toward target pretesting depth of 39.00
09/13/21 08:31:42, prp35 = 10458847902056956740364765053965417 (curve 195 stg2 B1=3000000 sigma=2620919999 thread=0)
09/13/21 08:31:49, Finished 197 curves using GMP-ECM method on C117 input, B1=3M, B2=gmp-ecm default
09/13/21 08:31:49, final ECM pretested depth: 35.98
09/13/21 08:31:49, prp84 cofactor = 67627522805179106773859180025103681923504306209525858835440580638970766947677849939
09/13/21 08:31:49, Total factoring time = 1183.1567 seconds[/code]Note the second-last line:
[c]prp84 cofactor = 67627522805179106773859180025103681923504306209525858835440580638970766947677849939[/c]
That number is only 8[b]3[/b] characters long, but claims to be a prp8[b]4[/b].

For comparison, this is what it shows on v1.34.5:[code]09/13/21 20:25:23 v1.34.5 @ 3930K, ****************************
09/13/21 20:25:23 v1.34.5 @ 3930K, Starting factorization of 11745986472276496655662247734956521108703066873589956247227553585499089637967910706104797828678082669016193648910144450016469882935490998359642649527365479
09/13/21 20:25:23 v1.34.5 @ 3930K, using pretesting plan: deep
09/13/21 20:25:23 v1.34.5 @ 3930K, using tune info for qs/gnfs crossover
09/13/21 20:25:23 v1.34.5 @ 3930K, ****************************
09/13/21 20:25:23 v1.34.5 @ 3930K, rho: x^2 + 3, starting 1000 iterations on C155
09/13/21 20:25:23 v1.34.5 @ 3930K, rho: x^2 + 2, starting 1000 iterations on C155
09/13/21 20:25:23 v1.34.5 @ 3930K, prp5 = 91291
09/13/21 20:25:23 v1.34.5 @ 3930K, rho: x^2 + 2, starting 1000 iterations on C150
09/13/21 20:25:23 v1.34.5 @ 3930K, prp7 = 7805879
09/13/21 20:25:23 v1.34.5 @ 3930K, rho: x^2 + 2, starting 1000 iterations on C143
09/13/21 20:25:23 v1.34.5 @ 3930K, rho: x^2 + 1, starting 1000 iterations on C143
09/13/21 20:25:23 v1.34.5 @ 3930K, pm1: starting B1 = 150K, B2 = gmp-ecm default on C143
09/13/21 20:25:23 v1.34.5 @ 3930K, current ECM pretesting depth: 0.00
09/13/21 20:25:23 v1.34.5 @ 3930K, scheduled 30 curves at B1=2000 toward target pretesting depth of 47.67
09/13/21 20:25:23 v1.34.5 @ 3930K, Finished 30 curves using Lenstra ECM method on C143 input, B1=2K, B2=gmp-ecm default
09/13/21 20:25:23 v1.34.5 @ 3930K, current ECM pretesting depth: 15.18
09/13/21 20:25:23 v1.34.5 @ 3930K, scheduled 74 curves at B1=11000 toward target pretesting depth of 47.67
09/13/21 20:25:27 v1.34.5 @ 3930K, Finished 74 curves using Lenstra ECM method on C143 input, B1=11K, B2=gmp-ecm default
09/13/21 20:25:27 v1.34.5 @ 3930K, current ECM pretesting depth: 20.24
09/13/21 20:25:27 v1.34.5 @ 3930K, scheduled 214 curves at B1=50000 toward target pretesting depth of 47.67
09/13/21 20:25:35 v1.34.5 @ 3930K, prp26 = 23304102950704118347000297 (curve 22 stg2 B1=50000 sigma=3377483298 thread=2)
09/13/21 20:25:35 v1.34.5 @ 3930K, Finished 132 curves using Lenstra ECM method on C143 input, B1=50K, B2=gmp-ecm default
09/13/21 20:25:35 v1.34.5 @ 3930K, current ECM pretesting depth: 23.33
09/13/21 20:25:35 v1.34.5 @ 3930K, scheduled 82 curves at B1=50000 toward target pretesting depth of 39.00
09/13/21 20:25:39 v1.34.5 @ 3930K, Finished 84 curves using Lenstra ECM method on C117 input, B1=50K, B2=gmp-ecm default
09/13/21 20:25:39 v1.34.5 @ 3930K, pm1: starting B1 = 3750K, B2 = gmp-ecm default on C117
09/13/21 20:25:41 v1.34.5 @ 3930K, current ECM pretesting depth: 25.34
09/13/21 20:25:41 v1.34.5 @ 3930K, scheduled 430 curves at B1=250000 toward target pretesting depth of 39.00
09/13/21 20:27:04 v1.34.5 @ 3930K, Finished 432 curves using Lenstra ECM method on C117 input, B1=250K, B2=gmp-ecm default
09/13/21 20:27:04 v1.34.5 @ 3930K, pm1: starting B1 = 15M, B2 = gmp-ecm default on C117
09/13/21 20:27:10 v1.34.5 @ 3930K, current ECM pretesting depth: 30.46
09/13/21 20:27:10 v1.34.5 @ 3930K, scheduled 904 curves at B1=1000000 toward target pretesting depth of 39.00
09/13/21 20:30:19 v1.34.5 @ 3930K, prp35 = 10458847902056956740364765053965417 (curve 40 stg2 B1=1000000 sigma=886406094 thread=1)
09/13/21 20:30:19 v1.34.5 @ 3930K, Finished 240 curves using Lenstra ECM method on C117 input, B1=1M, B2=gmp-ecm default
09/13/21 20:30:19 v1.34.5 @ 3930K, final ECM pretested depth: 31.78
09/13/21 20:30:19 v1.34.5 @ 3930K, scheduler: switching to sieve method
09/13/21 20:30:19 v1.34.5 @ 3930K, prp83 = 67627522805179106773859180025103681923504306209525858835440580638970766947677849939
09/13/21 20:30:19 v1.34.5 @ 3930K, Total factoring time = 296.4042 seconds[/code]

[QUOTE]Because for some reason my push/commit didn't take...[/QUOTE]Thanks!

2.07 now available
 

[QUOTE=James Heinrich;587832]I wouldn't have noticed this except for some error checking in my automated parsing of factor.log

Note the second-last line:
[c]prp84 cofactor = 67627522805179106773859180025103681923504306209525858835440580638970766947677849939[/c]
That number is only 8[b]3[/b] characters long, but claims to be a prp8[b]4[/b].
[/QUOTE]

This should be fixed now, as well as the previous problem building on avx2.

I verified the latest commits made it to github, we are now at 2.07.

In this version I've committed changes to the MSVC project files and linux makefile that revert back to the "normal" directory structure of yafu and its dependencies (no more ".git" or "trunk" in the relative paths of libraries). And removed some confusing stuff in the makefile. Hopefully working toward something that is easier to build.

Two other things of note:
1) I was made aware that aprcl wasn't running on factors found, this is now fixed and factors displayed to screen should now be "P" instead of "PRP"
2) AVX-ECM below 1040 bits is about 10% faster.

Regarding the "P" vs. "PRP" labeling... the .log file still generally gets "prp" printed. Which could be fixed, but before I do that I wanted to see if that would break anyone's scripting/parsing?

[QUOTE=bsquared;587887]Regarding the "P" vs. "PRP" labeling... the .log file still generally gets "prp" printed. Which could be fixed, but before I do that I wanted to see if that would break anyone's scripting/parsing?[/QUOTE]It wouldn't break anything I do, my regex already looks like [c]^(prp|p)([0-9]+)( cofactor)? = ([0-9]+)[/c]

We already have to handle the different format for small factors: [c]div: found prime factor = 3[/c]
Possibly this could be changed to standardize it such that all factors follow the format [c](p|prp|c)<len> = <factor>[/c]

YAFU2 doesn't like my tune info
 

Session:[code]YAFU Version 2.07
Built with GCC 9
Using GMP-ECM 7.0.5-dev, Powered by GMP 6.2.0
Detected Intel(R) Xeon(R) CPU E5-2620 v2 @ 2.10GHz
Detected L1 = 32768 bytes, L2 = 15728640 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(1802716097522165018257858828415111497060066282677325501816640492782221110851604465066510547671104729)
fac: [B]check tune params contained invalid parameter(s), ignoring tune info.[/B]
fac: factoring 1802716097522165018257858828415111497060066282677325501816640492782221110851604465066510547671104729
fac: using pretesting plan: normal
fac: [B]check tune params contained invalid parameter(s), ignoring tune info.[/B][/code]yafu.ini tune info:[code]%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
% Tune options
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
% If you run tune(), some information about the results should
% appear below here


tune_info=Intel(R) Xeon(R) Gold 5122 CPU @ 3.60GHz,LINUX64,1.59078e-05,0.196092,0.299688,0.0999245,102.36,42
tune_info= Intel(R) Xeon(R) CPU E5-2620 v2 @ 2.10GHz,LINUX64,2.98318e-05,0.19418,0.381544,0.1013,101.813,42[/code]I've tried removing the prior info and I've tried removing the whitespace after the "tune_info=" and neither worked.

Thanks for all.

[QUOTE=EdH;587942][code]%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
% Tune options
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
% If you run tune(), some information about the results should
% appear below here


tune_info=Intel(R) Xeon(R) Gold 5122 CPU @ 3.60GHz,LINUX64,1.59078e-05,0.196092,0.299688,0.0999245,102.36,42
tune_info= Intel(R) Xeon(R) CPU E5-2620 v2 @ 2.10GHz,LINUX64,2.98318e-05,0.19418,0.381544,0.1013,101.813,42[/code]I've tried removing the prior info and I've tried removing the whitespace after the "tune_info=" and neither worked.

Thanks for all.[/QUOTE]

Try removing the space *before* your tune_info line :) It is apparently picky about leading spaces.

[QUOTE=bsquared;587945]Try removing the space *before* your tune_info line :) It is apparently picky about leading spaces.[/QUOTE]That space isn't actually there! It's an artifact that the board keeps throwing into "code" blocks! I'm always having to edit the &^%^$ things and I missed that one. This is the current block:[code]% appear below here


tune_info=Intel(R) Xeon(R) Gold 5122 CPU @ 3.60GHz,LINUX64,1.59078e-05,0.196092,0.299688,0.0999245,102.36,42
tune_info= Intel(R) Xeon(R) CPU E5-2620 v2 @ 2.10GHz,LINUX64,3.08421e-05,0.193843,0.505431,0.0983408,101.613,42[/code]Sorry for the bad data.*

2.03 doesn't proclaim bad tune data, but I can't tell if it's actually using any. I get the same output without current tune data:[code]YAFU Version 2.03
Built with GCC 9
Using GMP-ECM 7.0.5-dev, Powered by GMP 6.2.1
Detected Intel(R) Xeon(R) CPU X5650 @ 2.67GHz
Detected L1 = 32768 bytes, L2 = 12582912 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(1802716097522165018257858828415111497060066282677325501816640492782221110851604465066510547671104729)
fac: factoring 1802716097522165018257858828415111497060066282677325501816640492782221110851604465066510547671104729
fac: using pretesting plan: normal
fac: using specified qs/gnfs crossover of 100 digits
fac: using specified qs/snfs crossover of 75 digits

starting SIQS on c100: 1802716097522165018257858828415111497060066282677325501816640492782221110851604465066510547671104729[/code] [code]% appear below here


tune_info=Intel(R) Xeon(R) Gold 5122 CPU @ 3.60GHz,LINUX64,1.59078e-05,0.196092,0.299688,0.0999245,102.36,42
tune_info=Intel(R) Xeon(R) CPU X5650 @ 2.67GHz,LINUX64,2.52186e-05,0.196652,0.440998,0.0992702,100.318,42[/code]I'll try updating that machine and I'll try building 2.07 on another very similar Xeon. (It might not be until tomorrow.)

* OF NOTE: The above block also added two characters, that I had to remove. I'm not seeing any extra characters in my gedit sessions. I've been experiencing this extraneous "junk" for a long time in all my code blocks. I don't think it's originating with me. I believe others have experienced the double returns and added characters in their code blocks, as well. But, I am open to all comments.

[QUOTE=EdH;587947]I've been experiencing this extraneous "junk" for a long time in all my code blocks.[/QUOTE]Probable artifact of CRLF in an otherwise unix-style (LF-only) file? Does YAFU make any attempt to check whether new "tune" lines are being inserted into windows or unix style ini files, or does it always use one style (which?)

[QUOTE=James Heinrich;587948]Probable artifact of CRLF in an otherwise unix-style (LF-only) file? Does YAFU make any attempt to check whether new "tune" lines are being inserted into windows or unix style ini files, or does it always use one style (which?)[/QUOTE]I don't think the extraneous characters are anything to do with YAFU. They happen to me when I edit my posts to the board for all my scripts, too.

To be clear the yafu.ini file has no noticeable extra spaces or additional line termination as displayed by gedit and no extra spaces show up for my initial copy/paste to a message block. They only appear after I make a change somewhere in the post and review it. I can copy/paste a block of text and it shows up correctly, then preview and edit something and the extra character(s) show(s) up. I don't think it is my copy/paste because the artifacts don't show up immediately, only after editing within the board's window. But, I'm open to any thoughts.

Example test:
[code]
line one.
line two.
line three.
line four.
[/code][code]
line one edited.
line two edited.
line three edited.
line four edited.
[/code]I typed the above two blocks directly into this message and both looked like the first one. Then I typed in the first edited and copy/pasted the other three. Now it has extra "junk."

Thanks for all suggestions.

I had missed something earlier. The very first line I get is:[code]Applying tune_info entry for LINUX64 - Intel(R) Xeon(R) CPU E5-2630 0 @ 2.30GHz[/code]Then it shows the following messages. This is a second nearly identical machine to the previous one:[code]$ ./yafu
Applying tune_info entry for LINUX64 - Intel(R) Xeon(R) CPU E5-2630 0 @ 2.30GHz


YAFU Version 2.07
Built with GCC 9
Using GMP-ECM 7.0.5-dev, Powered by GMP 6.2.1
Detected Intel(R) Xeon(R) CPU E5-2630 0 @ 2.30GHz
Detected L1 = 32768 bytes, L2 = 15728640 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(3895019629310942791127924868760001374161564829081811090059087663376519150666208901154051)
fac: check tune params contained invalid parameter(s), ignoring tune info.
fac: factoring 3895019629310942791127924868760001374161564829081811090059087663376519150666208901154051[/code]Here are the last few lines of the tune operation:[code]nfs: estimated time for complete factorization = 31033.7059 seconds
best linear fit is ln(y) = 0.101147 * x + -0.891959
R^2 = 0.967072
best exponential fit is y = 0.409852 * exp(0.101147 * x)
QS/NFS crossover occurs at 100.3 digits
found OS = LINUX64 and CPU = Intel(R) Xeon(R) Gold 5122 CPU @ 3.60GHz in tune_info field
Adding tune_info entry for LINUX64 - Intel(R) Xeon(R) CPU E5-2630 0 @ 2.30GHz


***factors found***


ans = 0[/code]and the last few of the new yafu.ini:[code]%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
% Tune options
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
% If you run tune(), some information about the results should
% appear below here


tune_info=Intel(R) Xeon(R) Gold 5122 CPU @ 3.60GHz,LINUX64,1.59078e-05,0.196092,0.299688,0.0999245,102.36,42
tune_info= Intel(R) Xeon(R) CPU E5-2630 0 @ 2.30GHz,LINUX64,2.60097e-05,0.197536,0.409852,0.101147,100.272,42[/code]No editing has been done to the yafu.ini file after running tune. The only editing prior, was threads and paths for ggnfs and ECM.

This entire message was constructed via gedit without editing anything via the board's tools.

If you think it's relevant, you might use the attachment feature of the forum to attach your .ini file to avoid any copy-paste-edit garbling.

[QUOTE=James Heinrich;587969]If you think it's relevant, you might use the attachment feature of the forum to attach your .ini file to avoid any copy-paste-edit garbling.[/QUOTE]A good suggestion! I'll wait a bit to see what b[SUP]2[/SUP] may come up with and while I upgrade a couple more diverse machines. I'm upgrading another Xeon ATM. Then I'll try an i7.

Well, no luck with these, either. Here's an i7 right after running tune:[code]$ ./yafu
Applying tune_info entry for LINUX64 - Intel(R) Core(TM) i7-2600 CPU @ 3.40GHz


YAFU Version 2.07
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

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

>> factor(1006937478603500243574011966177501282832467119633045794739218202437560443941866695322821)
fac: check tune params contained invalid parameter(s), ignoring tune info.
fac: factoring 1006937478603500243574011966177501282832467119633045794739218202437560443941866695322821
fac: using pretesting plan: normal
fac: check tune params contained invalid parameter(s), ignoring tune info.[/code]i7's yafu.ini tune info:[code]% appear below here


tune_info=Intel(R) Xeon(R) Gold 5122 CPU @ 3.60GHz,LINUX64,1.59078e-05,0.196092,0.299688,0.0999245,102.36,42
tune_info= Intel(R) Core(TM) i7-2600 CPU @ 3.40GHz,LINUX64,1.77913e-05,0.197298,0.28037,0.100998,100.365,42[/code]Here's an AMD machine:[code]$ ./yafu
Applying tune_info entry for LINUX64 - AMD Phenom(tm) II X4 B95 Processor


YAFU Version 2.07
Built with GCC 9
Using GMP-ECM 7.0.5-dev, Powered by GMP 6.2.0
Detected AMD Phenom(tm) II X4 B95 Processor
Detected L1 = 65536 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 =======
===============================================================

>> factor(8115344633731779104344693675156365299077770243773155282218623609391019030239893061930191)
fac: check tune params contained invalid parameter(s), ignoring tune info.[/code]and its tune info:[code]% appear below here


tune_info=Intel(R) Xeon(R) Gold 5122 CPU @ 3.60GHz,LINUX64,1.59078e-05,0.196092,0.299688,0.0999245,102.36,42
tune_info=AMD Phenom(tm) II X4 B95 Processor,LINUX64,1.5946e-05,0.202008,0.525842,0.0965283,98.6309,42[/code]All of the previous machines were running Ubuntu 20.04.

Here's a Debian (Buster) machine:[code]$ ./yafu
Applying tune_info entry for LINUX64 - Intel(R) Core(TM)2 Quad CPU Q8400 @ 2.66GHz


YAFU Version 2.07
Built with GCC 8
Using GMP-ECM 7.0.5-dev, Powered by GMP 6.2.0
Detected Intel(R) Core(TM)2 Quad CPU Q8400 @ 2.66GHz
Detected L1 = 32768 bytes, L2 = 2097152 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(2239620260486900894908265519196420231768486265882316440459029916618515194783127449405749)
fac: check tune params contained invalid parameter(s), ignoring tune info.[/code]and its tune info:[code]% appear below here


tune_info=Intel(R) Xeon(R) Gold 5122 CPU @ 3.60GHz,LINUX64,1.59078e-05,0.196092,0.299688,0.0999245,102.36,42
tune_info=Intel(R) Core(TM)2 Quad CPU Q8400 @ 2.66GHz,LINUX64,2.51073e-05,0.198206,0.473332,0.100239,100.487,42[/code]Maybe it's me. . .

Thanks for all the help/suggestions.

Just an additional note that the other Xeon acted the same. I forgot to include it in the last post.

I'll admit I'm posting this while looking at v1.34.5 and not v2.07, but is it possible to add in some kind of rough ETA to SIQS, which currently displays something like:[quote]==== sieving in progress ( 6 threads): 144224 relations needed ====
==== Press ctrl-c to abort and save state ====
41708 rels found: 20823 full + 20885 from 1252184 partial, (622.51 rels/sec)[/quote]

[QUOTE=EdH;587986]Just an additional note that the other Xeon acted the same. I forgot to include it in the last post.[/QUOTE]

Try the most-recent commit (just now). It is working for me...

[QUOTE=James Heinrich;587987]I'll admit I'm posting this while looking at v1.34.5 and not v2.07, but is it possible to add in some kind of rough ETA to SIQS, which currently displays something like:[/QUOTE]

Not trivial, given the ability to restart jobs and the non-linear growth of relation-sets in DLP/3LP variations.

Very roughly, when the number of fulls from partials is equal to the number of fulls then you are about 2/3 to 3/4 done.

[QUOTE=bsquared;587991]Not trivial... then you are about 2/3 to 3/4 done.[/QUOTE]I figured it's hard to get a precise number. But just wondering if something "very approximate" could be contrived, something like "about 3-6 hours left" or something like that?

[QUOTE=bsquared;587989]Try the most-recent commit (just now). It is working for me...[/QUOTE]Probably due to my CPUs missing (almost) all the valuable flags, I got an error after "make clean NFS=clean USE_SSE41=clean":[code]$ make NFS=1 USE_SSE41=1
. . .
factor/avx-ecm/avx_ecm.h:836:34: error: unknown type name \u2018__m512i\u2019
836 | void vecmul52_1(vec_bignum_t* a, __m512i b, vec_bignum_t* c, vec_bignum_t* n, vec_bignum_t* s, vec_monty_t* mdata);
| ^~~~~~~
. . .
make: *** [Makefile:393: factor/avx-ecm/avxecm.o] Error 1[/code]I also tried without the sse4_1 option and received the same error message.


On a different subject, I'm trying to figure out how to send options in the following script line:[code]echo "factor(${composite})" | ./yafu[/code]I've tried adding -one and -silent before and after the pipe (at the ends of each command) and inside and outside the quotes, with and without another set of enclosing quotes. Can these be added to the script line, or can I place them in yafu.ini in some manner? I'm using separate copies of yafu and yafu.ini within the working directory where the script is located, so I'm free to modify yafu.ini to be specific. Alternately for -silent, is there a less verbose mode?

Sorry if I'm a pain. Thanks for all the help.

[QUOTE=James Heinrich;587752]1) ECM runs as a single thread of yafu-x64.exe[/quote]Just confirming that internal ECM now uses the appropriate number of threads in v2.07 (Win10), thanks.

I did notice something when checking that -- I'm specifying [c]-p[/c] on the commandline but yafu-x64.exe is running in "normal" priority, not idle ([c]p[/c] is also set in yafu.ini).

Revision 2.07 appears to be stuck in a loop:[code]. . .
starting SIQS on c88: 1072980570200329351188730228988024470047893288038112575153917530948170108341537641314357
70449 relations found: 20728 full + 49721 from 872363 partial
threw away 0 relations with large primes too small

==== sieve params ====
n = 88 digits, 290 bits
factor base: 66560 primes (max prime = 1773997)
single large prime cutoff: 195139670 (110 * pmax)
double large prime range from 3147065356009 to 2173398172298490
DLP MFB = 1.85
using SSE41 enabled 32k sieve core
sieve interval: 12 blocks of size 32768
polynomial A has ~ 11 factors
using multiplier of 1 (kn mod 8 == 5)
using SPV correction of 20 bits, starting at offset 35
trial factoring cutoff at 93 bits

==== sieving in progress ( 24 threads): 66624 relations needed ====
==== Press ctrl-c to abort and save state ====
70449 rels found: 20728 full + 49721 from 872363 partial, (1592093.11 rels/sec)

sieving required 0 total polynomials (4294967295 'A' polynomials)
trial division touched 0 sieve locations out of 0
dlp-ecm: 0 failures, 0 attempts, 0 outside range, 0 prp, 0 useful
total reports = 0, total surviving reports = 0
total blocks sieved = 0, avg surviving reports per block = -nan
Elapsed time: 0.5610 sec
QS elapsed time = 0.5611 seconds.

==== post processing stage (msieve-1.38) ====
read 893090 relations
begin singleton removal with 893090 relations
reduce to 162769 relations in 9 passes
attempting to read and process 162769 relations
recovered 162769 relations
recovered 129773 polynomials
attempting to build 70448 cycles
found 70448 cycles from 162769 relations in 5 passes
distribution of cycle lengths:
length 1 : 20728
length 2 : 15380
length 3 : 12812
length 4 : 8869
length 5 : 5644
length 6 : 3303
length 7 : 1814
length 9+: 1898
largest cycle: 18 relations
matrix is 66560 x 70448 (16.6 MB) with weight 3794245 (53.86/col)
sparse part has weight 3794245 (53.86/col)
filtering completed in 4 passes
matrix is 59263 x 59327 (13.3 MB) with weight 3021409 (50.93/col)
sparse part has weight 3021409 (50.93/col)
saving the first 48 matrix rows for later
matrix is 59215 x 59327 (11.6 MB) with weight 2672491 (45.05/col)
sparse part has weight 2454774 (41.38/col)
matrix includes 64 packed rows
using block size 23730 for processor cache size 15360 kB
commencing Lanczos iteration
memory use: 9.5 MB
lanczos halted after 938 iterations (dim = 59210)
recovered 14 nontrivial dependencies
Lanczos elapsed time = 14.3076 seconds.
Sqrt elapsed time = 1.3032 seconds.
SIQS elapsed time = 16.1745 seconds.
pretesting / qs ratio was 0.90
fac: check tune params contained invalid parameter(s), ignoring tune info.
fac: setting target pretesting digits to 27.08
t15: 67.74
t20: 29.98
t25: 4.05
t30: 0.42
t35: 0.03
fac: estimated sum of completed work is t27.08

starting SIQS on c88: 1072980570200329351188730228988024470047893288038112575153917530948170108341537641314357
70449 relations found: 20728 full + 49721 from 872363 partial
threw away 0 relations with large primes too small

==== sieve params ====
n = 88 digits, 290 bits
factor base: 66560 primes (max prime = 1773997)
single large prime cutoff: 195139670 (110 * pmax)
double large prime range from 3147065356009 to 2173398172298490
DLP MFB = 1.85
using SSE41 enabled 32k sieve core
sieve interval: 12 blocks of size 32768
polynomial A has ~ 11 factors
using multiplier of 1 (kn mod 8 == 5)
using SPV correction of 20 bits, starting at offset 35
trial factoring cutoff at 93 bits

==== sieving in progress ( 24 threads): 66624 relations needed ====
==== Press ctrl-c to abort and save state ====
70449 rels found: 20728 full + 49721 from 872363 partial, (1348970.02 rels/sec)

sieving required 0 total polynomials (4294967295 'A' polynomials)
trial division touched 0 sieve locations out of 0
dlp-ecm: 0 failures, 0 attempts, 0 outside range, 0 prp, 0 useful
total reports = 0, total surviving reports = 0
total blocks sieved = 0, avg surviving reports per block = -nan
Elapsed time: 0.6621 sec
QS elapsed time = 0.6622 seconds.

==== post processing stage (msieve-1.38) ====
read 893090 relations
begin singleton removal with 893090 relations
reduce to 162769 relations in 9 passes
attempting to read and process 162769 relations
recovered 162769 relations
recovered 129773 polynomials
attempting to build 70448 cycles
found 70448 cycles from 162769 relations in 5 passes
distribution of cycle lengths:
length 1 : 20728
length 2 : 15380
length 3 : 12812
length 4 : 8869
length 5 : 5644
length 6 : 3303
length 7 : 1814
length 9+: 1898
largest cycle: 18 relations
matrix is 66560 x 70448 (16.6 MB) with weight 3794245 (53.86/col)
sparse part has weight 3794245 (53.86/col)
filtering completed in 4 passes
matrix is 59263 x 59327 (13.3 MB) with weight 3021409 (50.93/col)
sparse part has weight 3021409 (50.93/col)
saving the first 48 matrix rows for later
matrix is 59215 x 59327 (11.6 MB) with weight 2672491 (45.05/col)
sparse part has weight 2454774 (41.38/col)
matrix includes 64 packed rows
using block size 23730 for processor cache size 15360 kB
commencing Lanczos iteration
memory use: 9.5 MB
lanczos halted after 938 iterations (dim = 59210)
recovered 14 nontrivial dependencies
Lanczos elapsed time = 13.7053 seconds.
Sqrt elapsed time = 1.0454 seconds.
SIQS elapsed time = 15.4167 seconds.
pretesting / qs ratio was 0.94
fac: check tune params contained invalid parameter(s), ignoring tune info.
fac: setting target pretesting digits to 27.08
t15: 67.74
t20: 29.98
t25: 4.05
t30: 0.42
t35: 0.03
fac: estimated sum of completed work is t27.08

starting SIQS on c88: 1072980570200329351188730228988024470047893288038112575153917530948170108341537641314357
70449 relations found: 20728 full + 49721 from 872363 partial
threw away 0 relations with large primes too small

==== sieve params ====
n = 88 digits, 290 bits
factor base: 66560 primes (max prime = 1773997)
single large prime cutoff: 195139670 (110 * pmax)
double large prime range from 3147065356009 to 2173398172298490
DLP MFB = 1.85
using SSE41 enabled 32k sieve core
sieve interval: 12 blocks of size 32768
polynomial A has ~ 11 factors
using multiplier of 1 (kn mod 8 == 5)
using SPV correction of 20 bits, starting at offset 35
trial factoring cutoff at 93 bits

==== sieving in progress ( 24 threads): 66624 relations needed ====
==== Press ctrl-c to abort and save state ====
70449 rels found: 20728 full + 49721 from 872363 partial, (1616530.37 rels/sec)

sieving required 0 total polynomials (4294967295 'A' polynomials)
trial division touched 0 sieve locations out of 0
dlp-ecm: 0 failures, 0 attempts, 0 outside range, 0 prp, 0 useful
total reports = 0, total surviving reports = 0
total blocks sieved = 0, avg surviving reports per block = -nan
Elapsed time: 0.5525 sec
QS elapsed time = 0.5526 seconds.

==== post processing stage (msieve-1.38) ====
read 893090 relations
begin singleton removal with 893090 relations
reduce to 162769 relations in 9 passes
attempting to read and process 162769 relations
recovered 162769 relations
recovered 129773 polynomials
attempting to build 70448 cycles
found 70448 cycles from 162769 relations in 5 passes
distribution of cycle lengths:
length 1 : 20728
length 2 : 15380
length 3 : 12812
length 4 : 8869
length 5 : 5644
length 6 : 3303
length 7 : 1814
length 9+: 1898
largest cycle: 18 relations
matrix is 66560 x 70448 (16.6 MB) with weight 3794245 (53.86/col)
sparse part has weight 3794245 (53.86/col)
filtering completed in 4 passes
matrix is 59263 x 59327 (13.3 MB) with weight 3021409 (50.93/col)
sparse part has weight 3021409 (50.93/col)
saving the first 48 matrix rows for later
matrix is 59215 x 59327 (11.6 MB) with weight 2672491 (45.05/col)
sparse part has weight 2454774 (41.38/col)
matrix includes 64 packed rows
using block size 23730 for processor cache size 15360 kB
commencing Lanczos iteration
memory use: 9.5 MB
lanczos halted after 938 iterations (dim = 59210)
recovered 14 nontrivial dependencies
Lanczos elapsed time = 13.9592 seconds.
Sqrt elapsed time = 1.0246 seconds.
SIQS elapsed time = 15.5372 seconds.
pretesting / qs ratio was 0.93
fac: check tune params contained invalid parameter(s), ignoring tune info.
fac: setting target pretesting digits to 27.08
t15: 67.74
t20: 29.98
t25: 4.05
t30: 0.42
t35: 0.03
fac: estimated sum of completed work is t27.08
. . .[/code]Edit: This is occurring on 2 of 6 machines.

[QUOTE=EdH;588002]
On a different subject, I'm trying to figure out how to send options in the following script line:[code]echo "factor(${composite})" | ./yafu[/code]I've tried adding -one and -silent before and after the pipe (at the ends of each command) and inside and outside the quotes, with and without another set of enclosing quotes. Can these be added to the script line, or can I place them in yafu.ini in some manner? I'm using separate copies of yafu and yafu.ini within the working directory where the script is located, so I'm free to modify yafu.ini to be specific. Alternately for -silent, is there a less verbose mode?
[/QUOTE]

My perl scripts use:
[code]
$cmd="\"$YAFU\" 'factor($_[0])' -p -ecm_path /usr/bin/ecm -logfile $LOGFILE -threads $NUM_CPUS";
...
$res=system($cmd);
[/code]
perl substitutes suitable values for $YAFU, $_[0], $LOGFILE and $NUM_CPUS, then passes the resulting string to the shell.

Or a trivial example from the command line:
[code]
chris@rigel:~/bin$ yafu 'factor(2^128+1)' -threads 2


fac: factoring 340282366920938463463374607431768211457
fac: using pretesting plan: normal
fac: using tune info for qs/gnfs crossover
div: primes less than 10000
rho: x^2 + 3, starting 1000 iterations on C39
rho: x^2 + 2, starting 1000 iterations on C39
rho: x^2 + 1, starting 1000 iterations on C39
pm1: starting B1 = 150K, B2 = gmp-ecm default on C39
ecm: 30/30 curves on C39, B1=2K, B2=gmp-ecm default

starting SIQS on c39: 340282366920938463463374607431768211457

==== sieving in progress ( 2 threads): 656 relations needed ====
==== Press ctrl-c to abort and save state ====
539 rels found: 297 full + 242 from 2231 partial, (34049.89 rels/sec)

SIQS elapsed time = 0.1017 seconds.
Total factoring time = 0.4423 seconds


***factors found***

P22 = 5704689200685129054721
P17 = 59649589127497217

ans = 1
[/code]

Note it used 2 threads for sieving, so it saw the parameter [c]-threads 2[/c]

[QUOTE=EdH;588002]Probably due to my CPUs missing (almost) all the valuable flags, I got an error after "make clean NFS=clean USE_SSE41=clean":[code]$ make NFS=1 USE_SSE41=1
. . .
factor/avx-ecm/avx_ecm.h:836:34: error: unknown type name \u2018__m512i\u2019
836 | void vecmul52_1(vec_bignum_t* a, __m512i b, vec_bignum_t* c, vec_bignum_t* n, vec_bignum_t* s, vec_monty_t* mdata);
| ^~~~~~~
. . .

Sorry if I'm a pain. Thanks for all the help.[/QUOTE]

No worries at all. You just caught me in the middle of other intermediate updates, where I don't even do my usual poor job of checking if things work on other architectures. Try the latest commit now.

[QUOTE=EdH;588029]Revision 2.07 appears to be stuck in a loop:[/QUOTE]

You got me with this one, no idea what's going on. Maybe some context? Is this a resume or did it run through from scratch? Running on cmd line or in interpreter? etc.

[QUOTE=chris2be8;588043]My perl scripts use:
[code]
$cmd="\"$YAFU\" 'factor($_[0])' -p -ecm_path /usr/bin/ecm -logfile $LOGFILE -threads $NUM_CPUS";
...
$res=system($cmd);
[/code]perl substitutes suitable values for $YAFU, $_[0], $LOGFILE and $NUM_CPUS, then passes the resulting string to the shell.
. . .[/QUOTE]Thanks. I'll try some more syntax variations with my script to see if I can match your perl call.

[QUOTE=bsquared;588056]No worries at all. You just caught me in the middle of other intermediate updates, where I don't even do my usual poor job of checking if things work on other architectures. Try the latest commit now.

You got me with this one, no idea what's going on. Maybe some context? Is this a resume or did it run through from scratch? Running on cmd line or in interpreter? etc.[/QUOTE]Excellent! Thanks! All seems well.

Note: I found that tiny, unobtrusive, miniature, lower case, "v" you had hidden in the yafu.ini file.:whistle: So the verbosity is back to my liking.:smile:

As for the looping machines, they were running a bash script that feeds YAFU a composite. Both had already completed a good number of composites via the script. The one machine I noted had been looping for almost 7 hours overnight. I just fed that composite to the new version as a test and it flew through it. (Of course, I expected it would.)

Thanks for all!

Still Have Looping
 

I seemed to still have looping on one of the same machines as before, but I did break out of it without CTRL-c:[code]. . .
starting SIQS on c89: 13552335418571691348826103661651040263240362626711372932187961446062171132450991836093689

==== sieving in progress ( 24 threads): 68592 relations needed ====
==== Press ctrl-c to abort and save state ====
71951 rels found: 21038 full + 50913 from 925085 partial, (1651661.66 rels/sec)

SIQS elapsed time = 17.1809 seconds.

starting SIQS on c89: 13552335418571691348826103661651040263240362626711372932187961446062171132450991836093689

==== sieving in progress ( 24 threads): 68592 relations needed ====
==== Press ctrl-c to abort and save state ====
71951 rels found: 21038 full + 50913 from 925085 partial, (1610592.10 rels/sec)

SIQS elapsed time = 16.3661 seconds.

starting SIQS on c89: 13552335418571691348826103661651040263240362626711372932187961446062171132450991836093689

==== sieving in progress ( 24 threads): 68592 relations needed ====
==== Press ctrl-c to abort and save state ====
71951 rels found: 21038 full + 50913 from 925085 partial, (1650011.16 rels/sec)

SIQS elapsed time = 18.6747 seconds.
. . .[/code]I noticed the rels found was already populated, so I used CTRL-z to pause YAFU and deleted siqs.dat. Then I resumed with "fg" and the SIQS operation started from zero rels and completed the factoring. I've added "rm siqs.dat" to my script so there shouldn't be any leftover relations from previous runs. I'll see if this machine loops anymore.

An exciting day! I just updated all my machines, Core2 , i3, i5, i7, AMD (without SSE4_1) and Xeons. (I had to make a script.)

All are now running YAFU 2.07!!:fusion:

A couple questions:

- I didn't, but should I rebuild the Core2 machines with the Core2 line in the Makefile uncommented?

- In ytools, should the "CC = gcc-7.3.0" be changed to match the "CC = gcc" in the ysieve and YAFU Makefiles?

Thanks for all!

I've just run version 2.07 on my Win-7 machine, and I'm pleased to say that the trouble I was having with 2.06 does not happen with 2.07.
[CODE]JANELT3 C:\Users\Jane\Documents\Maths\yafu\Versions\yafu-2.07 > yafu-x64


YAFU Version 2.07
Built with Microsoft Visual Studio 1928
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 =======
===============================================================

>> nfs(296461670302265261661404037493475256820003211696331293471947264729761541)


starting SIQS on c72: 296461670302265261661404037493475256820003211696331293471947264729761541

==== sieving in progress ( 4 threads): 17568 relations needed ====
==== Press ctrl-c to abort and save state ====
17744 rels found: 6988 full + 10756 from 123762 partial, (2492.55 rels/sec)

SIQS elapsed time = 53.9072 seconds.


***factors found***

P31 = 5080439387107487549436920600141
P41 = 58353549312012091454346752496532032405401

ans = 1

>> exit[/CODE]
So you have yet another satisfied customer :smile:

[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:

[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]

[QUOTE=James Heinrich;587987]is it possible to add in some kind of rough ETA to SIQS[/QUOTE]NFS is even more opaque (to those like me who don't really understand what it's doing). It outputs a lot of stuff to the screen, such as [quote]35916 78129054809 1418312659029451279522
hashtable: 1024 entries, 0.02 MB
total yield: 60665, q=1850021 (0.01060 sec/rel)
nfs: commencing algebraic side lattice sieving over range: 1883341 - 1890008
Warning: lowering FB_bound to 1856672.[/quote]Is it possible to provide any kind of occasional screen output that gives some kind of guidance as to where we are in the NFS progress? At least with SIQS even if there's no ETA you can get some sense of progress, but with NFS it just seems (to me) that it's not-done until it is done.

Well, I spoke too quickly about all being well. (That should teach me a lesson, but probably won't.)

First, all my AMD machines are failing when they they try to use snfs to solve. I've temporarily sidestepped that trouble by using "snfs_xover=95." [STRIKE]I've provided more detail below.[/STRIKE] I'll address this in a separate post, since the second issue is rather lengthy and I'd like to see if I can determine whether this is a YAFU or Msieve issue.

Second, I'm still having the looping issues with SIQS. At present, I have been logging a single episode with v v v and have a log file that's over 25MB. (It's been looping for nearly 11 hours.) I've also discovered that YAFU is currently using 22GB of RAM, and growing into swap. I've tried to trim the log down to the repeating section to make it fit a code block. Here is a portion of the "top" display:[code]Tasks: 433 total, 3 running, 430 sleeping, 0 stopped, 0 zombie
%Cpu(s): 0.5 us, 0.3 sy, 0.2 ni, 92.8 id, 6.1 wa, 0.0 hi, 0.0 si, 0.0 st
MiB Mem : 24041.0 total, 324.9 free, 23343.9 used, 372.2 buff/cache
MiB Swap: 16373.0 total, 9720.1 free, 6652.9 used. 308.1 avail Mem

PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
2911573 math98 20 0 30.3g 22.0g 1212 R 7.0 93.5 627:21.54 yafu[/code]Here's the session log:[code]09/20/21 00:18:25, =====================================
09/20/21 00:18:25, System/Build Info:
09/20/21 00:18:25, YAFU Version 2.07
09/20/21 00:18:25, Built with GCC 9
09/20/21 00:18:25, Using GMP-ECM 7.0.5-dev, Powered by GMP 6.2.1
09/20/21 00:18:25, detected Intel(R) Xeon(R) CPU X5650 @ 2.67GHz
detected L1 = 32768 bytes, L2 = 12582912 bytes, CL = 64 bytes
09/20/21 00:18:25, using 1 random witness for Rabin-Miller PRP checks
09/20/21 00:18:25, Cached 664579 primes: max prime is 9999991

09/20/21 00:18:25, Random seed: 13035443370557393521[/code]Here's the repeating section:[code]found 72442 cycles from 160635 relations in 5 passes
distribution of cycle lengths:
length 1 : 23003
length 2 : 16947
length 3 : 13162
length 4 : 8489
length 5 : 5159
length 6 : 2853
length 7 : 1460
length 9+: 1369
largest cycle: 17 relations
matrix is 68528 x 72442 (16.8 MB) with weight 3819360 (52.72/col)
sparse part has weight 3819360 (52.72/col)
filtering completed in 4 passes
matrix is 59776 x 59840 (13.3 MB) with weight 3016591 (50.41/col)
sparse part has weight 3016591 (50.41/col)
saving the first 48 matrix rows for later
matrix is 59728 x 59840 (11.4 MB) with weight 2594461 (43.36/col)
sparse part has weight 2394272 (40.01/col)
matrix includes 64 packed rows
using block size 23936 for processor cache size 12288 kB
commencing Lanczos iteration
memory use: 9.4 MB
lanczos halted after 945 iterations (dim = 59721)
recovered 14 nontrivial dependencies
Lanczos elapsed time = 14.0724 seconds.
Sqrt elapsed time = 1.0826 seconds.
SIQS elapsed time = 15.7047 seconds.
pretesting / qs ratio was 1.05
fac: setting target pretesting digits to 27.38
t15: 73.14
t20: 33.35
t25: 4.59
t30: 0.48
t35: 0.04
fac: estimated sum of completed work is t27.39

starting SIQS on c89: 11539488294330117240202826559598428302679556688248012471560145814831982545559910259149337
input from file = 11539488294330117240202826559598428302679556688248012471560145814831982545559910259149337
input to yafu = 11539488294330117240202826559598428302679556688248012471560145814831982545559910259149337
input matches with multiple of 1
static memory usage:
initial cycle hashtable: 16777216 bytes
initial cycle table: 160000 bytes
factor base: 1370560 bytes
fb bounds
small: 1024
SPV: 38
10bit: 104
11bit: 176
12bit: 312
13bit: 552
32k div 3: 712
14bit: 1000
15bit: 1760
med: 2880
large: 16688
large_x2: 68528
all: 68528
start primes
SPV: 251
10bit: 1063
11bit: 2053
12bit: 4231
13bit: 8221
32k div 3: 11087
14bit: 16421
15bit: 32803
med: 57667
large: 392957
large_x2: 1823713
all: 1823713
memory usage during sieving:
curr_poly structure: 1048656 bytes
relation buffer: 7602176 bytes
factor bases: 184320 bytes
update data: 890864 bytes
sieve: 32768 bytes
bucket data: 1573672 bytes
memory usage during sieving:
curr_poly structure: 1048656 bytes
relation buffer: 7602176 bytes
factor bases: 184320 bytes
update data: 890864 bytes
sieve: 32768 bytes
bucket data: 1573672 bytes
memory usage during sieving:
curr_poly structure: 1048656 bytes
relation buffer: 7602176 bytes
factor bases: 184320 bytes
update data: 890864 bytes
sieve: 32768 bytes
bucket data: 1573672 bytes
memory usage during sieving:
curr_poly structure: 1048656 bytes
relation buffer: 7602176 bytes
factor bases: 184320 bytes
update data: 890864 bytes
sieve: 32768 bytes
bucket data: 1573672 bytes
memory usage during sieving:
curr_poly structure: 1048656 bytes
relation buffer: 7602176 bytes
factor bases: 184320 bytes
update data: 890864 bytes
sieve: 32768 bytes
bucket data: 1573672 bytes
memory usage during sieving:
curr_poly structure: 1048656 bytes
relation buffer: 7602176 bytes
factor bases: 184320 bytes
update data: 890864 bytes
sieve: 32768 bytes
bucket data: 1573672 bytes
memory usage during sieving:
curr_poly structure: 1048656 bytes
relation buffer: 7602176 bytes
factor bases: 184320 bytes
update data: 890864 bytes
sieve: 32768 bytes
bucket data: 1573672 bytes
memory usage during sieving:
curr_poly structure: 1048656 bytes
relation buffer: 7602176 bytes
factor bases: 184320 bytes
update data: 890864 bytes
sieve: 32768 bytes
bucket data: 1573672 bytes
memory usage during sieving:
curr_poly structure: 1048656 bytes
relation buffer: 7602176 bytes
factor bases: 184320 bytes
update data: 890864 bytes
sieve: 32768 bytes
bucket data: 1573672 bytes
memory usage during sieving:
curr_poly structure: 1048656 bytes
relation buffer: 7602176 bytes
factor bases: 184320 bytes
update data: 890864 bytes
sieve: 32768 bytes
bucket data: 1573672 bytes
memory usage during sieving:
curr_poly structure: 1048656 bytes
relation buffer: 7602176 bytes
factor bases: 184320 bytes
update data: 890864 bytes
sieve: 32768 bytes
bucket data: 1573672 bytes
memory usage during sieving:
curr_poly structure: 1048656 bytes
relation buffer: 7602176 bytes
factor bases: 184320 bytes
update data: 890864 bytes
sieve: 32768 bytes
bucket data: 1573672 bytes
memory usage during sieving:
curr_poly structure: 1048656 bytes
relation buffer: 7602176 bytes
factor bases: 184320 bytes
update data: 890864 bytes
sieve: 32768 bytes
bucket data: 1573672 bytes
memory usage during sieving:
curr_poly structure: 1048656 bytes
relation buffer: 7602176 bytes
factor bases: 184320 bytes
update data: 890864 bytes
sieve: 32768 bytes
bucket data: 1573672 bytes
memory usage during sieving:
curr_poly structure: 1048656 bytes
relation buffer: 7602176 bytes
factor bases: 184320 bytes
update data: 890864 bytes
sieve: 32768 bytes
bucket data: 1573672 bytes
memory usage during sieving:
curr_poly structure: 1048656 bytes
relation buffer: 7602176 bytes
factor bases: 184320 bytes
update data: 890864 bytes
sieve: 32768 bytes
bucket data: 1573672 bytes
memory usage during sieving:
curr_poly structure: 1048656 bytes
relation buffer: 7602176 bytes
factor bases: 184320 bytes
update data: 890864 bytes
sieve: 32768 bytes
bucket data: 1573672 bytes
memory usage during sieving:
curr_poly structure: 1048656 bytes
relation buffer: 7602176 bytes
factor bases: 184320 bytes
update data: 890864 bytes
sieve: 32768 bytes
bucket data: 1573672 bytes
memory usage during sieving:
curr_poly structure: 1048656 bytes
relation buffer: 7602176 bytes
factor bases: 184320 bytes
update data: 890864 bytes
sieve: 32768 bytes
bucket data: 1573672 bytes
memory usage during sieving:
curr_poly structure: 1048656 bytes
relation buffer: 7602176 bytes
factor bases: 184320 bytes
update data: 890864 bytes
sieve: 32768 bytes
bucket data: 1573672 bytes
memory usage during sieving:
curr_poly structure: 1048656 bytes
relation buffer: 7602176 bytes
factor bases: 184320 bytes
update data: 890864 bytes
sieve: 32768 bytes
bucket data: 1573672 bytes
memory usage during sieving:
curr_poly structure: 1048656 bytes
relation buffer: 7602176 bytes
factor bases: 184320 bytes
update data: 890864 bytes
sieve: 32768 bytes
bucket data: 1573672 bytes
memory usage during sieving:
curr_poly structure: 1048656 bytes
relation buffer: 7602176 bytes
factor bases: 184320 bytes
update data: 890864 bytes
sieve: 32768 bytes
bucket data: 1573672 bytes
memory usage during sieving:
curr_poly structure: 1048656 bytes
relation buffer: 7602176 bytes
factor bases: 184320 bytes
update data: 890864 bytes
sieve: 32768 bytes
bucket data: 1573672 bytes
restarting siqs from saved data set
72443 relations found: 23003 full + 49440 from 882638 partial
threw away 0 relations with large primes too small

==== sieve params ====
n = 91 digits, 300 bits
factor base: 68528 primes (max prime = 1823713)
single large prime cutoff: 200608430 (110 * pmax)
double large prime range from 3325929106369 to 2287420354104121
DLP MFB = 1.85
using SSE2 enabled 32k sieve core
sieve interval: 12 blocks of size 32768
polynomial A has ~ 11 factors
using multiplier of 137
using Q2(x) polynomials for kN mod 8 = 1
using SPV correction of 22 bits, starting at offset 38
trial factoring cutoff at 94 bits

==== sieving in progress ( 24 threads): 68592 relations needed ====
==== Press ctrl-c to abort and save state ====
72443 rels found: 23003 full + 49440 from 882638 partial, (1709269.38 rels/sec)
72443 rels found: 23003 full + 49440 from 882638 partial, (1709166.16 rels/sec)
72443 rels found: 23003 full + 49440 from 882638 partial, (1709121.00 rels/sec)
72443 rels found: 23003 full + 49440 from 882638 partial, (1709075.85 rels/sec)
72443 rels found: 23003 full + 49440 from 882638 partial, (1709050.04 rels/sec)
72443 rels found: 23003 full + 49440 from 882638 partial, (1709027.47 rels/sec)
72443 rels found: 23003 full + 49440 from 882638 partial, (1709001.67 rels/sec)
72443 rels found: 23003 full + 49440 from 882638 partial, (1708979.09 rels/sec)
72443 rels found: 23003 full + 49440 from 882638 partial, (1708953.29 rels/sec)
72443 rels found: 23003 full + 49440 from 882638 partial, (1708930.72 rels/sec)
72443 rels found: 23003 full + 49440 from 882638 partial, (1708904.92 rels/sec)
72443 rels found: 23003 full + 49440 from 882638 partial, (1708879.13 rels/sec)
72443 rels found: 23003 full + 49440 from 882638 partial, (1708856.56 rels/sec)
72443 rels found: 23003 full + 49440 from 882638 partial, (1708830.76 rels/sec)
72443 rels found: 23003 full + 49440 from 882638 partial, (1708808.19 rels/sec)
72443 rels found: 23003 full + 49440 from 882638 partial, (1708782.40 rels/sec)
72443 rels found: 23003 full + 49440 from 882638 partial, (1708692.12 rels/sec)
72443 rels found: 23003 full + 49440 from 882638 partial, (1708663.11 rels/sec)
72443 rels found: 23003 full + 49440 from 882638 partial, (1708640.55 rels/sec)
72443 rels found: 23003 full + 49440 from 882638 partial, (1708614.76 rels/sec)
72443 rels found: 23003 full + 49440 from 882638 partial, (1708592.19 rels/sec)
72443 rels found: 23003 full + 49440 from 882638 partial, (1708566.40 rels/sec)
72443 rels found: 23003 full + 49440 from 882638 partial, (1708543.84 rels/sec)
72443 rels found: 23003 full + 49440 from 882638 partial, (1708521.28 rels/sec)
72443 rels found: 23003 full + 49440 from 882638 partial, (1677482.63 rels/sec)

sieving required 0 total polynomials (4294967295 'A' polynomials)
trial division touched 0 sieve locations out of 0
dlp-ecm: 0 failures, 0 attempts, 0 outside range, 0 prp, 0 useful
total reports = 0, total surviving reports = 0
total blocks sieved = 0, avg surviving reports per block = -nan
Elapsed time: 0.5399 sec
QS elapsed time = 0.5400 seconds.

==== post processing stage (msieve-1.38) ====
read 905640 relations
begin singleton removal with 905640 relations
reduce to 160635 relations in 11 passes
attempting to read and process 160635 relations
recovered 160635 relations
recovered 127168 polynomials
attempting to build 72442 cycles[/code]I've attached a full example in text form, that has all the >2k repetitions removed.

Thanks for any help.

What is the command line that starts these looping jobs? I see it is a batchfile job but yafu calls pipes and redirects batchfile jobs also, I think. Wanted to see if I can duplicate here and how yafu is called may matter...

As for your difficulties with older machines I can nearly guarantee it is a yafu issue and not msieve. yafu's siqs is nearly 100% assembly or intrinsics code using sse4.1 or better. The Phenom II x4 doesn't have sse4.1. Yafu's sse2-only compile option will apparently still compile but I haven't tested that build in... a while.


[QUOTE=BudgieJane;588140]I've just run version 2.07 on my Win-7 machine, and I'm pleased to say that the trouble I was having with 2.06 does not happen with 2.07.
[/Quote]

Yay, glad to hear it!

Addendum to previous SIQS issue
 

I've also noticed that siqs.dat has a current size of over 50MB. I removed it and YAFU broke out of the loop. I've attached the end of the log, since it is too large for a code block. I have saved the larger siqs.dat, but it's too large to post. If you would like, I can work with it in some manner, or maybe compress and post it somewhere.

Thanks!

[QUOTE=bsquared;588229]What is the command line that starts these looping jobs? I see it is a batchfile job but yafu calls pipes and redirects batchfile jobs also, I think. Wanted to see if I can duplicate here and how yafu is called may matter...

As for your difficulties with older machines I can nearly guarantee it is a yafu issue and not msieve. yafu's siqs is nearly 100% assembly or intrinsics code using sse4.1 or better. The Phenom II x4 doesn't have sse4.1. Yafu's sse2-only compile option will apparently still compile but I haven't tested that build in... a while.
. . .[/QUOTE]I suspected the missing SSE4_1 was the issue. I tried building without the NFS=1 and it errorred with "nfs" references. To my untrained eye, SIQS appears to be fine. The error appears if YAFU finds the composite to be snfs compatible. Is it still running SIQS for snfs worthy composites? I'll try the sse2-only in a little while. This is a very minor issue for me, if any. The current work-around is fine.

The looping is very intermittent as a whole, so I don't think you'll be able to duplicate it easily. (That's why I have all my machines using "v v v" to a log file.) Last night, I factored several thousand composites in the 89 digit range across several machines and only one looped. (Unfortunately, it takes that machine out of the system until I intervene.) The previous night, during about the same time frame, four looped. YAFU is being called via a BASH script line:[code]echo "factor(${composite})" | ./yafu -one >>dbW.log[/code](The "-one" might be working now, but I haven't verified.)

The siqs.dat file is explicitly deleted prior to each run and the dbW.log file is re-initialized for each run as well, so they are purely written by the current iteration of YAFU.

Thanks for all.

[QUOTE=EdH;588234]I suspected the missing SSE4_1 was the issue. I tried building without the NFS=1 and it errorred with "nfs" references. To my untrained eye, SIQS appears to be fine. The error appears if YAFU finds the composite to be snfs compatible. Is it still running SIQS for snfs worthy composites? I'll try the sse2-only in a little while. This is a very minor issue for me, if any. The current work-around is fine.
[/QUOTE]

Ok I guess I misunderstood; I thought it was a siqs issue not snfs. If I read fast those two acronyms look the same :blush:

So ignore everything I said about sse2/4.1, that shouldn't be an issue with snfs. For snfs the yafu-side code should be pretty agnostic to cpu... so I'm not sure why it would not work with older machines. Maybe it's an msieve issue after all. I will take a look at the yafu side at least and see if anything occurs to me.

A couple feature requests/thoughts:
Would it be possible to implement aurifeuillian factor calculation? would speed up factorization of certain forms.
Would prioritizing composite factors found via rho/ecm be a feature you'd be able to add?

More loop issue data
 

So far today I've found four instances (includes overnight). But, again, that's in several thousand factorizations, so it's still not common.

I found some interesting (at least to me) bits in factor.log of one of the machines. I've attached the whole log.

Of interest, I found these differences between failed loops and the final one that was after I removed siqs.dat.

Here are some lines from the failed loop just previous to the successful one:[code]09/21/21 12:33:35, DLP MFB = 1.85
09/21/21 12:33:35, using SSE41 enabled 32k sieve core
09/21/21 12:33:35, sieve interval: 13 blocks of size 32768
09/21/21 12:33:35, polynomial A has ~ 12 factors
. . .
09/21/21 12:33:35, ==== sieving started ( 8 threads) ====
09/21/21 12:33:35, trial division touched 0 sieve locations out of 0
09/21/21 12:33:35, total reports = 0, total surviving reports = 0
09/21/21 12:33:35, total blocks sieved = 0, avg surviving reports per block = -nan
09/21/21 12:33:35, dlp-ecm: 0 failures, 0 attempts, 0 outside range, 0 prp, 0 useful
09/21/21 12:33:35, 79066 relations found: 21666 full + 57400 from 1145924 partial, using 0 polys (-1 A polys)
09/21/21 12:33:35, on average, sieving found inf rels/poly and 2083055.32 rels/sec
09/21/21 12:33:35, trial division touched 0 sieve locations out of 0
09/21/21 12:33:35, ==== post processing stage (msieve-1.38) ====
09/21/21 12:33:35, QS elapsed time = 0.5606 seconds.
. . .
09/21/21 12:33:52, lanczos halted after 1138 iterations (dim = 71861)
09/21/21 12:33:52, recovered 15 nontrivial dependencies
09/21/21 12:33:54, Lanczos elapsed time = 17.6298 seconds.
09/21/21 12:33:54, Sqrt elapsed time = 1.2765 seconds.
09/21/21 12:33:54, SIQS elapsed time = 19.4675 seconds.
[/code]and, here are corresponding sections of the successful completion:[code]09/21/21 12:33:54, DLP MFB = 1.85
09/21/21 12:33:54, allocating 8 large prime slices of factor base
09/21/21 12:33:54, buckets hold 2048 elements
09/21/21 12:33:54, large prime hashtables have 1703936 bytes
09/21/21 12:33:54, using SSE41 enabled 32k sieve core
09/21/21 12:33:54, sieve interval: 13 blocks of size 32768
09/21/21 12:33:54, polynomial A has ~ 12 factors
. . .
09/21/21 12:33:54, ==== sieving started ( 8 threads) ====
09/21/21 12:38:46, trial division touched 39333795 sieve locations out of 521638707200
09/21/21 12:38:46, total reports = 39333795, total surviving reports = 13059246
09/21/21 12:38:46, total blocks sieved = 15919150, avg surviving reports per block = 0.82
09/21/21 12:38:46, dlp-ecm: 25 failures, 1061012 attempts, 7063329 outside range, 4629850 prp, 860162 useful
09/21/21 12:38:46, 78670 relations found: 21569 full + 57101 from 1143648 partial, using 612275 polys (1100 A polys)
09/21/21 12:38:46, on average, sieving found 1.90 rels/poly and 3985.64 rels/sec
09/21/21 12:38:46, trial division touched 39333795 sieve locations out of 521638707200
09/21/21 12:38:46, ==== post processing stage (msieve-1.38) ====
09/21/21 12:38:46, QS elapsed time = 292.3540 seconds.
. . .
09/21/21 12:39:03, lanczos halted after 1139 iterations (dim = 71926)
09/21/21 12:39:03, recovered 16 nontrivial dependencies
09/21/21 12:39:04, prp59 = 52849932024287778885817430875314364339557493580386262089853
09/21/21 12:39:04, prp33 = 166873661278274944173735579427313
09/21/21 12:39:04, Lanczos elapsed time = 17.4163 seconds.
09/21/21 12:39:04, Sqrt elapsed time = 0.3407 seconds.
09/21/21 12:39:04, SIQS elapsed time = 310.1780 seconds.
[/code]There are, of course other differences, as can be seen in factor.log. Hopefully, this info is helpful.

Thanks for all.

[QUOTE=EdH;588346]So far today I've found four instances (includes overnight). But, again, that's in several thousand factorizations, so it's still not common.

[/QUOTE]

The differences in those bits of log stem from the fact that the first one was a restart and the second one wasn't. But why would the first one restart after everything apparently completed? The only thing I can think of is that no factor was found in the 15 dependencies. In that case yafu would try to redo the factorization, but since a data file still exists it would of course just reuse it, and the same 0-for-15 result would ensue during the sqrt phase. And so on.

When you manually delete the file then a different set of dependencies would result and (with high likelihood) the factorization completes successfully.

Assuming this conclusion is correct, the question now is what to do about it. First, detect it, and second, probably do some more sieving. Maybe step zero is to just print some statement to the log file that no factors were found during sqrt. Then your script can see it and start over.

Could I delete siqs.dat as soon as "SIQS elapsed time" appears in factor.log? Is there any need for siqs.dat to exist after that point? It would be easy for me to have a separate script watching factor.log for that line and invoke a deletion. As long as that wouldn't interfere with normal runs, I'll try it. I'm already deleting siqs.dat prior to each run anyway. This would just do it sooner.

[QUOTE=EdH;588356]Could I delete siqs.dat as soon as "SIQS elapsed time" appears in factor.log? Is there any need for siqs.dat to exist after that point? It would be easy for me to have a separate script watching factor.log for that line and invoke a deletion. As long as that wouldn't interfere with normal runs, I'll try it. I'm already deleting siqs.dat prior to each run anyway. This would just do it sooner.[/QUOTE]

There is no need for the file after that line, no.

[QUOTE=bsquared;588357]There is no need for the file after that line, no.[/QUOTE]Would it make any sense for YAFU itself to have an option to auto-delete siqs.dat at the point where it's no longer required? Defaulted off of course, but perhaps easier (or at least more reliable) than depending on external programs to monitor and delete when it's (hopefully) no longer needed (or via manual cleanup).

[QUOTE=James Heinrich;588358]Would it make any sense for YAFU itself to have an option to auto-delete siqs.dat at the point where it's no longer required? Defaulted off of course, but perhaps easier (or at least more reliable) than depending on external programs to monitor and delete when it's (hopefully) no longer needed (or via manual cleanup).[/QUOTE]

Yes that does make sense :smile:.

There is also the existing "inmem" option. As the name suggests, siqs does all work in RAM and never writes to siqs.dat. Of course if something goes wrong or you want to abort then you have to start over. But for most jobs that's seconds to a few minutes or so. And in EdH's case it would probably solve the looping problem because if no factors are found, the next time around an entirely new matrix will be built.

usage:
-inmem 70

Where 70 (for example) means that all 70 digit inputs or smaller are processed without saving to file.

[QUOTE=bsquared;588360]There is also the existing "inmem" option...
Where 70 (for example) means that all 70 digit inputs or smaller are processed without saving to file.[/QUOTE]Ooh, I didn't know about that, new feature in 2.0 I guess (I'm still mostly stuck with 1.34 on my i7-3930K).
It will go nicely with the [URL="https://www.mersenneforum.org/showthread.php?t=27099"]extension to -pretest feature[/URL] I requested. :wink:

[QUOTE=bsquared;588360]Yes that does make sense :smile:.

There is also the existing "inmem" option. As the name suggests, siqs does all work in RAM and never writes to siqs.dat. Of course if something goes wrong or you want to abort then you have to start over. But for most jobs that's seconds to a few minutes or so. And in EdH's case it would probably solve the looping problem because if no factors are found, the next time around an entirely new matrix will be built.

usage:
-inmem 70

Where 70 (for example) means that all 70 digit inputs or smaller are processed without saving to file.[/QUOTE]Excellent! I'm changing all my yafu.ini files to inmem=95 (since I'm working at 91 digits right now). I'll let you know if that prevents the machines from looping. . .

Thanks!

[QUOTE=EdH;588364]Excellent! I'm changing all my yafu.ini files to inmem=95 (since I'm working at 91 digits right now). I'll let you know if that prevents the machines from looping. . .[/QUOTE]I made it overnight and so far today without any looping, so I'm going to declare this a suitable setting. Additionally, I reset the "inmem" to 70 and wrote a script to factor one of the failed composites repeatedly, trying for a loop. The three machines I ran the script on totaled over 700 iterations without an occurrence. The script is provided below for others to try or comment on.[code]#!/bin/bash

comp=11539488294330117240202826559598428302679556688248012471560145814831982545559910259149337

count=0
while [ ! -e stopTest ]
do
rm siqs.dat 2>/dev/null
rm factor.log 2>/dev/null
rm session.log 2>/dev/null
rm loopTest.log 2>/dev/null
let count=${count}+1
dt=$(date)
echo "Run ${count} started at ${dt:16:11}"
echo "siqs(${comp})" | ./yafu >>loopTest.log
done[/code]

Single yafu.ini across several varied machines
 

For ease of updates, etc., I would like to have a single yafu.ini that will work on all my machines (maybe excluding the AMDs). I currently have that for everything but the tune_info. It appears that I can add all the machines' tune_info into a single yafu.ini and the appropriate line will be used for each machine.

Is there a limit to how many tune_info lines I should use? I have several of a particular i7 and they vary in RAM (or other specs). Should I choose the lower or higher set of values, or are they close enough (if even different) that I would notice no difference?

Thanks for all.

[QUOTE=EdH;588415]For ease of updates, etc., I would like to have a single yafu.ini that will work on all my machines (maybe excluding the AMDs). I currently have that for everything but the tune_info. It appears that I can add all the machines' tune_info into a single yafu.ini and the appropriate line will be used for each machine.

Is there a limit to how many tune_info lines I should use? I have several of a particular i7 and they vary in RAM (or other specs). Should I choose the lower or higher set of values, or are they close enough (if even different) that I would notice no difference?

Thanks for all.[/QUOTE]

There is no built-in limit. There is nothing computationally intensive about processing them. So, have a ball! If it helps at all the structure of them is:

cpu-string, os-string, siqs-mult, siqs-exp, nfs-mult, nfs-exp, siqs-gnfs-xover, freq

If the line's cpu-string and os-string match the current cpu/os then the rest of the line is parsed and applied, RAM and other system configuration will not enter into it. Really only the siqs-gnfs-xover number is used, the rest is just informational (but parsing expects them to be there - it is not robust to missing info). The mult/exp numbers are constants in an exponential trendline fit to the data measured during tune. The freq is unused, I think tune just assigns it the value '42' for now. Because, reasons.

[QUOTE=bsquared;588423]There is no built-in limit. There is nothing computationally intensive about processing them. So, have a ball! If it helps at all the structure of them is:

cpu-string, os-string, siqs-mult, siqs-exp, nfs-mult, nfs-exp, siqs-gnfs-xover, freq

If the line's cpu-string and os-string match the current cpu/os then the rest of the line is parsed and applied. Really only the siqs-gnfs-xover number is used, the rest is just informational (but parsing expects them to be there - it is not robust to missing info). The mult/exp numbers are constants in an exponential trendline fit to the data measured during tune. The freq is unused, I think tune just assigns it the value '42' for now. Because, reasons.[/QUOTE]Excellent! Thanks for the extra info. Does the tune_info take precedence over "xover=100," or do I need to comment (% ) that out?

[QUOTE=EdH;588425]Excellent! Thanks for the extra info. Does the tune_info take precedence over "xover=100," or do I need to comment (% ) that out?[/QUOTE]

tune_info should take precedence, but let me know if not.

[QUOTE=bsquared;588427]tune_info should take precedence, but let me know if not.[/QUOTE]i have should have checked first, but tune_info is superseded by xover:[code]fac: using specified qs/gnfs crossover of 100 digits
fac: using specified qs/snfs crossover of 75 digits[/code]vs.:[code]fac: using tune info for qs/gnfs crossover[/code]when I comment it out.


Thanks.

NFS screen output shows up ugly under Win10, see attached. Something about mangled CRLF I guess?

I've had that happen too. It must be a bug in YAFU, as it doesn't happen in other command line software.

Would it be possible to have YAFU (optionally) output to factor.log a partial-progress report on ECM, either after every <1000> curves, or better would be if no output to factor.log has happened in the last <60> minutes. It would be useful (to me anyways) to both easily check progress on a remote machine and provide some fallback in the event of power failure or similar.

[QUOTE=bsquared;588423]
The freq is unused, I think tune just assigns it the value '42' for now. Because, reasons.[/QUOTE]

According to Douglas Adams, 42 is the answer to the meaning of life, the universe, and everything. Maybe they are the reasons?

Is there somewhere a complete-idiot's-guide (i.e. Windows user) to getting YAFU2 compiled and working on linux (CentOS 8 in my case) ?

[QUOTE=James Heinrich;588761]Is there somewhere a complete-idiot's-guide (i.e. Windows user) to getting YAFU2 compiled and working on linux (CentOS 8 in my case) ?[/QUOTE]Have you looked at my "[URL="https://www.mersenneforum.org/showthread.php?t=26764"]How I install YAFU2 onto my Ubuntu Machines[/URL]" to see if it might help? It does not go into the details of using all the options, but it may be a place to start.

[QUOTE=James Heinrich;588761]Is there somewhere a complete-idiot's-guide (i.e. Windows user) to getting YAFU2 compiled and working on linux (CentOS 8 in my case) ?[/QUOTE]


Written for an older version but [url]https://mersenneforum.org/showthread.php?t=23087[/url] should be useful. Any differences to this probably should be added (in an appendix if they don't affect Ubuntu).

I just updated tune_info for yafu 2.07 in my yafu.ini file

[CODE]
tune_info=Intel(R) Core(TM) i7-4710MQ CPU @ 2.50GHz,WIN64,8.66985e-06,0.221065,19.753,0.0695336,96.607,42[/CODE]
and then ran yafu 2.07 on a small number. Imagine my surprise when this turned up on the screen:
[CODE]
fac: check tune params contained invalid parameter(s), ignoring tune info.
qs_mult = 0.000000e+00
qs_exp = 0.000000e+00
qs_freq = 0.000000e+00
nfs_mult = 0.000000e+00
nfs_exp = 0.000000e+00
nfs_freq = 0.000000e+00[/CODE]
This seems strange when yafu claims that the parameters that it itself wrote to my yafu.ini file not 15 minutes earlier are invalid.
What's occurring?

[QUOTE=henryzz;588765]Written for an older version but [URL]https://mersenneforum.org/showthread.php?t=23087[/URL] should be useful. Any differences to this probably should be added (in an appendix if they don't affect Ubuntu).[/QUOTE]I've done a separate one for YAFU2. See the previous post I got in just before yours, so you missed it. Thanks for the mention.

[QUOTE=BudgieJane;588767]I just updated tune_info for yafu 2.07 in my yafu.ini file
. . .
and then ran yafu 2.07 on a small number. Imagine my surprise when this turned up on the screen:
. . .

[This seems strange when yafu claims that the parameters that it itself wrote to my yafu.ini file not 15 minutes earlier are invalid.
What's occurring?[/QUOTE]Try another "git pull." I think the earlier one I was experiencing this with, was also 2.07, but it was an earlier commit. My latest pull has been working fine with its new tune_info.

[QUOTE=EdH;588779]Try another "git pull." I think the earlier one I was experiencing this with, was also 2.07, but it was an earlier commit. My latest pull has been working fine with its new tune_info.[/QUOTE]

Thanks for the hint. I downloaded the executable, then ran tune again. No change.

[QUOTE=BudgieJane;588813]Thanks for the hint. I downloaded the executable, then ran tune again. No change.[/QUOTE]
I missed that you were using an executable, rather than building yourself.

[QUOTE=Stargate38;588630]I've had that happen too. It must be a bug in YAFU, as it doesn't happen in other command line software.[/QUOTE]

Those messages come from the ggnfs sievers.

[QUOTE=James Heinrich;588671]Would it be possible to have YAFU (optionally) output to factor.log a partial-progress report on ECM, either after every <1000> curves, or better would be if no output to factor.log has happened in the last <60> minutes. It would be useful (to me anyways) to both easily check progress on a remote machine and provide some fallback in the event of power failure or similar.[/QUOTE]

Yes, good suggestion thanks.

[QUOTE=BudgieJane;588730]According to Douglas Adams, 42 is the answer to the meaning of life, the universe, and everything. Maybe they are the reasons?[/QUOTE]

:smile:

[QUOTE=bsquared;588832]Those messages come from the ggnfs sievers.[/QUOTE]These are the same ggnfs executables I use with v1.34 (on Win7) and they do not produce linemash output there, so there's some minor difference between 1.34+Win7 and 2.07+Win10. I'm not sure if YAFU manipulates (or even sees?) the ggnfs output at all, if not it may not be anything you can fix.