editor's blog
Subscribe Now

An Unambiguous Message for Multicore Architects

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.

Leave a Reply

featured blogs
Oct 16, 2019
In this week's Whiteboard Wednesdays video, David Peña discusses Cadence'€™s focus on models for various emerging memory standards. https://youtu.be/_Xps6I6kE0E [[ Click on the title to access the full blog on the Cadence Community site. ]]...
Oct 15, 2019
As technology advances, it's becoming harder and harder to know what is real and what isn't....
Oct 14, 2019
My working life includes a lot of writing – blogs, articles, conference papers and white papers are typical of what I produce. A common factor of my writing is that it is aimed to be technical and instructive. What I do not like writing is sales pitches. I can accept th...
Oct 14, 2019
In 1995, I attended a seminar in which the presenter told us that copper was dead.  This sort of statement is not new. The connector market is filled with armchair pundits who predict the demise of everything from D-Subminiature connectors (which are very much alive and ...
Oct 11, 2019
[From the last episode: We looked at subroutines in computer programs.] We saw a couple weeks ago that some memories are big, but slow (flash memory). Others are fast, but not so big '€“ and they'€™re power-hungry to boot (SRAM). This sets up an interesting problem. When ...