YAFU Version 2.10

[James Heinrich]

I tried building YAFU under WSL2/Ubuntu22.04 in Win11 on my Ryzen 7950X using EdH's instructions.

make yafu NFS=1 USE_SSE41=1 USE_AVX2=1 USE_BMI2=1 ICELAKE=1
make: *** [Makefile:399: factor/gmp-ecm/tinyecm.o] Error 1

make yafu NFS=1 USE_SSE41=1 USE_AVX2=1 USE_BMI2=1 SKYLAKE=1
success

lscpu tells me (bold is all AVX-512, green is the ones mentioned further below):

fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt pdpe1gb rdtscp lm constant_tsc rep_good nopl tsc_reliable nonstop_tsc cpuid extd_apicid pni pclmulqdq ssse3 fma cx16 sse4_1 sse4_2 movbe popcnt aes xsave avx f16c rdrand hypervisor lahf_lm cmp_legacy svm cr8_legacy abm sse4a misalignsse 3dnowprefetch osvw topoext perfctr_core ssbd ibrs ibpb stibp vmmcall fsgsbase bmi1 avx2 smep bmi2 erms invpcid avx512f avx512dq rdseed adx smap avx512ifma clflushopt clwb avx512cd sha_ni avx512bw avx512vl xsaveopt xsavec xgetbv1 xsaves avx512_bf16 clzeroxsaveerptr arat npt nrip_save tsc_scale vmcb_clean flushbyasid decodeassists pausefilter pfthreshold v_vmsave_vmload avx512vbmi umip avx512_vbmi2 gfni vaes vpclmulqdq avx512_vnni avx512_bitalg avx512_vpopcntdq rdpid fsrm

Originally Posted by README

SKYLAKEX will add support for AVX512F and AVX512BW.
ICELAKE will add support for AVX512F, AVX512BW, and AVX512IFMA.

To me it looks like I have AVX512IFMA? Should I be make'ing YAFU with different flags?

[James Heinrich]

But the AVX512 issue aside, the Linux build I now have seems perfectly happy to through the -batchfile list of assignments, no crashing on P-1 like the Windows binary does.

Case #1:
edit: Well, it worked nicely for the first 236 inputs, then started spamming the screen with this kind of thing in infinite loop (for about 35 minutes before I noticed it):

**** finished poly work in thread 6
nfs: thread 15 commencing polynomial search over range: 57829442 - 57829692
deadline: 8640000 CPU-seconds per coefficient
error generating or reading NFS polynomials
**** finished poly work in thread 15
nfs: thread 4 commencing polynomial search over range: 57829692 - 57829942
deadline: 8640000 CPU-seconds per coefficient
error generating or reading NFS polynomials
**** finished poly work in thread 4
nfs: thread 1 commencing polynomial search over range: 57829942 - 57830192
deadline: 8640000 CPU-seconds per coefficient
error generating or reading NFS polynomials
**** finished poly work in thread 1
nfs: thread 10 commencing polynomial search over range: 57830192 - 57830442
deadline: 8640000 CPU-seconds per coefficient
error generating or reading NFS polynomials
**** finished poly work in thread 10
^Z
[1]+  Stopped

Seemed to get stuck (including on restart) on 4883304788759377425832442960351366921415998012385829279000071261453377754486259


Case #2:
Stuck on 6064229034709002472262972268188545203995543889159050770751775303656682657114151
or 7037143403475036214202972850064341177702412654627932222322186191725165912592743

...
total yield: 35448, q=530017 (0.00037 sec/rel)
nfs: commencing msieve filtering
6064229034709002472262972268188545203995543889159050770751775303656682657114151
checking relations array at location 1
checking relations array at location 1
checking relations array at location 1
checking relations array at location 1
error: number of relsets too large

[bsquared]

Originally Posted by James Heinrich

But the AVX512 issue aside, the Linux build I now have seems perfectly happy to through the -batchfile list of assignments, no crashing on P-1 like the Windows binary does.

Case #1:
edit: Well, it worked nicely for the first 236 inputs, then started spamming the screen with this kind of thing in infinite loop (for about 35 minutes before I noticed it):

**** finished poly work in thread 6
nfs: thread 15 commencing polynomial search over range: 57829442 - 57829692
deadline: 8640000 CPU-seconds per coefficient
error generating or reading NFS polynomials
**** finished poly work in thread 15
nfs: thread 4 commencing polynomial search over range: 57829692 - 57829942
deadline: 8640000 CPU-seconds per coefficient
error generating or reading NFS polynomials
**** finished poly work in thread 4
nfs: thread 1 commencing polynomial search over range: 57829942 - 57830192
deadline: 8640000 CPU-seconds per coefficient
error generating or reading NFS polynomials
**** finished poly work in thread 1
nfs: thread 10 commencing polynomial search over range: 57830192 - 57830442
deadline: 8640000 CPU-seconds per coefficient
error generating or reading NFS polynomials
**** finished poly work in thread 10
^Z
[1]+  Stopped

Seemed to get stuck (including on restart) on 4883304788759377425832442960351366921415998012385829279000071261453377754486259


Case #2:
Stuck on 6064229034709002472262972268188545203995543889159050770751775303656682657114151
or 7037143403475036214202972850064341177702412654627932222322186191725165912592743

