TLDR: Adjust GOMAXPROCS if you want a speedup from multiple goroutines.<p><a href="http://golang.org/pkg/runtime/" rel="nofollow">http://golang.org/pkg/runtime/</a><p>"GOMAXPROCS sets the maximum number of CPUs that can be executing simultaneously and returns the previous setting. If n < 1, it does not change the current setting. The number of logical CPUs on the local machine can be queried with NumCPU. This call will go away when the scheduler improves."<p>It will be nice when this requirement is eliminated.
I think that the default of single threaded is going to bite them hard in the long run. I've already discovered libraries that were never tested with MAXGOPROCS > 1 that are not thread safe. They should default it to at least 2 to make sure these bugs are shaken out.
Another error the author made is adding to a sync.WaitGroup in a different goroutine than the one that waits. This is another rookie mistake that go test -race would probably catch.
OT: The way we use the terms parallel and concurrent in computer science seems completely backward to me. The dictionary says "concurrent" means at the same time, and parallel lines need not be drawn at the same moment...<p>Yet in CS we talk of things being concurrent even if they're executed as cooperative threads on a single core and parallel only applies when executing concurrently (at the same time).
No-one has ever claimed it is, in fact they specifically tell you it isn't, multiple times<p>A Jan 2013 Go lang blog post<p><a href="http://blog.golang.org/concurrency-is-not-parallelism" rel="nofollow">http://blog.golang.org/concurrency-is-not-parallelism</a><p>reminding people of the Jan 2012 talk Rob Pike did on the subject<p><a href="https://talks.golang.org/2012/waza.slide" rel="nofollow">https://talks.golang.org/2012/waza.slide</a><p>Feb 2011 : Rob Pike on Parallelism and Concurrency in Programming Languages<p><a href="http://www.infoq.com/interviews/pike-concurrency" rel="nofollow">http://www.infoq.com/interviews/pike-concurrency</a><p>I'll skip all the intermediate steps from there back to<p>Tony Hoare<p><a href="http://www.usingcsp.com/" rel="nofollow">http://www.usingcsp.com/</a>
I have just started a Go project for a core aspect of my business, so this information was well timed, for me at least, and gave me a quick overview of concurrency/parallelism in Go.<p>I will be developing both concurrent and parallel threads in my app, so this was very enlightening.<p>Thanks to the author for his clear writing style and efforts to educate.
Its a decent intro, but I think instead of just jumping into parallel code, its better to read the docs before hand. There are plenty of references to GOMAXPROCS and the thread safety of math/rand (and most of the stdlib).
This is a somewhat trivial suggestion, but it would be much more clear to your readers what the speedup was if you aligned the values in the benchmark results.
<a href="http://joearms.github.io/2013/04/05/concurrent-and-parallel-programming.html" rel="nofollow">http://joearms.github.io/2013/04/05/concurrent-and-parallel-...</a><p>Parallel, at least in English, means to have nothing in common with others. On most OSes it is a <i>process</i> affined to a dedicated CPU which is configured to access a dedicated physical I/O device only. Everything else is concurrent.
Parallelism is like hunting elephants. The languages we use like Java, Ruby, Python and C++, for example, give you weapons for the hunt on the level of a very strong toothpick at best. Go has apparently upgraded the situation to a 3" pocket knife. Clojure to the level of a proper spear. But we need languages that allow us to completely avoid hunting elephants in the first place.
Have sent a PR handling all the wrinkles: <a href="https://github.com/soroushjp/go-parallelism-monte-carlo-demo/pull/2" rel="nofollow">https://github.com/soroushjp/go-parallelism-monte-carlo-demo...</a><p>* There is a race condition where wg.Wait() might execute before the wg.Add(1) runs
* The wait group was not necessary as we are already waiting for all the results from the channel
Thanks for all the feedback everyone. Incorporated everything to make the code as good as possible, want readers to learn as much as possible. Just to be clear, this article was my way of highlighting Rob Pike's point that concurrency <i>isn't</i> parallelism, not to make it seem as if Go didn't support or was falsely claiming true parallelism.
It looks like you didn't allow for using more than a single process by setting GOMAXPROCS.<p>Additionally, it looks like you're re-seeding your random engine inside your sample loop, which is very slow. You only need to seed the engine outside the loop at the beginning.
I wouldn't call this "real world". In a real world you are better off distributing these kind of tasks across multiple machines. Multicore parallelism per se is overrated and overhyped.