Looks good for cryptonight. The're also releasing a Ryzen 9 series with up to 16 cores, 32 threads and
72 MB cache, enough to run a full 32 threads of cryptonight with room to spare.
The R9 still uses 2 channel memory where the next bottleneck is. Need Threadripper to get 4 channels.

Hoping for some AVX2 improvements but haven't heard of any.

The 3000G series is an interesting curiosity, boasting the "most powerful graphics" on a desktop CPU.
assuming it's Radeon based it should be possible to mine with it. It might be a good choice for a GPU
rig to add a little extra hash for about the same price as an equivalent Intel CPU.

From a feature perspective AMD already beat Intel with SHA on the first gen Ryzens, and they closed
the gap with the addition of AVX2 capability if not AVX2 performance.

AMD caught up with Intel with gen1 Ryzen and is now pulling ahead while Intel continues delay its
next generation architecture, which includes AVX512,  and instead puts out refresh after refresh
of Skylake.

I thought Intel would wake up with Ryzen gen1 but their only response was to add a couple of cores
to the latest Skylake refresh and call it Coffeelake.

It's nice to see AMD giving Intel a good run but I wish intel would get their heads back into the race.

It seems you are correct. I have a skylake running linux, a haswell running windows and a ryzen
running linux. The ryzen and haswell both need affinity set, the skylake doesn't. I would extrapolate
that a ryzen running windows wouldn't need afinity either.

Seems odd but it's not an issue with the miner. Thanks for all your help. It's difficult when I don't
have the precise environment to reproduce certain problems.

The mod is in a bad mood and decided to overreach with rule enforcement.
Here's a repost of the release announcement, all by itself. I hope it stays
that way.

This announcement deserves a thorough reading by anyone considering
using the cpu-affinity option when mining with fewer miner threads than CPU
threads.
---

cpuminer-opt-3.9.2.4

Yet more cpu-affinity fixes, hopefully the last.

https://github.com/JayDDee/cpuminer-opt/releases/tag/v3.9.2.4

Edit: The advice below applies to Linux. It seems on Windows the behaviour is
the exact opposite.

Affinity should rarely be used, dependant on how the CPU maps the affinity mask to
CPU threads.

With Intel CPUs the default will ensure all physical cores get assigned one thread before
doubling up with hyperthreading. Some fine tuning might help distribute the cores with
2 threads more evenly when miner thread count is not exactly half the number of CPU threads.

In short, on an Intel 8/16 CPU threads 0 & 8 are hyperthreaded on the same physical core
and therefore compete for shared resources and should be avoided as much as possible.

AMD is different and requires custom affinity specifying an alternating bit mask pattern (0x5555 or
0xAAAA for even or odd threads respectively) to ensure optimum distribution of miner threads.
This applies to all AMD CPUs due to the modular architecture of AMD's Computing Complex.

In short, on an AMD CPU threads 0 & 1 compete for shared physical resources.

First question: Absolutely but they don't and it's easier to troubleshoot with fewer variables.

Second question: I can look at the data when available and determine myself but I also wanted to compare
with your expectations when using a simpler mask.

Computers are binary, everything works better in powers of 2.

I think you're overcomplicating things. Defaults exist for a reason, you shouldn't change them
without a very good reason and knowing what you're doing. You stilll haven't given me a reason
and I have questions that you know what you're doing considering you're using an alternating
bit affinity mask with an Intel CPU. That's not meant to be an insult, it's just that I fail to see any
logical reason for what you are doing or why.

---

There's another downside to specifying a custom cpu affinity. Whe using  the default
each thread is affined to a precise cpu, the one matching the thread number.
With a custom affinity mask it's more complicated so the thread is afffined to the "mask"
which means any of the allowable cpus.

I don't feel like doing the additional coding to do one to one matching of each thread
to a unique allowable cpu.

Affinity should only be needed if there is a good reason to run fewer threads and if the CPU
is an AMD. That's small set.

---

It's not about perfomance, it's a test to troubleshoot affinity. Yes start with all defaults then
add options until it breaks. And use -D for testing and note thread distribution in task manager.

1. all defaults, already done, test passed.

2. half threads (28), default affinity?

3. half threads, alternating affinity?

4. What you really want, test failed.

In my experience default affinity works best for Intel CPUs using half threads, but not on AMD where
a mask is needed with alternating bits set. Keep this in mind when you set affinity in test 4 to avoid
hyperthreading.

