Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

C#, Environment.PhysicalCoreCount #111173

Open
vsfeedback opened this issue Jan 7, 2025 · 1 comment
Open

C#, Environment.PhysicalCoreCount #111173

vsfeedback opened this issue Jan 7, 2025 · 1 comment
Labels
api-suggestion Early API idea and discussion, it is NOT ready for implementation area-System.Threading untriaged New issue has not been triaged by the area owner

Comments

@vsfeedback
Copy link

This issue has been moved from a ticket on Developer Community.


Currently, Environment.ProcessorCount provides the total number of logical threads, which has been useful in processors leveraging technologies like SMT (Simultaneous Multithreading). However, this approach has limitations because, in SMT configurations, only one thread per core is truly executed simultaneously, while the second thread is only used when the first thread is idle. This can lead to worse performance in intensive parallel loops (such as those using native memory and pointers) when attempting to use all logical threads without effectively leveraging hardware resources.

Until now, dividing Environment.ProcessorCount by 2 was a common practice to estimate the number of physical cores. However, this solution is no longer valid with newer processors that do not implement SMT, such as some recent Intel and Apple models. In these cases, continuing to divide by 2 would result in a significant waste of resources by ignoring half of the available physical cores.

For this reason, it is crucial for C# to offer a native API to directly retrieve the number of physical cores, something like Environment.PhysicalCoreCount. This would avoid the current limitations and ensure a reliable, cross-platform, and native way to access this information without relying on operating system calls.

Additionally, it is important to revisit how C# parallel loops handle scenarios on heterogeneous processors, i.e., those combining high-performance cores (P-cores) and high-efficiency cores (E-cores), as seen in modern hybrid architectures. In such cases, the performance of parallel loops can degrade significantly if the unequal performance of the cores is not accounted for. A potential solution could involve dynamically adjusting the workload based on the relative performance of each core.

These improvements would not only benefit high-performance scenarios but also simplify the development of applications that need to optimally utilize underlying hardware in modern and heterogeneous configurations.


Original Comments

Feedback Bot on 12/2/2024, 09:22 PM:

Thank you for taking the time to provide your suggestion. We will do some preliminary checks to make sure we can proceed further. You will hear from us in about a week on our next steps.

@dotnet-issue-labeler dotnet-issue-labeler bot added the needs-area-label An area label is needed to ensure this gets routed to the appropriate area owners label Jan 7, 2025
@dotnet-policy-service dotnet-policy-service bot added the untriaged New issue has not been triaged by the area owner label Jan 7, 2025
@jkotas jkotas added area-System.Threading and removed needs-area-label An area label is needed to ensure this gets routed to the appropriate area owners labels Jan 7, 2025
Copy link
Contributor

Tagging subscribers to this area: @mangod9
See info in area-owners.md if you want to be subscribed.

@vcsjones vcsjones added the api-suggestion Early API idea and discussion, it is NOT ready for implementation label Jan 7, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
api-suggestion Early API idea and discussion, it is NOT ready for implementation area-System.Threading untriaged New issue has not been triaged by the area owner
Projects
None yet
Development

No branches or pull requests

3 participants