I had the good fun of co-moderating a panel with Multicore Association President Markus Levy at the Multicore Expo last week. The goal of the panel was to explore how software programmers who aren’t multicore architecture experts – and who don’t want to be – can write code that won’t have to be re-written for each multicore architecture variant that comes around. We were pushing our luck on the scheduling, since it was on the last day just after 4 PM. The exhibit booths were mostly down by then, and the chances were good that everyone would have gone home.

But a healthy crowd postponed their beer and sat in. And it was the most involved crowd I’ve seen at a panel: clearly the topic touched a nerve. Markus and I hardly had to do anything – the audience was right in there driving the conversation.

We tried hard to end on a positive note, since it was clear that there’s a lot of work to do before software programmers are relieved of the burdens of optimizing to the architecture in the way that single-core programmers currently are. Audience frustration with the current state of affairs was palpable.

But there was one comment that got more audience response than any other. When a member of the panel suggested that software programmers should be consulted during the process of designing the multicore architecture, there was a spontaneous round of applause. Clearly these guys felt like the hardware guys go off and do their architecture, and then the programmers have to work around it.

As to the positive note, well, the panelists all felt like much of this is a solvable problem, largely requiring tools, and that things will improve. Programmers may not be completely relieved of the need to consider concurrency, but they should be able to focus only on the concurrency inherent in their program, without having to worry about how that happens to match up with the computing architecture on which it will run.