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
Jan 17, 2020
[From the last episode: We saw how virtual memory helps resolve the differences between where a compiler thinks things will go in memory and the real memories in a real system.] We'€™ve talked a lot about memory '€“ different kinds of memory, cache memory, heap memory, vi...
Jan 16, 2020
While Samtec started as a connector company with a focus on two-piece, pin-and-socket board stacking systems, High-Speed Board Stacking connectors and High-Speed Cable Assemblies now make up a significant portion of our sales. To support development in this area, in December ...
Jan 16, 2020
Betting on Hydrogen-Powered Cars On-demand DRC within P&R cuts closure time in half for MaxLinear Functional Safety Verification For AV SoC Designs Accelerated With Advanced Tools Automating the pain out of clock domain crossing verification Mentor unpacks LVS and LVL iss...
Jan 16, 2020
This little robot arm continually points to the current location of the International Space Station (ISS)....

Featured Video

RedFit IDC SKEDD Connector

Sponsored by Wurth Electronics and Mouser Electronics

Why attach a header connector to your PCB when you really don’t need one? If you’re plugging a ribbon cable into your board, particularly for a limited-use function such as provisioning, diagnostics, or testing, it can be costly and clunky to add a header connector to your BOM, and introduce yet another component to pick and place. Wouldn’t it be great if you could plug directly into your board with no connector required on the PCB side? In this episode of Chalk Talk, Amelia Dalton chats with Ben Arden from Wurth Electronics about Redfit, a slick new connector solution that plugs directly into standard via holes on your PCB.

Click here for more information about Wurth Electronics REDFIT IDC SKEDD Connector