Repeating test 3 with 0x0055555555555555 and 0x000000000FFFFFFF should confirm that, the latter
giving the same performane as with default affinity.

And don't use any external tools to set affinity or otherwise mess with the test, It's a test, have I said
that before, don't introduce extraneous variables.

---

I've made some more tweaks and this is what I get  with -t 8 --cpu-affinity=0x5555
on Linux. I'l wait for your test results on Windows before I commit the change.

Also what is your goal? Why are you going to all this trouble with odd thread counts and
complex affinity masks?

Enough with the overly complex test cases. I've said it before DEFAULTS!

---

This CPU affinity crap is starting to piss me off. That's not what I came back for.
It's taking way too much of my time.

This all started with a request to support CPU groups on Windows. Windows is a
commercial product: it costs money to use it and takes even more money to
develop on it and for it. Enterprise level development (multi-socket, large thread
counts, NUMA, CPU groups, etc) costs even more.

Yet I don't get paid a penny.

From now on any requests for features specific to Windows must be accompanied
by a nominal non-refundable donation. I will do an assessment and determine if I can
do it with my skill level and resources and how much work may be involved. I will
then set a fee payable on completion. The fee will be scaled based on whether the
feature is for consumers or enterprises.

CPU groups is an enterprise feature. I will make one more attempt to fix the current
issues. If that fails I wlll remove the CPU Groups support and revert to v3.8.8.1 affinity..

cpuminer-opt-3.9.2.3

Another cpu-affinity fix.
Disabled test code that fails to compile on some CPUs with limited
AVX512 capabilities.

https://github.com/JayDDee/cpuminer-opt/releases/tag/v3.9.2.3

Ooops, that code is supposed to bre turned off in the field. It appears your CPU has some limited AVX512
capabilities, but not enough for my test code. It also shows my test code did not screen properly for
the correct features. But as I said that code should never have been enabled in the release.

A small code edit in avxdefs.h will fix that. Find the follwing code near the bottom of the file and
change "#if 1" to "#if 0". It'll be fixed in the next release.

I may have introduced a regression to cpu-affinity affecting Linux. Linux can support
up to 128 CPUs by using a 128 bit mask. Support for 128 bit integers is very limited
with no way to enter a 128 bit number on the command line.

As a result I replicated the 64 bit mask entered on the command line to the upper half of
the 128 bit mask resulting in a symetrical 128 bit mask.

The problem is I did this even when there are fewer than 64 CPUs available resulting in an
invalid mask. It will be ignored because it has bits set that don't have a matching CPU.
 
I will make a change in the next release to only replicate the lower 64 bits of the mask
if there are more than 64 CPUs.

cpuminer-opt-3.9.2.2

Fixed some day 1 cpu-affinity issues.

https://github.com/JayDDee/cpuminer-opt/releases/tag/v3.9.2.2

My plan for the opt_affinity option when it is int128 is to replicate the command line 64 bit mask to the
upper 64 bits of opt-affinity. The debug output will use a union overlay to display int128  as 2 int64.
This might allow specifying affinity with more than 64 cpus on linux.

EDIT:

It's looking good. I'm able to do some basic arithmetic with __int128, in particular I can shift 64 bits
so I can easilly extract both halves for 64 bit formatting. Didn't have to use a union. My testing
capabilities are limited without a >64 core cpu bt I was able to see a correctly formed 128 bit
affinity mask.

I won't try handling the 128 bit affinity yet for big cpus on linux, I want this change to soak first.

I was wondering about  that when I saw it but hadn't followed up (too much multitasking).

I think I found the problem, it's day 1. The argument to SetThreadAffinityMask is supposed to be DWORD_PTR,
not a DWORD, so "&affinity_mask" instead of "affinity_mask". It supports 64 CPU by casting the pointer as DWORD64_ptr.

It's all clear now. Thanks for your persistence.

Interesting, the errors occurred even with a default affinity. I looked deeper and discovered the mask
on Windows is only 32 bits as you suspected. I don't know how it's supposed to support 64 CPUs
with only a 32 bit mask.

With groups enabled the mask is of type KAFFINITY and a member of a struct that also include group info.
KAFFINITY was described as a bit mask to set affinity of "one or more" cpus in a group but doesn't specify
a maximum or further define KAFFINITY.

Maybe you should enable CPU-groups, but cpuminer-opt needs a custom build to use it.

cpuminer-opt-3.9.2

