4 ms·
Just run 2 Windows instances. Problem solved.
by anticensor 8y ago
Just run 2 Windows instances. Problem solved.
- blattimwind 8y agoWindows can use more than 64 hardware threads, but a single process kinda can't.
- anticensor 8y ago[dropped]
- quotemstr 8y agoNo, it most definitely is not.
- deleted 8y ago[deleted]
- bhengaij 8y agoNo such inherent limitation on windows
- bluecalm 8y agoIt 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.
- zamadatix 8y agoBut 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.
- mehrdadn 8y agoI think it can? https://msdn.microsoft.com/en-us/library/windows/desktop/dd405516.aspx https://msdn.microsoft.com/en-us/library/windows/desktop/dd4...
- monocasa 8y agoThe KAFFITY in the GROUP_AFFINITY struct is a bitmap ULONG, so 64 bits on 64 bit archs, and 32 bits on 32 bit archs.
- mehrdadn 8y agoYes but that means every group is 64 CPUs. Notice you can set affinity for any group (16-bit index).
- psyq321 8y agoYes, 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.
- monocasa 8y agoBut 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.
- mehrdadn 8y agoHuh, 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?