From ca69a916ca588ff24f8804b1c1b91926726280ec Mon Sep 17 00:00:00 2001 From: Rob Pike Date: Fri, 13 Jul 2018 09:08:13 +1000 Subject: [PATCH] doc: rearrange the description of GOMAXPROCS The old text was written when it was only 1 by default, which changed a long time ago. Also add a note that GOMAXPROCS does not limit the total number of threads. Change-Id: I104ccd7266d11335320a4d7f5671fb09ed641f88 Reviewed-on: https://go-review.googlesource.com/123916 Reviewed-by: Ian Lance Taylor --- doc/go_faq.html | 82 ++++++++++++++++++++++++++----------------------- 1 file changed, 44 insertions(+), 38 deletions(-) diff --git a/doc/go_faq.html b/doc/go_faq.html index 002b44777d..21d4ebd996 100644 --- a/doc/go_faq.html +++ b/doc/go_faq.html @@ -1437,7 +1437,7 @@ Do not communicate by sharing memory. Instead, share memory by communicating.

See the Share Memory By Communicating code walk -and its +and its associated article for a detailed discussion of this concept.

@@ -1445,8 +1445,42 @@ associated article for a detailed discussion of this concept. Large concurrent programs are likely to borrow from both these toolkits.

-

-Why doesn't my multi-goroutine program use multiple CPUs?

+

+Why doesn't my program run faster with more CPUs?

+ +

+Whether a program runs faster with more CPUs depends on the problem +it is solving. +The Go language provides concurrency primitives, such as goroutines +and channels, but concurrency only enables parallelism +when the underlying problem is intrinsically parallel. +Problems that are intrinsically sequential cannot be sped up by adding +more CPUs, while those that can be broken into pieces that can +execute in parallel can be sped up, sometimes dramatically. +

+ +

+Sometimes adding more CPUs can slow a program down. +In practical terms, programs that spend more time +synchronizing or communicating than doing useful computation +may experience performance degradation when using +multiple OS threads. +This is because passing data between threads involves switching +contexts, which has significant cost, and that cost can increase +with more CPUs. +For instance, the prime sieve example +from the Go specification has no significant parallelism although it launches many +goroutines; increasing the number of threads (CPUs) is more likely to slow it down than +to speed it up. +

+ +

+For more detail on this topic see the talk entitled +Concurrency +is not Parallelism. + +

+How can I control the number of CPUs?

The number of CPUs available simultaneously to executing goroutines is @@ -1464,50 +1498,22 @@ forcing independent goroutines to take turns executing.

-Programs that perform parallel computation might benefit from a further increase in -GOMAXPROCS. -However, be aware that -concurrency -is not parallelism. -

- -

-Why does using GOMAXPROCS > 1 sometimes make my program -slower?

- -

-It depends on the nature of your program. -Problems that are intrinsically sequential cannot be sped up by adding -more goroutines. -Concurrency only becomes parallelism when the problem is -intrinsically parallel. -

- -

-In practical terms, programs that spend more time -synchronizing or communicating than doing useful computation -may experience performance degradation when using -multiple OS threads. -This is because passing data between threads involves switching -contexts, which has significant cost. -For instance, the prime sieve example -from the Go specification has no significant parallelism although it launches many -goroutines; increasing GOMAXPROCS is more likely to slow it down than -to speed it up. +The runtime can allocate more threads than the value +of GOMAXPROCS to service multiple outstanding +I/O requests. +GOMAXPROCS only affects how many goroutines +can actually execute at once; arbitrarily more may be blocked +in system calls.

Go's goroutine scheduler is not as good as it needs to be, although it -has improved in recent releases. +has improved over time. In the future, it may better optimize its use of OS threads. For now, if there are performance issues, setting GOMAXPROCS on a per-application basis may help.

-

-For more detail on this topic see the talk entitled, -Concurrency -is not Parallelism.

Why is there no goroutine ID?