I think it can? https://msdn.microsoft.com/en-us/library/windows/desktop/dd4...

The KAFFITY in the GROUP_AFFINITY struct is a bitmap ULONG, so 64 bits on 64 bit archs, and 32 bits on 32 bit archs.

Yes but that means every group is 64 CPUs. Notice you can set affinity for any group (16-bit index).

Yes, starting from Windows 7 / Server 2008 R2 it is possible to support more than 64 CPUs within a single process by using new Win32 APIs supporting processor groups. You'd need to manually set the affinities for the threads, but after that you are all set.

Unfortunately, unaware (legacy) software is still limited to 64 processors.

But AFAIK, if I have 128 logical cores, I can't say "schedule this thread on any of the 128 cores because you as the scheduler should know better than me". You have to manually manage the two thread groups each of 64 cores because new threads are round robin assigned to the two groups on thread creation and aren't migrated as circumstances change.

Huh, I don't really know much about this to be honest, but are you sure that's not a consequence of prefering not to migrate threads across NUMA nodes rather than across thread groups? Are you aware if there's any documentation on the behavior you're mentioning?

Oof, I hadn't read the whole page. Interesting, thanks!

It can but you have to take care too change process affinity groups every time you want to work with threads in another group as a group is limited to 64 virtual cores. It complicates thread pool implementation significantly.

But bringing it back to the parent comment thread it's easier to manage affinity of your processes than it is to synchronize them across multiple OS instances.

No such inherent limitation on windows

[dropped]

No, it most definitely is not.