A postcard from Intel in Lisbon
Intel says 'parallel or perish'
So you thought Intel was a hardware company? In fact, it's also a major supplier of software – compilers and developer tools.
This was what the Think Parallel Intel EMEA Software Conference 2.0 in Lisbon was all about. I've only space to cover the main theme here (there was an interesting session I must return to, on Second Life, which Intel presumably hopes will soak up the multicore processing power it's going to be providing) and the tone was set by Herb Sutter (Microsoft software architect and chair of the C++ Standards Committee), who revisited his "the free lunch is over" warning (originally given here).
Herb Sutter contemplates
the end of the free lunch.
Basically, Sutter's saying that while Moore's Law still applies in its purest sense (you can double the number of transistors on a square inch of silicon every 24 months), this isn't delivering the expected end-user performance improvements any more.
At the same time, power consumption is becoming a major issue – in fact, it's the prime barrier to growth on the very largest systems (this is confirmed by eBay Inc technical fellow Dan Pritchett, speaking at the QCon -see here - as well as by Sun making "green computing" a keynote of SunLive07).
The answer to both the flattening of the performance curve and increasing power consumption seems to be multicore chips – and the end of the ubiquitous sequential Von Neumann architecture as we know it. A small drop in clock speed yields a small drop in performance and a proportionately much larger drop in power consumption. Put several of these lower power processors on a socket and you can ramp up performance while keeping power consumption constant, thus breaking through what Intel's James Reinders (lead evangelist and director of marketing and business development), who gave the Day 1 closing keynote, called the "Power Wall".
That's all very well, of course, but for MRDA. Intel has built its business model around Moore's Law and the continual upgrading of PCs. To some extent, these powerful multicore chips might look like a solution looking for a problem. However, there certainly are some that are thought of as HPC (High Productivity, rather than High Performance, Computing) problems (real-time 100 per cent accurate speech recognition, for example) that could move to the desktop, so let's accept Intel's worldview for now.
The fly in this particular ointment is the good old programmer, who isn't famous for an ability to handle multiprogramming or multithreading. Multithreaded applications are often brittle, often due to race conditions and deadlocks, and many applications avoid these issues by only running on one processor.
However, we don't really want the sort of parallel programming on quad core chips which just runs the OS in a thread on one processor, Office on a second, and all the spy ware that clutters up most PCs on a third – leaving just one processor for actual work...
The strong message from this conference was that programmers had better start thinking in terms of parallel processing, at least if they expect to run on Intel hardware. This certainly doesn't mean coding with locks and semaphores, however. As Reinders says: "This is the assembly language of parallel processing" - and that way lies brittle, unmaintainable code.
Neither does it mean dividing your program into, say, four threads, one per processor, because while that program may work very well on a quad processor it simply won't scale to more processors. One message from this conference was to think in terms of hundreds of processors, not now perhaps, but sooner than you might think – Intel claims that it can already build 80 core chips if it wants to. Oh, and by the way, you had better make sure that your parallel-enabled application can actually run on a single core machine, or you'll find debugging the non-parallel functionality a PITA.