On Sunday, 29 December 2019 22:18:51 UTC, Robert Engels wrote: > > I agree. I meant that worker pools are especially useful when you can do > cpu affinity - doesn’t apply to Go. > > I think Go probably needs some idea of “capping” for cpu based workloads. > You can cap in the local N CPUs
By default go only runs N threads, where N is the number of CPUs > , but in a larger app that has multiple parallel processing points you can > easy create too many routines and then you are paying overhead switching > costs for no reason. > > Which switching cost are you referring to? The switching cost between goroutines? This is minimal, as it takes places within a single thread. Or are you referring to cache invalidation issues? Or something else? -- 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/2fa8b487-d95e-46b3-9b8c-3a0833cd0b85%40googlegroups.com.
