Go 计算虚拟核心，而不是物理核心？

Question

我有一些 Go 代码在我的 Macbook（具有两个物理内核的 Intel Core i5 处理器）上进行基准测试。

Go 的runtime.NumCPU()产量为 4，因为它计算“虚拟核心”

在这种情况下，我对虚拟内核了解不多，但我的基准测试似乎表明，当我使用配置代码时，多处理速度只有 2 倍

runtime.GOMAXPROCS(runtime.NumCPU())

如果我使用 2 个而不是 4 个内核，我将获得相同的性能。我会发布代码，但我认为这在很大程度上与我的问题无关，这些问题是：

1）这是正常的吗？

2）如果是的话，为什么多个虚拟内核会使像我的macbook这样的机器受益？

更新：

万一这很重要，在我的代码中，goroutines 的数量与你设置runtime.GOMAXPROCS() 的任务是完全并行的，没有相互依赖关系或共享状态。它作为本机编译的二进制文件运行。

Answer 1

1）这是正常的吗？如果您的意思是虚拟内核出现在 中runtime.NumCPU()，那么是的，至少在某种意义上，用 C 编写的程序以及在其他运行时（如 JVM）上运行的程序将看到相同数量的 CPU。如果您指的是性能，请参见下文。2）如果是的话，为什么多个虚拟内核会使像我的macbook这样的机器受益？这是一个复杂的问题，取决于工作量。最能体现其优势的工作负载通常是高度并行的，例如 3D 渲染和某些类型的数据压缩。在其他工作负载中，这些好处可能不存在，并且 HT 对性能的影响可能是负面的（由于运行更多线程的通信和上下文切换开销）。阅读关于超线程的维基百科文章可以进一步阐明这个问题。这是一个示例基准测试，它比较了具有和不具有 HT 的相同 CPU 的性能。请注意，HT 并不总是提高性能，在某些情况下，实际上会降低性能。