Detect number of cores better on multi-socket systems#6108
Merged
dscho merged 2 commits intogit-for-windows:mainfrom Apr 6, 2026
Merged
Detect number of cores better on multi-socket systems#6108dscho merged 2 commits intogit-for-windows:mainfrom
dscho merged 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 <[email protected]>
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 <[email protected]> Signed-off-by: Matthias Aßhauer <[email protected]>
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
|
Member
Excellent! Let's merge it. |
Member
|
/add relnote bug The number of CPU cores is now detected correctly on multi-socket systems. The workflow run was started |
github-actions bot
pushed a commit
to git-for-windows/build-extra
that referenced
this pull request
Apr 6, 2026
The number of CPU cores is [now detected correctly](git-for-windows/git#6108) on multi-socket systems. Signed-off-by: gitforwindowshelper[bot] <[email protected]>
gitforwindowshelper bot
pushed a commit
that referenced
this pull request
Apr 7, 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.
gitforwindowshelper bot
pushed a commit
that referenced
this pull request
Apr 7, 2026
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.](https://learn.microsoft.com/en-us/windows/win32/api/sysinfoapi/ns-sysinfoapi-system_info#members) 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](https://cloudbase.it/ampere-altra-industry-leading-arm64-server/), but I don't have access to such hardware and the hypervisor I use apparently can't emulate that either.
gitforwindowshelper bot
pushed a commit
that referenced
this pull request
Apr 7, 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.
gitforwindowshelper bot
pushed a commit
that referenced
this pull request
Apr 7, 2026
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.](https://learn.microsoft.com/en-us/windows/win32/api/sysinfoapi/ns-sysinfoapi-system_info#members) 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](https://cloudbase.it/ampere-altra-industry-leading-arm64-server/), but I don't have access to such hardware and the hypervisor I use apparently can't emulate that either.
gitforwindowshelper bot
pushed a commit
to git-for-windows/shears-builds
that referenced
this pull request
Apr 7, 2026
…s#6108) 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.](https://learn.microsoft.com/en-us/windows/win32/api/sysinfoapi/ns-sysinfoapi-system_info#members) 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](https://cloudbase.it/ampere-altra-industry-leading-arm64-server/), but I don't have access to such hardware and the hypervisor I use apparently can't emulate that either.
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.