Good sequential code != Good parallel code != Good concurrent code

The code you write is very often shaped by the environment you are writing it for. What is good code in one environment can often be very bad code in another.

One of the major distinctions between environments is to do with parallelization and/or concurrency.

Just to get everyone on the same page, here is what I take these phrases to mean:

• Sequential code is code that executes its core logic on a single core, so the problem needs to be solved in a linear fashion

• Parallel code is code that executes its core logic on multiple cores in parallel, with each core working on smaller parts of the same problem

• Concurrent code is code that executes on multiple cores, where each core can be working on completely unrelated problems

Optimising for performance requires different skill-sets for each environment

• To write good performant sequential code, you need to minimize the total number of operations performed, therefore you use clever tricks to reuse previously computed results

  With parallel and concurrent code, the performance penalty is inter-core communication, so it may actually be quicker in wall-time, to re-compute partial results rather than synchronise with the other core(s) to get those partial results

• To write good performant sequential code, you need to make maximum use of the processors memory cache lines, therefore you try to keep storage use to a minimum.

  With parallel and concurrent code, immutable objects can be accessed without locks, so they can be shared by multiple cores, so even though they tend to be more wasteful of space, you actually get more performant code from using them.

• When we look at solving problems in a sequential environment, we tend to favour linear problem decomposition… because it fits the execution environment and our own mental model well… process one thing at a time and accumulate the results.

  Solving problems in a parallel/concurrent environment usually requires multiway problem decomposition and multi-way aggregation of results… think MapReduce and friends

Just some food for thought!

—Stephen Connolly
CloudBees
cloudbees.com

Stephen Connolly has nearly 20 years experience in software development. He is involved in a number of open source projects, including Jenkins . Stephen was one of the first non-Sun committers to the Jenkins project and developed the weather icons. Stephen lives in Dublin, Ireland - where the weather icons are particularly useful. Follow Stephen on Twitter and on his blog .