Issue 48 - May 2010
Editorial Intro - Matt Nicholson
Last month I spent a couple of days at the Gran Hotel La Florida, suspended high above an overcast Barcelona. I was there for the Intel Software Conference 2010, the fifth annual meeting that Intel has held at assorted European locations in an attempt to persuade us to 'think parallel'.
The reason we need to 'think parallel' was made clear at the first conference, held in London in 2006. Processor speeds had been increasing at an exponential rate for nearly 30 years, from the 4.77MHz of the 8086, introduced in 1978, to the 3.4GHz of the Pentium 4, achieved in 2004. As a result, software developers have benefited from what Intel refer to as a 'free lunch', in that each successive generation of processor has made their software run faster, without them having to raise a finger. This free lunch ended in 2004 when Intel realised that speeds above 3.4GHz were simply not viable.
Intel's solution was the multi-core processor. These days even entry-level desktops and laptops come with dual-core processors, while the latest Intel Core i7 uses Hyper-Threading to simulate eight processor cores on four physical cores.
Developers can only take advantage of such processors if they write their software to work in parallel, executing more than one instruction at a time. However concurrency introduces a whole new set of potential bugs caused by 'race conditions' and 'deadlocks'. This is alien territory for most developers, and hence the need to learn how to 'think parallel'.
Over the past five years, Intel and partners such as Microsoft have released a succession of compilers, tools and libraries to help with the writing and debugging of parallel code. One obvious progression is the shift in focus from Fortran, C and C++, and from 'traditional'; programming models such as OpenMP and MPI; to the 2010 event which saw Microsoft's Steve Teixeira taking us through the new features in .NET Framework 4.0 that facilitate parallel development such as Parallel LINQ, the new Parallel and Task classes from the Task Parallel Library, and the Concurrency Runtime which is independent of programming model.
One thing that became apparent at the 2010 conference, and was confirmed in my conversation with Intel's James Reinders, is that parallelism should be an adjunct of algorithm design, which means it is the solution architect who needs to 'think parallel', rather than the coder. Here the concept of the Task, and Task-based programming, become useful. By thinking in terms of tasks, and how those tasks interact, potential race conditions and deadlocks can be avoided.
There are parallels (excuse the pun) with the management of business projects. The business manager needs to allocate tasks to staff so as to allow each to work as efficiently as possible without interfering with the work of their colleagues. In other words, business managers already 'think parallel'. Perhaps the territory is not so alien.
|