aboutsummaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorRob Pike <r@golang.org>2012-01-26 14:44:38 -0800
committerRob Pike <r@golang.org>2012-01-26 14:44:38 -0800
commit01afb79c5960c746238c21b1eadc222af85d7c19 (patch)
tree9a3b706d84393c70aab5179f29dc4e67d6cbe9f9
parent899cd04e214435ee09483231fc3fa03ad270c5e6 (diff)
downloadgo-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.html21
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>