> Not all programs benefit from concurrency. Writing concurrent code for
> essentially sequential programs will not benefit from multiple cores,
> like generating prime numbers. Do not forget that concurrency includes
> overhead for context switch and memory barriers. Using channels in a
> sequential program is I think misuse of channels. There is no
> performance gain in having a sequence of goroutines, each waiting for
> the previous one the complete.

You are conflating concurrency and parallelism, or perhaps the problem and
the solution. Some programs (solutions) benefit from expression as
concurrent code, others do not. Whether performance improves depends on how
many cores you have as well as the inherent nature of the problem. Remember
there is no such thing as parallelism on a single core, yet the idea of
using concurrency in programs arose when multicore was but a dream.

Judging the benefit of an approach to a problem depends on your figure of
merit. Your figure of merit seems to be performance, which is perfectly
valid. Mine depends on the problem and on the solution, and performance may
not be the most important component.

In other words, some solutions work well expressed concurrently; others do
not. Whether the performance improves is only one part of deciding how
well. One programmer's misuse may be another's thing of joy.


You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 

Reply via email to