Editorials

Can You Go Parallel?

If I had to pick important programming techniques for developers to learn well in the modern age I think I would choose Asynchronous Code and Parallel Processing. As our hardware continues to grow by adding more CPUs or Cores, we must become more proficient with these two patterns, if we are going to write performant code that plays well with other software.

Anyone who has written their own multi-threaded application from the ground up in a language like C++, Java or C# knows how painful it is to implement these two patterns. The code becomes even more complicated if multiple threads have to cooperate in some fashion. When they share data, or must notify one another of state, the software complexity increases considerably.

Many software languages and services are making these patterns much simpler to implement. Google’s Cloud Dataflow allows you to present your work, and the separation and synchronization of threads are done for you. Your client software is quite simple. The same is true of database engines that take advantage of multiple cores. You submit your query to the engine, and it handles the parallelism on your behalf.

In those cases when you are rolling your own software that needs to by asynchronous and/or parallel, many languages have provided constructs to manage the underlying thread management on your behalf. You see things like ParDo in the Cloud Dataflow, or Parallel.For in C#. C# makes asynchronous programming quite simple with the Task and Await syntax. These capabilities make it so much easier to write our software in a parallel form that it is well worth learning how to do it. If you want to stay relevant for the next few years, you are probably going to have to get this under your belt.

That doesn’t mean all your code should be written to use parallel constructs. Parallel and Asynchronous code has associated overhead to keep the different threads or processes synchronized. You’ll see new features like Parallel Collections. These new collections perform slower than the non-parallel counterparts, simply because of the locking and blocking that happens behind the scenes to keep multiple threads from impacting each other. Sure, you don’t have to write the locks anymore. But you still have to assure two different threads don’t manipulate the same object simultaneously.

So, if you don’t have these coding patterns down, you may want to add that to your personal development in the near future.

Cheers,

Ben