...
total yield: 35448, q=530017 (0.00037 sec/rel)
nfs: commencing msieve filtering
6064229034709002472262972268188545203995543889159050770751775303656682657114151
checking relations array at location 1
checking relations array at location 1
checking relations array at location 1
checking relations array at location 1
error: number of relsets too large

Thank you for those. At first I was wondering why in the world it is running nfs on C79's but then realized YAFU detects they are cofactors of SNFS forms: 10^92 + 584669, 10^94 - 169754, and 10^92 + 650179 respectively.

Some numbers in that range may be competitive with SIQS, but definitely not these. I would raise snfs_xover in yafu.ini to something like 95 or 100 to avoid this problem.

That said, both the 2nd and 3rd of your example finish fine for me with snfs, just 4 times slower than siqs would have finished. The first example does go into an infinite loop because it detects the SNFS form, then decides that gnfs would actually be better, but there are no good preconfigured parameters for poly selection on a gnfs 79. So it never finds one. It does not occur to the nfs poly selection routine to consider siqs instead of gnfs... that is something I can fix. I don't think it is worth figuring out gnfs parameters for less than c85.

Continue building with SKYLAKEX on the Zen 4 machine. IFMA as of now only helps with AVX-ECM, but there is something wrong with the IFMA code there; it is not finding factors that it should be finding. So until I can fix that don't use the ICELAKE build option. Edit: Also make sure you are using SKYLAKEX, not just SKYLAKE. It will just ignore the latter. I guess I should teach the makefile to accept either one.

Thanks again for all of the use/testing!

[henryzz]

Originally Posted by bsquared

Edit: Also make sure you are using SKYLAKEX, not just SKYLAKE. It will just ignore the latter. I guess I should teach the makefile to accept either one.

That's just going to confuse people with actual skylake cpus.

[bsquared]

Originally Posted by henryzz

That's just going to confuse people with actual skylake cpus.

You're right. Of course James doesn't have either one, he has a Zen 4. When I first starting writing AVX-512 code, skylakex was what I was using. I was lazy and just tied use of AVX-512 instructions to that processor architecture, not thinking that it may eventually be available in other architectures or even cpu brands. So, SKYLAKEX is really a codeword for "use AVX-512F and BW instruction sets". Just remember to put the X on there.

[James Heinrich]

Originally Posted by bsquared

I would raise snfs_xover in yafu.ini to something like 95 or 100 to avoid this problem.

Default yafu.ini:70 has % snfs_xover=85 (commented-out), I don't know what the fallback default is. I have now set it to 95.

Originally Posted by bsquared

Also make sure you are using SKYLAKEX, not just SKYLAKE. It will just ignore the latter. I guess I should teach the makefile to accept either one.

I totally missed the X
I rebuilt it with SKYLAKEX and it seemed to work. It finished the last hundred assignments without complain anyways.

Is there some way to see what features YAFU is built with? Maybe a line in the header would be interesting:

YAFU Version 2.10
Built with GCC 11
Built with CPU features: SSE4.1 AVX2 AVX512
Using GMP-ECM 7.0.6-dev, Powered by GMP 6.2.1
Detected AMD Ryzen 9 7950X 16-Core Processor

[henryzz]

Originally Posted by bsquared

You're right. Of course James doesn't have either one, he has a Zen 4. When I first starting writing AVX-512 code, skylakex was what I was using. I was lazy and just tied use of AVX-512 instructions to that processor architecture, not thinking that it may eventually be available in other architectures or even cpu brands. So, SKYLAKEX is really a codeword for "use AVX-512F and BW instruction sets". Just remember to put the X on there.

Maybe basing on cpu features would make more sense?

[James Heinrich]

I was mildly amused by this:

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

>> help
searching for help on 'help'
>>

Not particularly helpful help.

[bsquared]

Originally Posted by James Heinrich

Default yafu.ini:70 has % snfs_xover=85 (commented-out), I don't know what the fallback default is. I have now set it to 95.

I totally missed the X
I rebuilt it with SKYLAKEX and it seemed to work. It finished the last hundred assignments without complain anyways.

Is there some way to see what features YAFU is built with? Maybe a line in the header would be interesting:

The built-in default was 75. I'll change that to 95 (same as gnfs/siqs crossover).

Originally Posted by henryzz

Maybe basing on cpu features would make more sense?

Yes it would.

Originally Posted by James Heinrich

I was mildly amused by this:Not particularly helpful help.

It is supposed to print the relevant portion of the help document. The help document is not up to date anyway, something else that needs work. Lately I have been trying to keep the .ini file up to date with what the various options do.

[bsquared]

Originally Posted by bsquared

Lately I have been trying to keep the .ini file up to date with what the various options do.

An unfortunate side effect of this is that when I add an option and update the repository yafu.ini, then a user's yafu.ini file (maybe full of custom things) gets overwritten when they update versions. Or is there a merge feature when fetching/pulling from github? I'm still a relative noob with git/github.

[BudgieJane]

Originally Posted by bsquared

An unfortunate side effect of this is that when I add an option and update the repository yafu.ini, then a user's yafu.ini file (maybe full of custom things) gets overwritten when they update versions. Or is there a merge feature when fetching/pulling from github? I'm still a relative noob with git/github.

You are implying that users don't back up their files when they update versions. I find that hard to believe. In my case, if I have made changes in yafu.ini, I will always compare my changed version with what I have just downloaded, and make any necessary changes to that one (after backing that up, too.)