Hello Serhat,
Yes, I do not see a use case either. This is why I opened this thread, to know if someone sees a use case since it has been mentioned on GitHub :) Le jeudi 5 décembre 2019 11:33:10 UTC+4, Serhat Şevki Dinçer a écrit : > > 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/e281fe24-26f2-4a20-89ee-b43888c557c2%40googlegroups.com.