https://github.com/JayDDee/cpuminer-opt/releases/tag/v3.9.2

Added sha256q algo.
Yespower now uses openssl SHA256, but no observable hash rate increase
on Ryzen.
Ongoing rearchitecting.
Lyra2z now hashes 8-way on CPUs with AVX2.
Lyra2 (all including phi2) now runs optimized code with SSE2.

The best advice for complex system architectures is probably to run seperate instances of the miner
for differnt CPU groups, NUMAs, whatever other scaling and partitioning features Windows has.

Your still jumping ahead. What about defaults? I need to underestand how it works with defaults
before you throw this other stuff at me.

Your CPU has 14/28 cores/threads but you didn't say you had 4 of them.
So now I have a clue what error 57 means, one more than the number of cpus.
It suggests that it was attempting to affine beyond 56.

The change to support CPU groups in v3.9 resulted in using different Windows functions for
counting the number of CPUs and setting the affinity. This appears to be a Windows
specific problem as Linux affinity works up to 64 CPUs and is ignored with more than 64
CPUs.

Edit: I took another look at the code changes and there should be no difference if cpu groups
is not enabled. A change in behaviour means it's running different code. But if it was running
the new code the "Binding thread" message would have included the group. I don't know what's
going on.

You can still have cpu groups with fewer than 64 cpus.
 

This statement caught my attention. The binaries are cross-compiled with GCC in a mingw environment
runing on Linux. What are you referring to that is better?

What is confusing me is all your changes from the norm. I would like to see how it works
with defaults to get a reference. I also don't know what you mean by truncating to 32,
affinity is 64 bits. and you don't have more than 32 CPUs anyway.

I don't know the case you posted  but there were errors


repeated for many CPUs, seems to be all the odd numbered ones.

EDIT:

I can't find what error 57 means.

Some useful tests, you don't have to post the session just whether it worked as expected.
Running less than N threads should be by factors of 2. Anything else is YMMV.
And forcing the process affinity disqualifies everything.

1. All defaults

2. 14 threads default affinity, note wether cpu loads are balanced, ie affinity was properly
distributed.

3. If unbalanced try setting affinity 0x5555555 or  0xaaaaaaa

If everything works as expected I don't see a problem. Windows issues like CPU groups and
NUMA shouldn't be an issue until you get over 64 CPUs.

A few points. and questions:

What's your CPU and OS?

Summary: Changes were made to support Windows CPU groups
                 There have been no changes to yescrypt code.
                 There have been no recent changes to Windows buld process

Edit: please use -D to display affinity debug info.

Long version:

CPU limit and affinity:
A change was made initially in 3.9.0, later tweaked to add CPU groups support to Windows.
This may be responsible for that issue. I can have a look at the code in light of the specific symtoms you saw.
Do you use CPU groups? Which version of Windows? You said you affine the process seperately and that
causes problems. That could be related to CPU groups if the process is in a different group from the miner
threads.

General performance degredation:
The binaries are still made the same way using mingw,specifically using the winbuild-cross.sh script.
The compiler was upgraded (evident in the startup messages showing the compiler version) prior
to 3.9.
However, I have been making some architectural changes that may have a small impact on performance,
though 5% seems a bit much. I'm making them due to issues in preparation for AVX512 where
up to 16 lanes can run parallel in a single CPU tread. The overhead for interleaving and deinterleaving the data,
the increase in memory usage, etc, don't scale well.

Some of those changes affect the locally displayed hashrate, both in volume of thread hash reports and
their values. I have reduced the latency between detecting a solution and submitting it to the pool. As
a side effect there are fewer hash meter reports and the reported hashrate is actually from the previous
block. Another side effect is the reduced latency is not reflected in the hash rate reported by the miner.
I considered it an acceptible compromise as it's just optics. The acumulated share difficulty over time is
what the pool uses. In both the miner and the pool the hashrate is an artificial metric.
The changes result in less deinterleaving of final hash (check for solution before interleaving instead of
after), and submitting a share immediately when found while continuing the scan instead of aborting the scan
to submit the share an start a new scan. On their face it is obviously more efficient but I measured no
discernable difference in reprted hash rate.
These changes are being migrated slowly and can be confirmed by a more detailed share submitted message
indicating which thread and lane found the solution.

Sorry for the ramble but there's a lot going on at the same time. I appreciate the testing and reports of any deviations
from previous versions, especially the unintended ones.