Detect number of cores better on multi-socket systems#6108
Open
rimrul wants to merge 2 commits intogit-for-windows:mainfrom
Open
Detect number of cores better on multi-socket systems#6108rimrul wants to merge 2 commits intogit-for-windows:mainfrom
rimrul wants to merge 2 commits intogit-for-windows:mainfrom
Conversation
Git for Windows doesn't support anything prior to Windows 8.1 since 2.47.0 and Git followed along with commits like ce6ccba (mingw: drop Windows 7-specific work-around, 2025-08-04). There is no need to pretend to the compiler that we still support Windows Vista, just to lock us out of easy access to newer APIs. There is also no need to have conflicting and unused definitions claiming we support some versions of Windows XP or even Windows NT 4.0. Bump all definitions of _WIN32_WINNT to a realistic value of Windows 8.1. This will also simplify code for a followup commit that will improve cpu core detection on multi-socket systems. Signed-off-by: Matthias Aßhauer <mha1993@live.de>
While the currently used way to detect the number of CPU cores on Windows is nice and straight-forward, GetSystemInfo() only gives us access to the number of processors within the current group. [1] While that is usually fine for systems with a single physical CPU, separate physical sockets are typically separate groups. Switch to using GetLogicalProcessorInformationEx() to handle multi-socket systems better. [1] https://learn.microsoft.com/en-us/windows/win32/api/sysinfoapi/ns-sysinfoapi-system_info#members This fixes git-for-windows#4766 Co-Authored-by: Herman Semenov <GermanAizek@yandex.ru> Signed-off-by: Matthias Aßhauer <mha1993@live.de>
dscho
approved these changes
Feb 22, 2026
Member
dscho
left a comment
dscho
left a comment
There was a problem hiding this comment.
Nice! I have no way of testing this, that's why it's extra nice that you can confirm that this works as advertised.
dscho
added a commit
that referenced
this pull request
Apr 6, 2026
1edeb9a (Win32: warn if the console font doesn't support Unicode, 2014-06-10) introduced both code to detect the current console font on Windows Vista and newer and a fallback for older systems to detect the default console font and issue a warning if that font doesn't support unicode. Since we haven't supported any Windows older than Vista in almost a decade, we don't need to keep the workaround. This more or less fell out of #6108, but didn't quite fit into that PR. There are also some other version specific hacks and workarounds I considered dropping, but decided against: * 492f709 * I'm unsure if this regression has ever been fixed or just become the new normal. * #5042 * So far this hasn't been an issue on Windows 8.1, but officially Go 1.21 and newer only support Windows 10 and newer. So this might become a problem at any point.
Member
Author
|
I have tested that I get the expected numbers out of
|
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
While the currently used way to detect the number of CPU cores ond
Windows is nice and straight-forward, GetSystemInfo() only gives us
access to the number of processors within the current group.
While that is usually fine for systems with a single physical CPU,
separate physical sockets are typically separate groups.
Switch to using GetLogicalProcessorInformationEx() to handle multi-socket
systems better.
I've tested this on a physical single-socket x86-64 and a physical dual-socket x86-64 system, and on a virtual single-socket ARM64 system. Physical multi-socket ARM64 systems seem to exist, but I don't have access to such hardware and the hypervisor I use apparently can't emulate that either.