我想检测实际物理核心的数量，而不是逻辑核心的数量，因为当更多线程竞争私有每核心缓存时，工作负载会出现负扩展，和/或具有足够高的 IPC，每个核心运行多个逻辑线程不会出现这种情况。吞吐量的增加不会超过线程开销的增加，特别是对于无法完美扩展到大量内核的问题。
或者换句话说，在没有任何线程相互竞争执行资源（内存带宽除外）的情况下可以运行的线程数量。 （编者注：超线程的一些替代方案，例如 AMD Bulldozer 系列 CMP 有 2 个共享 FPU/SIMD 单元的整数核心；您可能希望根据工作负载将其算作 2 个真正的核心，即使您不希望计算 2 个逻辑核心与 SMT 共享一个物理核心，例如 Intel 的超线程。）
我知道以前曾有人问过类似的问题，但答案看起来已经过时了。 或者“获取物理处理器计数 .NET Core 2.2”没有得到解答，问题中的代码不完全可移植。
System.Environment.ProcessorCount仅返回
逻辑核心的计数，因此我的超线程系统中的数量是双倍的。对于一些密集的并行计算，启动不超过可用的物理内核的线程是最有效的 - 至少我的测试显示，当我启动更多线程时，性能会显着下降。 我发现一些仅限 Windows 的解决方案调用 WMI 或 kernel.dll 来获取物理核心的数量。但是在 .net core 中如何保持平台独立性
呢？是否有隐藏的核心数量或可靠的计算方法？ 到目前为止我发现的最有前途的想法是在一个线程上进行一些较长的计算并测量它的时间。然后并行执行相同的计算（即 ProcessorCount 线程）并测量总时间。比较两次来猜测物理核心的数量。这可能有效，但对我来说看起来成本高昂且不可靠。
不幸的是，我不知道有一个独立于操作系统的库来检索或解析它。我过去曾为雇主编写过一个解析器，尽管与我使用过的许多规范相比，它并不是特别困难，但我不会说它很容易。我必须编写 Linux 和 Windows 版本的代码来获取数据。
所以这并不是真正解决您的问题，而是一条可以为您的问题
制作独立于平台的库的途径。 哦，还有，不要太相信数据。硬件供应商通常不会费心准确地填写所有内容。不过，如果您处理的是真实的物理系统，处理器信息应该是可靠的。