5

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.

Jonathan Hall
  • 75,165
  • 16
  • 143
  • 189
domoarigato
  • 2,802
  • 4
  • 24
  • 41
  • There are a lot of unknowns from my perspective here. How many go routines are you running concurrently? Is Hyper threading switched on in your BIOS? Are you running in a Virtual Machine on your Mac? By the way, a Hyperthreaded core isn't a real core, it's just clever instruction scheduling which allows another thread of execution to run concurrently during idle states of the other program running on the same CPU core. – KRK Owner Jun 12 '16 at 19:42

1 Answers1

7

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.

Community
  • 1
  • 1
nwk
  • 4,004
  • 1
  • 21
  • 22
  • 3
    The point of having these virtual cores is that while one task is stalled (waiting on main memory or something slow like floating-point division, say), the CPU can try to sneak in work on another. Whether it helps depends partly on whether your code has those long stalls (like, adding a long stream of numbers probably won't) and whether the other thread really uses complementary CPU resources (e.g. a load of all floating-point divisions on all threads may be limited by your cores' physical dividers, HT or no). – twotwotwo Jun 12 '16 at 20:17
  • 2
    As another example of how it's super workload-dependent, there's a benchmark on a database workload where it averages a 24% gain, but less or much more depending on the query: http://sqlblog.com/blogs/joe_chang/archive/2013/04/08/hyper-threading-performance.aspx – twotwotwo Jun 12 '16 at 20:18