> > > 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. -rob -- 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 https://groups.google.com/d/msgid/golang-nuts/CAOXNBZSPhMm1XWtMBX7z7g%3Dbh4gXW%2BRrrQ%2BfLCmN3aeE-UzhDQ%40mail.gmail.com.
