I attended a DATE 2008 open exhibition panel discussion on multicore programming, organized by Gary Smith EDA. The panel was a few people short, and ended up with just Simon Davidmann of Imperas, Grant Martin of Tensilica, and Rudy Lauwereins of IMEC. A user representative from Ericsson was supposed to have been there but he never arrived. Overall, the panel was geared towards data-plane processing-type thinking, and a bit short on internal dissonance.
Any case, the panel said the following, including feedback from the audience (including the author of this post):
- Gary Smith laid out some data indicating that software is overtaking hardware as the main effort even for the core SoC designers for multicore. Today, some 50% is software, by 2012, 75% of the design cost will be software.
- Rudy lamented the difficulty of doing anything with regular unrestrained C code, and
described some IMEC research where they restrict down C to make it palatable. Probably related to their work on “2D” VLIW architectures. Their “clean C” can easily be analyzed and create statically scheduled code (my interpretation) that runs well without caches and cache coherency. The audience asked how you could actually write a program without using pointers… good point. I think it can work nicely for data crunching, but fails horribly for control-oriented and dynamic codes. - Grant made the point that there is no need to panic. Today, we can see people actually building successful multicore systems with today’s tools. It is a bit of muddling through, but it does get through. There is a lot of truth to that, but it misses the issue of converting or containing all legacy code that has a hard time moving from a single to multiple processors.
- Grant also said that the applications he had seen the most success with where those typically called “embarrassingly parallel”. But why should anyone be embarrassed that they have such nice problems? There is nothing to be embarrassed about, rather you should be proud of having such a nice system/algorithm.
- Simon Davidmann echoed my favorite theme that simulation is a key tool to develop software for multicore, as it gives you insight and control.
- When asked about hardware debug support, Simon was downright negative and wanted it all in simulation. Grant said that the proper solution was a mix of hardware debug and software simulators, which I agree with (see http://jakob.engbloms.se/archives/17 for some more thinking on this topic).
- Someone pointed out that hardware debug is sometimes taken out of volume chips and is only used in development versions — apparently, that is common in automotive, as the cost of each shipping chip is of utmost importance. Less practical for larger machines, though, where you cannot easily build a development version of your rack/router/switch/server…
- When asked about how to handle billions of lines of legacy code in a mix of C, C++, Java, and other languages, Rudy sounded downright exasperated. He seemed to be most comfortable with expressing algorithms and mapping them down to hardware using tools, rather than trying to deal with managing a zoo of legacy code… that is what I mean with the data-plane/data-crunching mindset of this panel.
Overall, an interesting panel, but a bit disappointing in the lack of large-scale software thinking. Would have been nice to mix in someone with an HPC, server, or large-scale control-plane embedded-systems background in the panel.