Getting Positioned in Parallel

As multicore issues arise in your personal programming practice, what you want to know is how to position yourself in the new arena. I have a few practical observations to share on this score.

First of all, the new arena is called "How to use all this power." Things you could not do before you can do now. Things can genuinely happen asynchronously and simultaneously now, which is the making of certain algorithmic confections and the breaking of certain legacy applications.

Let's refine that: "How to use all this power safely." Multiproc operating systems can stymie older apps which had implicit, hidden dependencies on the serial implementation of classic multitasking's emulation of parallelism.

Let's refine that further: "How to use all this power safely in the context of the marketplace." All the parallel algorithms were known decades ago. What is most accessible and broadly useful in the mass marketplace is a loose task parallelism supported by the higher-level toolkits, the synchronization of work units that themselves are conceptually unitary but at the code level are complex and heterogenous. Classic biz/consumer applications exhibiting multitasking were already modelling this in the multitasking era, albeit their code bodies, compiled objects and some conceptions were broken or flawed when transferred to genuinely parallel platforms.

And further: "How to use all this power safely in the context of multiple marketplaces." There are layers of increasingly technically demanding parallel application market spaces. Image resolution is deeper (though arguably more straightforward) than speeding up a word processing package.

The first thing to do is decide what you want out of which parallel platforms. Are you writing consumer apps or mapping distant galaxies, and are you doing it on Windows, or portably also to Mac and Open Source, or on a custom platform like IBM SP?

It all resolves itself as soon as you ask the right questions. If you're in supercomputer world, including supercomputers woven from packs of biz/consumer boxes, your algorithms will come from textbooks and experience and your tools will be dictated by implementation availability.

If you're doing computationally intense stuff or designing programming frameworks or authoring C/C++ backends to transactional web applications, you should explore feverishly TBB and OpenMP and become briefly expert in all nuances, including the nerdly compiler support/non-support issues for every platform you support. Join the community, read the forums, the whole nine yards.

If you're working on classic biz/consumer apps, you're probably best off doing workflow systems based on messaging models, possibly employing messaging middleware. You'll never write a lock or a semaphore and you won't miss it very much.