I feel that a discussion of <a href="http://en.wikipedia.org/wiki/Amdahl's_law" rel="nofollow">http://en.wikipedia.org/wiki/Amdahl's_law</a> should be mandatory when introducing parallel programming<p>Small sequential portions of an otherwise parallel algorithm can have huge effects on the overall running when trying to scale up.<p>"parconc" explains this while discussing a parallel version of k-means, talks about how things like granularity of data needs to be fine-tuned for parallel algos, and provides some nice visualizations into what the CPU's are actually doing on a timeline: <a href="http://chimera.labs.oreilly.com/books/1230000000929/ch03.html#sec_par-kmeans-perf" rel="nofollow">http://chimera.labs.oreilly.com/books/1230000000929/ch03.htm...</a><p>Overall I think multicore is a good tool to have in your toolbox, but it seems like there needs to be a lot of tuning and effort to get good rewards for the time invested.
I wrote <a href="https://github.com/abemassry/crazip" rel="nofollow">https://github.com/abemassry/crazip</a> in python and it was challenging to find out how to do multiprocessing effectively, not sure how this would run if implemented in other laungaues.
This article contains a perfect example of why I don't like to write or read comments in code. Comments are not compiled and thus allow for sloppy verbiage such as the following:<p><pre><code> # Exit the completed processes
for p in processes:
p.join()
</code></pre>
The comment should read something more like: "Wait for all the subprocesses to exit" but is that really any more helpful than just reading the code and seeing that join is called on each subprocess and connecting the dots from there?
Instead of calling the 'else' condition of the for loop a 'completion-else', just call it the 'nobreak' condition. Unlike 'completion-else', 'nobreak' immediately describes when it will be executed.