In runtime it says: The GOMAXPROCS variable limits the number of operating system threads that can execute user-level Go code simultaneously. There is no limit to the number of threads that can be blocked in system calls on behalf of Go code; those do not count against the GOMAXPROCS limit. This package's GOMAXPROCS function queries and changes the limit.
So normally it does not make sense to increase it beyond available physical "HW threads" (I think this is what you meant with cpu) count (since blocked threads do not count towards this limit). As long as "active thread accounting" is accurate in the OS, I dont see any reason to set it higher. I think it is easy to test >HWthreads effects with a concurrent cpu-intensive job. On Wednesday, December 4, 2019 at 8:24:13 PM UTC+3, Vincent Blanchon wrote: > > Hello, > > > I've read on GitHub ( > https://github.com/golang/go/issues/20303#issuecomment-329418911) "there > are good reasons" to set GOMAXPROCS to > num CPU. > Just out of curiosity, I want to know if someone has an example of it or > any good reason to set it up more than the number of CPUs? > > Thanks > -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/7246cd08-f340-4120-875d-7fca069ac8f3%40googlegroups.com.
