On Mon, Dec 30, 2019 at 10:14 PM Robert Engels <reng...@ix.netcom.com> wrote:
> Here is a simple test that demonstrates the dynamics > https://play.golang.org/p/6SZcxCEAfFp (cannot run in playground) > > Notice that the call that uses an over allocated number of routines takes > 5x longer wall time than the properly sized one - this is due to scheduling > and contention on the underlying structures. So blindly creating go > routines does not achieve optimum performance for many workloads (even when > the number of OS threads is capped). > > rengels@rengels:~/gotest$ go run main_bench.go > 2.261805812s > 1.311269725s > 6.341378965s > > Yes, this is unsurprising since the problem in the program is parallel. In a typical concurrent problem, most work is sitting and waiting for some event to happen and those events are usually measured in several milliseconds. For those problems, the switching cost is very low given the other benefits you gain. The key property there is rarely about speed, but about description of the problem to the machine. Go definitely leans toward concurrent problems. If you want to target parallel problems, you have other options which are better, depending on factors of distribution, GPU availability, etc. -- J. -- 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/CAGrdgiVaF2AQF%2BehTk5ugP%3DWq%2BS8SmxKNxNTuXKWF8LrYeV2-Q%40mail.gmail.com.
