使用GOMAXPROCS进行并行编程

Question

I have seen people setting runtime.GOMAXPROCS to runtime.NumCPU() to enable parallel processing in go. Official documentation doesn't say anything about the upper bound of GOMAXPROCS; can I set this to any arbitrary positive integer or should it always be less than eq. to NumCPU value?

I tried setting it to a number that's greater than the # of logical cores, my code works just fine

Answer 1

The max is 256; but note, it will not error if you set it higher.

https://golang.org/src/runtime/debug.go?s=534:560#L7

12  // GOMAXPROCS sets the maximum number of CPUs that can be executing
13  // simultaneously and returns the previous setting.  If n < 1, it does not
14  // change the current setting.
15  // The number of logical CPUs on the local machine can be queried with NumCPU.
16  // This call will go away when the scheduler improves.
17  func GOMAXPROCS(n int) int {
18      if n > _MaxGomaxprocs {
19          n = _MaxGomaxprocs
20      }
21      lock(&sched.lock)
22      ret := int(gomaxprocs)
23      unlock(&sched.lock)
24      if n <= 0 || n == ret {
25          return ret
26      }
27  
28      stopTheWorld("GOMAXPROCS")
29  
30      // newprocs will be processed by startTheWorld
31      newprocs = int32(n)
32  
33      startTheWorld()
34      return ret
35  }

Line 19 sets the total number to _MaxGomaxprocs.

Which is...

https://golang.org/src/runtime/runtime2.go?h=_MaxGomaxprocs#L407

const (
    // The max value of GOMAXPROCS.
    // There are no fundamental restrictions on the value.
    _MaxGomaxprocs = 1 << 8
)

That bitshift in binary form is 100000000 and 1 is an int which on 64bit systems Go makes that an Int64, which means the max is 256. (32bit systems with int in Go would be int32, but same value of 256)

Now, as far as setting this to more than your number of cores - it all depends on your workload and CPU context switching that is happening (e.g. how many locks does your go program force to happen, or do you use mutex.Lock() everywhere, etc).

Remember, Golang abstracts away the context switching if it needs to happen or not.

Benchmarking is your friend here. If your app runs 10,000 goroutines with little to no cpu context switching (following good design patterns), then yes bump that sucker to 256 and let it ride. If you app chokes and creates a lot of CPU wait-time with context switching/threads, then set it to 8 or 4 even to give it room to breath with all that mutex locking going on.