Go counts virtual cores, not physical?

Question

I have some Go code I am benchmarking on my Macbook (Intel Core i5 processor with two physical cores).

Go's runtime.NumCPU() yields 4, because it counts "virtual cores"

I don't know much about virtual cores in this context, but my benchmarks seems to indicate a multiprocessing speedup of only 2x when I configure my code using

runtime.GOMAXPROCS(runtime.NumCPU())

I get the same performance if I use 2 instead of 4 cores. I would post the code, but I think it's largely irrelevant to my questions, which are:

1) is this normal?

2) why, if it is, do multiple virtual cores benefit a machine like my macbook?

Update:

In case it matters, in my code, there are the same number of goroutines as whatever you set runtime.GOMAXPROCS() the tasks are fully parallel, have no interdependencies or shared state. its running as a native compiled binary.

Answer 1

1) is this normal?

If you mean the virtual cores showing up in runtime.NumCPU(), then yes, at least in the sense that programs written in C as well as those running on top of other runtimes like the JVM will see the same number of CPUs. If you mean the performance, see below.

2) why, if it is, do multiple virtual cores benefit a machine like my macbook?

It's a complicated matter that depends on the workload. The workloads where its benefits show the most are typically highly parallel like 3D rendering and certain kinds of data compression. In other workloads, the benefits may be absent and the impact of HT on performance may be negative (due to the communication and context-switching overhead of running more threads). Reading the Wikipedia article on hyper-threading can elucidate the matter further.

Here is a sample benchmark that compares the performance of the same CPU with and without HT. Note how the performance is not always improved by HT and in some cases, in fact, decreases.