CODEWITHSUNDEEP
goparallel-processing
Shan Valleru
Shan Valleru

Reputation: 3121

Parallel programming in go using GOMAXPROCS

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

Upvotes: 3

Views: 3004

Answers (2)

eduncan911
eduncan911

Reputation: 17604

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.

Upvotes: 3

matt.s
matt.s

Reputation: 1736

You shouldn't need to mess with GOMAXPROCS most of the time since the runtime interacts with the OS for you. GOMAXPROCS used to default to 1, but with Go 1.5, it now defaults to the NumCPU()

Setting it higher than NumCPU will only give the scheduler more (unnecessary) work for dealing with OS threads.

Upvotes: 6

Related Questions