4 ms·
Damn, with 64core/128 threads becoming widely available a lot of Windows software will have to be updated to use that because of "64 bits should be enough for e
by bluecalm 8y ago
Damn, with 64core/128 threads becoming widely available a lot of Windows software will have to be updated to use that because of "64 bits should be enough for everybody" kind of decision in Windows when implementing affinity. You can't get more than 64 threads in OpenMp when compiling with MinGW and you can get it with Clang but the implementation wasn't very efficient when tested it.
I suspect the problem is there in most Windows thread pool implementations.
- anticensor 8y agoJust 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?
- SlowRobotAhead 8y agoLast I saw MS SQL licensing among others like it have a pricing structure per CPU core... That’s going to need to be modified I think!
- adwf 8y agoOracle says "Haha, no."
- astrodust 8y agoOracle says "Looks like our profits will double each time AMD doubles the core count of their flagship chip."
- squarefoot 8y agoPostgreSQL replies "Haha, thanks." :)
- chime 8y agoDoubt they will go away from per core pricing. Most SQL servers are VMs so you can assign as many cores as you want. I do expect them to give bulk pricing for more cores. So 4 core=$x, 16cores=$3x, 64cores=$10x.