[codemusings]

> The irony is that, since you are splitting the problem in a way that requires synchronization between cores, you are actually introducing more work to be executed in the same CPU-time budget. So you are spending more time on overhead due to synchronization, which does the opposite of what you probably hoped for — it makes your code even slower, not faster.

That is certainly not universally true for every scenario and if you need to sync state between cpu cores very often then your tasks simply don't lend themselves to parallelization. That doesn't mean that multi-threading is inheritely the wrong design choice. Of course it will always be a trade-off between performance gains and the code complexity of your job control.

[hinkley]

But people new to thinking about concurrency don’t know this. They write “parallel” code that goes pretty fast, and that initial reward convinces them to continue. Then the bugs are found, and their parallel code gets slower, but that’s just bug fixes. Never mind the performance loss.