Commit 01afb79c authored by Rob Pike's avatar Rob Pike

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
parent 899cd04e
......@@ -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>
......
Markdown is supported
0% or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment