When Is Parallel Programming Easy But Useless?

Parallel programming is easy when the problem partitions nicely, perhaps with some replication of read-only or read-mostly data. But just because parallel programming is easy does not automatically make it useful.

The word “useful” entails some goal. Things that move you towards that goal are labeled “useful”.

So, what goals might a parallel programmer be striving towards?

  1. Performance.
  2. High availability (but not for shared-memory parallelism, only for clusters).
  3. Education via the building of parallel-programming skills.
  4. Fun (for hard-core hobbyists).

There are no doubt other goals, but in my experience, parallelism has almost always been a performance optimization. After all, if you don't care about performance, your best strategy just might be to write a simple sequential program and get on with your life.

But parallelism is only one potential optimization of many, and there is no guarantee that it is the best possible optimization for your particular situation. For one thing, parallelism is not typically going to be much use unless the bottleneck is in the CPU. For example, if your workload is I/O-bound, adding more CPUs will do nothing but increase the number of CPUs waiting on I/O, which I believe we can all agree is pretty useless. In this situation, caching or data compression just might be better choices than parallelism.

Other examples leading to useless parallelism include cases where memory is the limiting factor, where each thread's cache footprint is so large that running more instances does nothing but increase the cache-miss rate, where the added effort required to certify a parallel program outweighs the benefits of added performance, or where it just doesn't help for the program to run any faster than it does on a single CPU.

Given these examples of useless parallelism, I am sure that you can come up with many more.