[LOCKED] cpuminer-opt v3.12.3, open source optimized multi-algo CPU miner

[4ward]

If they are compiled with MinGW, the performance will be lower. Cross-compile with GCC does a better job optimizing

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?

Right, I meant that cross compile is faster than using Cygwin on Windows. Not MinGW... Mixed them up ))

[joblo]

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

Code:

affine_to_cpu_mask for 1 returned 57

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.

There are more than 32 CPUs (check the debug above: 56 CPU cores available, 30 miner threads selected.).
If I select all 28 even CPUs for instance, that means an affinity of 0x55555555555555 which is over 32 bits. If I do set --cpu-affinity=0x55555555555555 , I can check in Task Manager that affinities for CPUs above CPU 31 are not set, which led me to think that affinity is truncating to lower 32 bits.
I do think the warning is just that: a warning, but wanted to be sure as v3.8.8 did not issue such warning before.
And yes, there is no warning issued if I use --cpu-affinity (or don't use it at all) as long as I don't set affinity externally beforehand, so that is not an issue.

EDIT: I made a few tests and verified the following:
* With v3.8.8, a cpu affinity works correctly up to 0xffffff; above that, it triggers that exactly the first 32 CPUs are used, no matter the value.
* With v3.9.1.1, a cpu affinity works correctly up to 0xf; above that, it triggers that exactly the first 32 CPUs are used, no matter the value.
I verified this by using the CPU affinity option in Task Manager for the miner process.

So the reason I set affinity externally is because I could never rely on the built-in cpu affinity for most miners. It seems to break in some configurations.

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.
 

[malafaya]

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.
 

If I had groups enabled, I would have a combo box like the one in this page. As I don't have it, I suppose I definitely don't have them enabled.
Thanks for analyzing this anyway. I'll still stick to setting affinity externally and ignore the warning.

[joblo]

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.
 

If I had groups enabled, I would have a combo box like the one in this page. As I don't have it, I suppose I definitely don't have them enabled.
Thanks for analyzing this anyway. I'll still stick with setting affinity externally and ignore the warning.

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.

[malafaya]

Does this help?

Not specifying --cpu-affinity:

Code:

[2019-06-04 01:29:03] 56 CPU cores available, 30 miner threads selected.
[2019-06-04 01:29:03] Starting Stratum on stratum+tcp://***
[2019-06-04 01:29:03] Binding thread 0 to cpu 0 (mask 1)
[2019-06-04 01:29:03] Binding thread 14 to cpu 14 (mask 4000)
[2019-06-04 01:29:03] Binding thread 9 to cpu 9 (mask 200)
[2019-06-04 01:29:03] affine_to_cpu_mask for 9 returned 57
[2019-06-04 01:29:03] Binding thread 4 to cpu 4 (mask 10)
[2019-06-04 01:29:03] Binding thread 18 to cpu 18 (mask 40000)
[2019-06-04 01:29:03] Binding thread 7 to cpu 7 (mask 80)
[2019-06-04 01:29:03] affine_to_cpu_mask for 7 returned 57
[2019-06-04 01:29:03] 30 miner threads started, using 'yescrypt' algorithm.
[2019-06-04 01:29:03] Binding thread 22 to cpu 22 (mask 400000)
[2019-06-04 01:29:03] Binding thread 6 to cpu 6 (mask 40)
[2019-06-04 01:29:03] Binding thread 2 to cpu 2 (mask 4)
[2019-06-04 01:29:03] Binding thread 11 to cpu 11 (mask 800)
[2019-06-04 01:29:03] affine_to_cpu_mask for 11 returned 57
[2019-06-04 01:29:03] Binding thread 8 to cpu 8 (mask 100)
[...]

Specifying --cpu-affinity=0xd555555d555555:

Code:

[2019-06-04 01:30:37] 56 CPU cores available, 30 miner threads selected.
[2019-06-04 01:30:37] Starting Stratum on stratum+tcp://***
[2019-06-04 01:30:37] Binding thread 0 to cpu mask 35ffbe0
[2019-06-04 01:30:37] Binding thread 7 to cpu mask 43ffbe0
[2019-06-04 01:30:37] Binding thread 9 to cpu mask 47ffbe0
[2019-06-04 01:30:37] Binding thread 10 to cpu mask 49ffbe0
[2019-06-04 01:30:37] Binding thread 4 to cpu mask 3dffbe0
[2019-06-04 01:30:37] Binding thread 19 to cpu mask 5bffbe0
[2019-06-04 01:30:37] Binding thread 6 to cpu mask 41ffbe0
[2019-06-04 01:30:37] 30 miner threads started, using 'yescrypt' algorithm.
[2019-06-04 01:30:37] Binding thread 1 to cpu mask 37ffbe0
[2019-06-04 01:30:37] Binding thread 8 to cpu mask 45ffbe0
[2019-06-04 01:30:37] Binding thread 2 to cpu mask 39ffbe0
[2019-06-04 01:30:37] Binding thread 11 to cpu mask 4bffbe0
[2019-06-04 01:30:37] Binding thread 12 to cpu mask 4dffbe0
[2019-06-04 01:30:37] Binding thread 13 to cpu mask 4fffbe0
[2019-06-04 01:30:37] Binding thread 3 to cpu mask 3bffbe0
[...]

Those CPU masks become quite weird with --cpu-affinity. And in the end, it's actually bound to CPUs 0-31.

[joblo]

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.

[joblo]

Does this help?

Those CPU masks become quite weird with --cpu-affinity. And in the end, it's actually bound to CPUs 0-31.

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.

[malafaya]

Does this help?

Those CPU masks become quite weird with --cpu-affinity. And in the end, it's actually bound to CPUs 0-31.

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.

Hmmm, that seems to be different between Win32 and Win64: https://stackoverflow.com/questions/10877182/getprocessaffinitymask-returns-processaffinty-and-systemaffinity-as-1-overflow. The parameter seems to be 64 bit under Win64 despite their deceiving name (type DWORD64...).

Code:

typedef unsigned __int64 DWORD64, *PDWORD64;

EDIT: https://docs.microsoft.com/en-us/windows-hardware/drivers/kernel/interrupt-affinity-and-priority#about-kaffinity: "The KAFFINITY type is 32 bits on a 32-bit version of Windows and is 64 bits on a 64-bit version of Windows."

[malafaya]

I tried using --cpu-affinity=0x3 in another computer (laptop) without setting affinity externally. Results are similarly problematic:

Code:

         **********  cpuminer-opt 3.9.2  ***********
     A CPU miner with multi algo support and optimized for CPUs
     with AES_NI and AVX2 and SHA extensions.
     BTC donation address: 12tdvfF7KmAsihBXQXynT6E6th2c2pByTT

CPU: Intel(R) Core(TM) i7-6600U CPU @ 2.60GHz.
SW built on Jun  3 2019 with GCC 7.3.0.
CPU features: SSE2 AES SSE4.2 AVX AVX2.
SW features: SSE2 AES SSE4.2 AVX AVX2.
Algo features: SSE2.
Start mining with SSE2.

[2019-06-04 14:17:20] 4 CPU cores available, 2 miner threads selected.
[2019-06-04 14:17:20] Binding process to cpu mask a5fce0
****** [2019-06-04 14:17:20] affine_to_cpu_mask for 4294967295 returned 57 ********
[2019-06-04 14:17:20] 2 miner threads started, using 'yespower' algorithm.
[2019-06-04 14:17:20] Starting Stratum on stratum+tcp://******
[2019-06-04 14:17:20] Binding thread 0 to cpu mask 32cfbe0
[2019-06-04 14:17:20] Binding thread 1 to cpu mask 34cfbe0
[2019-06-04 14:17:20] Stratum session id: 725103584be7a27346f921881f5ac7d8
[2019-06-04 14:17:20] Stratum difficulty set to 1

This "Binding process to cpu mask a5fce0" seems to occur in every machine, no matter how many CPUs it's got: it's always a5fce0.
Also, a quick look at the process affinity in Task Manager and I see all 4 CPUs affined, instead of just the first 2.

[joblo]

I tried using --cpu-affinity=0x3 in another computer (laptop) without setting affinity externally. Results are similarly problematic:

Code:

         **********  cpuminer-opt 3.9.2  ***********
     A CPU miner with multi algo support and optimized for CPUs
     with AES_NI and AVX2 and SHA extensions.
     BTC donation address: 12tdvfF7KmAsihBXQXynT6E6th2c2pByTT

CPU: Intel(R) Core(TM) i7-6600U CPU @ 2.60GHz.
SW built on Jun  3 2019 with GCC 7.3.0.
CPU features: SSE2 AES SSE4.2 AVX AVX2.
SW features: SSE2 AES SSE4.2 AVX AVX2.
Algo features: SSE2.
Start mining with SSE2.

[2019-06-04 14:17:20] 4 CPU cores available, 2 miner threads selected.
[2019-06-04 14:17:20] Binding process to cpu mask a5fce0
****** [2019-06-04 14:17:20] affine_to_cpu_mask for 4294967295 returned 57 ********
[2019-06-04 14:17:20] 2 miner threads started, using 'yespower' algorithm.
[2019-06-04 14:17:20] Starting Stratum on stratum+tcp://******
[2019-06-04 14:17:20] Binding thread 0 to cpu mask 32cfbe0
[2019-06-04 14:17:20] Binding thread 1 to cpu mask 34cfbe0
[2019-06-04 14:17:20] Stratum session id: 725103584be7a27346f921881f5ac7d8
[2019-06-04 14:17:20] Stratum difficulty set to 1

This "Binding process to cpu mask a5fce0" seems to occur in every machine, no matter how many CPUs it's got: it's always a5fce0.
Also, a quick look at the process affinity in Task Manager and I see all 4 CPUs affined, instead of just the first 2.

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.

[malafaya]

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.

Thank YOU for all your hard work.

[joblo]

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.

Thank YOU for all your hard work.

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.

[joblo]

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

[joblo]

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

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.

[p2501]

Hello,

I'm getting the following since version 3.9.1.1 on a Xeon D-2141I CPU while compiling with gcc 6.3.0 under a debian system

In file included from algo-gate-api.h:5:0,
                 from util.c:48:
avxdefs.h: In function ‘avx512_compile_test’:
In file included from algo-gate-api.h:5:0,
                 from cpu-miner.c:64:
avxdefs.h: In function ‘avx512_compile_test’:
avxdefs.h:2035:7: warning: implicit declaration of function ‘mm256_rorv_16’ [-Wimplicit-function-declaration]
   y = mm256_rorv_16( y, 3 );
       ^~~~~~~~~~~~~
avxdefs.h:2035:7: warning: implicit declaration of function ‘mm256_rorv_16’ [-Wimplicit-function-declaration]
   y = mm256_rorv_16( y, 3 );
       ^~~~~~~~~~~~~
avxdefs.h:2035:5: error: incompatible types when assigning to type ‘__m256i {aka __vector(4) long long int}’ from type ‘int’
   y = mm256_rorv_16( y, 3 );
     ^
avxdefs.h:2036:7: warning: implicit declaration of function ‘mm256_ror_1x16’ [-Wimplicit-function-declaration]
   y = mm256_ror_1x16( y );
       ^~~~~~~~~~~~~~
avxdefs.h:2035:5: error: incompatible types when assigning to type ‘__m256i {aka __vector(4) long long int}’ from type ‘int’
   y = mm256_rorv_16( y, 3 );
     ^
avxdefs.h:2036:5: error: incompatible types when assigning to type ‘__m256i {aka __vector(4) long long int}’ from type ‘int’
   y = mm256_ror_1x16( y );
     ^
avxdefs.h:2036:7: warning: implicit declaration of function ‘mm256_ror_1x16’ [-Wimplicit-function-declaration]
   y = mm256_ror_1x16( y );
       ^~~~~~~~~~~~~~
avxdefs.h:2036:5: error: incompatible types when assigning to type ‘__m256i {aka __vector(4) long long int}’ from type ‘int’
   y = mm256_ror_1x16( y );
     ^

and later on
In file included from algo-gate-api.h:5:0,
                 from algo-gate-api.c:20:
avxdefs.h: In function ‘avx512_compile_test’:
avxdefs.h:2035:7: warning: implicit declaration of function ‘mm256_rorv_16’ [-Wimplicit-function-declaration]
   y = mm256_rorv_16( y, 3 );
       ^~~~~~~~~~~~~
avxdefs.h:2035:5: error: incompatible types when assigning to type ‘__m256i {aka __vector(4) long long int}’ from type ‘int’
   y = mm256_rorv_16( y, 3 );
     ^
avxdefs.h:2036:7: warning: implicit declaration of function ‘mm256_ror_1x16’ [-Wimplicit-function-declaration]
   y = mm256_ror_1x16( y );
       ^~~~~~~~~~~~~~
avxdefs.h:2036:5: error: incompatible types when assigning to type ‘__m256i {aka __vector(4) long long int}’ from type ‘int’
   y = mm256_ror_1x16( y );
     ^

[joblo]

Hello,

I'm getting the following since version 3.9.1.1 on a Xeon D-2141I CPU while compiling with gcc 6.3.0 under a debian system

In file included from algo-gate-api.h:5:0,
                 from util.c:48:
avxdefs.h: In function ‘avx512_compile_test’:

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.

Code:

#if 1
//////////////////////////////////////////////////
//
//   Compile test.
//
//   Code to test that macros compile.

[p2501]

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.

Code:

#if 1
//////////////////////////////////////////////////
//
//   Compile test.
//
//   Code to test that macros compile.

yeap, that did the trick for me.

[joblo]

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

[malafaya]

CPU affinity still does not set correctly in v3.9.2.3. In Task Manager, it seems it still can't affine CPUs above CPU31. Also, some CPUs not specified in the mask are set.

Setting --cpu-affinity=0x55555545555544 with 56 CPUs:

Code:

         **********  cpuminer-opt 3.9.2.3  ***********
     A CPU miner with multi algo support and optimized for CPUs
     with AES_NI and AVX2 and SHA extensions.
     BTC donation address: 12tdvfF7KmAsihBXQXynT6E6th2c2pByTT

CPU: Intel(R) Xeon(R) CPU E5-2660 v4 @ 2.00GHz.
SW built on Jun  5 2019 with GCC 7.3.0.
CPU features: SSE2 AES SSE4.2 AVX AVX2.
SW features: SSE2 AES SSE4.2 AVX AVX2.
Algo features: SSE2.
Start mining with SSE2.

[2019-06-07 10:02:58] 56 CPU cores available, 25 miner threads selected.
[2019-06-07 10:02:58] Starting Stratum on stratum+tcp://***
[2019-06-07 10:02:58] Binding thread 0 to cpu mask ffffffffffffffff ffffffffffffffff
[2019-06-07 10:02:58] affine_to_cpu_mask for 0 returned 57
[2019-06-07 10:02:58] Binding thread 9 to cpu mask ffffffffffffffff fffffffffffffe00
[2019-06-07 10:02:58] affine_to_cpu_mask for 9 returned 57
[2019-06-07 10:02:58] Binding thread 12 to cpu mask ffffffffffffffff fffffffffffff000
[2019-06-07 10:02:58] affine_to_cpu_mask for 12 returned 57
[2019-06-07 10:02:58] Binding thread 18 to cpu mask ffffffffffffffff fffffffffffc0000
[2019-06-07 10:02:58] affine_to_cpu_mask for 18 returned 57
[2019-06-07 10:02:58] Binding thread 20 to cpu mask ffffffffffffffff fffffffffff00000
[2019-06-07 10:02:58] Binding thread 7 to cpu mask ffffffffffffffff ffffffffffffff80
[2019-06-07 10:02:58] affine_to_cpu_mask for 7 returned 57
[2019-06-07 10:02:58] Binding thread 1 to cpu mask ffffffffffffffff fffffffffffffffe
[2019-06-07 10:02:58] affine_to_cpu_mask for 1 returned 57
[2019-06-07 10:02:58] Binding thread 10 to cpu mask ffffffffffffffff fffffffffffffc00
[2019-06-07 10:02:58] affine_to_cpu_mask for 10 returned 57
[2019-06-07 10:02:58] Binding thread 3 to cpu mask ffffffffffffffff fffffffffffffff8
[2019-06-07 10:02:58] affine_to_cpu_mask for 3 returned 57
[2019-06-07 10:02:58] Binding thread 13 to cpu mask ffffffffffffffff ffffffffffffe000
[2019-06-07 10:02:58] affine_to_cpu_mask for 13 returned 57
[2019-06-07 10:02:58] Binding thread 15 to cpu mask ffffffffffffffff ffffffffffff8000
[2019-06-07 10:02:58] affine_to_cpu_mask for 15 returned 57
[2019-06-07 10:02:58] Binding thread 17 to cpu mask ffffffffffffffff fffffffffffe0000
[2019-06-07 10:02:58] affine_to_cpu_mask for 17 returned 57
[2019-06-07 10:02:58] Binding thread 5 to cpu mask ffffffffffffffff ffffffffffffffe0
[2019-06-07 10:02:58] affine_to_cpu_mask for 5 returned 57
[2019-06-07 10:02:58] 25 miner threads started, using 'yespower' algorithm.
[2019-06-07 10:02:58] Binding thread 21 to cpu mask ffffffffffffffff ffffffffffe00000
[2019-06-07 10:02:58] affine_to_cpu_mask for 21 returned 57
[2019-06-07 10:02:58] affine_to_cpu_mask for 20 returned 57
[2019-06-07 10:02:58] Binding thread 8 to cpu mask ffffffffffffffff ffffffffffffff00
[2019-06-07 10:02:58] affine_to_cpu_mask for 8 returned 57
[2019-06-07 10:02:58] Binding thread 23 to cpu mask ffffffffffffffff ffffffffff800000
[2019-06-07 10:02:58] affine_to_cpu_mask for 23 returned 57
[2019-06-07 10:02:58] Binding thread 11 to cpu mask ffffffffffffffff fffffffffffff800
[2019-06-07 10:02:58] affine_to_cpu_mask for 11 returned 57
[2019-06-07 10:02:58] Binding thread 14 to cpu mask ffffffffffffffff ffffffffffffc000
[2019-06-07 10:02:58] affine_to_cpu_mask for 14 returned 57
[2019-06-07 10:02:58] Binding thread 6 to cpu mask ffffffffffffffff ffffffffffffffc0
[2019-06-07 10:02:58] affine_to_cpu_mask for 6 returned 57
[2019-06-07 10:02:58] Binding thread 22 to cpu mask ffffffffffffffff ffffffffffc00000
[2019-06-07 10:02:58] affine_to_cpu_mask for 22 returned 57
[2019-06-07 10:02:58] Binding thread 2 to cpu mask ffffffffffffffff fffffffffffffffc
[2019-06-07 10:02:58] affine_to_cpu_mask for 2 returned 57
[2019-06-07 10:02:58] Binding thread 16 to cpu mask ffffffffffffffff ffffffffffff0000
[2019-06-07 10:02:58] affine_to_cpu_mask for 16 returned 57
[2019-06-07 10:02:58] Binding thread 24 to cpu mask ffffffffffffffff ffffffffff000000
[2019-06-07 10:02:58] affine_to_cpu_mask for 24 returned 57
[2019-06-07 10:02:58] Binding thread 19 to cpu mask ffffffffffffffff fffffffffff80000
[2019-06-07 10:02:58] affine_to_cpu_mask for 19 returned 57
[2019-06-07 10:02:58] Binding thread 4 to cpu mask ffffffffffffffff fffffffffffffff0
[2019-06-07 10:02:58] affine_to_cpu_mask for 4 returned 57
[2019-06-07 10:02:59] Stratum session id: 2cd01d0b28be7edd72b3b4e03ce04797

[joblo]

CPU affinity still does not set correctly in v3.9.2.3. In Task Manager, it seems it still can't affine CPUs above CPU31. Also, some CPUs not specified in the mask are set.

Setting --cpu-affinity=0x55555545555544 with 56 CPUs:

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..