diff options
author | Rob Pike <r@golang.org> | 2012-01-26 14:44:38 -0800 |
---|---|---|
committer | Rob Pike <r@golang.org> | 2012-01-26 14:44:38 -0800 |
commit | 01afb79c5960c746238c21b1eadc222af85d7c19 (patch) | |
tree | 9a3b706d84393c70aab5179f29dc4e67d6cbe9f9 | |
parent | 899cd04e214435ee09483231fc3fa03ad270c5e6 (diff) | |
download | go-01afb79c5960c746238c21b1eadc222af85d7c19.tar.gz go-01afb79c5960c746238c21b1eadc222af85d7c19.zip |
FAQ: more words about why GOMAXPROCS>1 might not speed you up
R=golang-dev, adg, gri
CC=golang-dev
https://golang.org/cl/5572067
-rw-r--r-- | doc/go_faq.html | 21 |
1 files changed, 17 insertions, 4 deletions
diff --git a/doc/go_faq.html b/doc/go_faq.html index 33e5cde41a..93e1ea4ee5 100644 --- a/doc/go_faq.html +++ b/doc/go_faq.html @@ -1020,10 +1020,23 @@ slower?</h3> <p> It depends on the nature of your program. -Programs that contain several goroutines that spend a lot of time -communicating on channels will experience performance degradation when using -multiple OS threads. This is because of the significant context-switching -penalty involved in sending data between threads. +Problems that are intrinsically sequential cannot be sped up by adding +more goroutines. +Concurrency only becomes parallelism when the problem is +intrinsically parallel. +</p> + +<p> +In practical terms, programs that spend more time +communicating on channels than doing computation +will experience performance degradation when using +multiple OS threads. +This is because sending data between threads involves switching +contexts, which has significant cost. +For instance, the <a href="/doc/go_spec.html#An_example_package">prime sieve example</a> +from the Go specification has no significant parallelism although it launches many +goroutines; increasing <code>GOMAXPROCS</code> is more likely to slow it down than +to speed it up. </p> <p> |