A Few Words of Reality about Multicore Programming Tools

Tom Halfhill, Senior Analyst at InStat, writes for the Microprocessor Report, a newsletter dedicated to discussing new developments in microprocessors and microprocessor-based systems. Microprocessor Report is also a sister publication to EDN. Tom has just published a good editorial on Multicore Programming tools. While I can’t deliver the whole editorial to you—Microprocessor Report is a paid-circulation newsletter—I can show you some of Tom’s editorial because he’s conveniently put an excerpt of it in InStat’s free email newsletter called Processor Watch:

+++ Editorial: Tools for Multicore Processors

Tom R. Halfhill - Senior Analyst, MPR (07/28/2008)

We keep hearing more complaints that it’s hard to write software for multicore processors because there aren’t enough development tools. Not enough tools? That’s like complaining it’s hard to buy Chinese products because there aren’t enough Wal-Marts.

The real problem with multicore processors is too many development tools–and the tools are often difficult to learn and use. What programmers actually seem to want is just one tool. It would work with the most popular CPU architectures, let programmers write serial code in plain-vanilla C, automatically extract parallelism from their code during compilation, and automatically exploit the additional cores in future processors.

Well, sure, we’d all like that. And we would also like an electric car that carries six people, runs 500 miles on a quick charge, and costs $15,000. Maybe it’s not impossible, but it’s not imminent, either.

I think Tom is right on the money here. Your vision is unrealistic if you think that a tool can take your uninspired, serially conceived C code and magically distribute it across multiple processors. Our current crop of design tools are great at executing crisply defined rules over and over again. HLL compilers, wiring routers, and design-rule checkers do this sort of thing billions and billions of times each day. These tools perform a workman-like task and relieve us of the tedium.

However, these design tools don’t have imagination and that’s exactly what you need to creatively distribute the workloads of complex systems over multiple processors. That’s called—um—engineering.