mirror of
https://github.com/golang/go
synced 2024-11-21 17:04:42 -07:00
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
This commit is contained in:
parent
899cd04e21
commit
01afb79c59
@ -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>
|
||||
|
Loading…
Reference in New Issue
Block a user