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 | f3fa46a9daf7d53ae096c386fae253a2fbf22c54 (patch) | |
tree | cf786ffbd8b01fdec45bc3f9145060d0c6fad0da | |
parent | df4d97f2c999c4d03c777c671807936f6a61bf0b (diff) | |
download | go-f3fa46a9daf7d53ae096c386fae253a2fbf22c54.tar.gz |
FAQ: more words about why GOMAXPROCS>1 might not speed you up
R=golang-dev, adg, gri
CC=golang-dev
http://codereview.appspot.com/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 33e5cde41..93e1ea4ee 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> |