> We have to go parallel for things that need speed. That really depends on the kind of speed you need. I have, in my brief time on this planet, accomplished e

> We have to go parallel for things that need speed. That really depends on the kind of speed you need. I have, in my brief time on this planet, accomplished each of the following at least once: Sped up a concurrent implementation by making it parallel. Sped up a concurrent implementation by making it sequential. Sped up a parallel implementation by making it concurrent. Sped up a parallel implementation by making it sequential. Sped up a sequential implementation by making it concurrent. Sped up a sequential implementation by making it parallel. The 2nd and 4th ones are often the easiest to accomplish. Amdahl's law is a great rule of thumb, but it subtly implies an idealized world where both the transition between sequential and parallelizable sections of the process, and the communication among parallel sections, happen at zero cost. The real world is messy, though, so, in practice, they can get pretty expensive. Parallelism can slow things down by introducing extra copying, memory access, memory fences, conditional branches, etc. You've got to dig yourself out of that hole before you can realize any gains. To the extent that the term "order of magnitude" often comes into play when describing the sizes of delays these things can cause, it can be a pretty deep hole.