Cool VL Viewer forum

Hi Henri,

i ported the Linux thread affinity code to the equivalent Windows code. It is mostly a simple 1:1 port.

Greetings, Kathrine

I already had a look at affinity for Windows. Sadly, it does not work like under Linux. Under Linux, you can set the main thread (process) affinity, e.g. to cores 0 and 1 and child threads affinity to cores 2 to 8. This allows to ensure that child threads won't consume processing time on the cores the main thread (and renderer, for the viewer) is running; this is the whole point of this feature as I implemented it.

Under Windows, however, the child threads of a process can only have their affinity set to a sub-set of the process affinity. E.g. a process could have its affinity set to cores 0 to 8, and child threads only to cores 2 to 8; but as you can see, it won't prevent the main thread to be scheduled on the same cores as the child threads... Or at least, this is how I understand the SetThreadAffinityMask() documentation, and especially:
This means that this feature is not adapted to Windows' scheduler (neither to macOS', that, AFAIK, does not even have any system call to set threads or processes affinity)...

Not really. Windows just has a slightly different API for affinity.

The Windows API works exactly like the Linux one in that respect. The main difference is how the schedulers distribute the threads when Hyperthreading is active.

You get the Process Affinity Mask, which is "all available cores" by default. So if you do nothing, the threads will be scheduled on all cores of the machine.
This is the same as the default "cpuset" on Linux (https://man7.org/linux/man-pages/man7/cpuset.7.html).
Now you can set the Thread Affinity Mask to control the distribution of threads on the available cores. The main threads affinity mask isn't the same as the process affinity mask.

(see for example: https://stackoverflow.com/questions/248 ... and-openmp )

There are some extra complexities with Processor Groups, NUMA and core topology in multi-socket systems or when more than 64-cores are involved, but for the basic Thread Affinity mask it doesn't matter.

It seems to work properly, when i lookup the best core in Ryzen Master, then set a MainThreadAffinity Mask for the 2 best HT cores. Checking with Process Explorer, the load stays on the selected CPUs as expected and the threads do not migrate away. Could add a few asserts to be sure the main threads stay on the assigned CPUs and to make sure the other threads never go there... (https://docs.microsoft.com/en-us/window ... ornumberex )

Ah... That would indeed be a game changer... The documentation is very confusing for a Linux developer (where a process and the main thread of that process are in actuality the same things: for Linux, each thread is just another (lightweight) process, the secondary threads/lightweight processes simply being parented to the main thread/process), that is you cannot, under Linux, differentiate the "process" from the "main thread"...

It won't help/be desirable for a release build, but if you can find the time to experience it with an llassert_always(), it would be an interesting confirmation that your interpretation of M$ documentation is the right one. I would be especially worried that the main thread could be scheduled on the child threads reserved cores (largely defeating the purpose of this feature)...

FYI, with the new threaded GL worker (which I also made multi-threaded instead of just mono-threaded), I did more work on affinity setting (I spotted the HttpThread thread affinity, for example, which I so far did not set), so to move more threads away from the main thread/renderer cores; the benefit of the affinity setting should be even more obvious with the upcoming releases.

Feature included in today's releases.