How do you see the multicore maze right now? Your experience can make all the difference in how you approach solutions and where your application goes next.

I opened my recent presentation at the Wind River Multicore Regional Conference with the idea that multicore is like a maze – it’s easy to get into, but harder to get out with the results you want unless development is viewed differently.

Multicore hardware is plentiful and multicore operating systems are catching up, but application developers are just getting started. VDC just published a September 2010 report indicating that nearly 65 percent of engineers have less than one year of experience deploying software over multicore platforms. The questions of what multicore is capable of, what it will do for my application, and how my development has to change are on a lot of developers’ minds lately. For the latest ideas, visit http://channels.opensystemsmedia.com/Multicore

There is a huge variety of multicore architectures with compute cores, graphics cores, DSP cores, networking cores, and I/O cores, and in many cases software designers don’t actually know what’s under the hood. That idea prompted an interesting audience remark: “We’ve found that it’s easier to just start over.” Taking that lump of existing C code and trying to spread it out over a new multicore architecture isn’t the fastest path in some instances.

Another audience member posed this question: “What kind of parallel compiler technology is available?” This query is an indication that people tend to think of symmetric multiprocessing first. There are applications that benefit from technology like OpenMP and parallel programming. But often the application either has subsets or regions of intensity that lend to breaking things up instead of just spreading them out equally across cores.

Case in point: Wind River presenters said that for packet acceleration, they’re discovering that two groups of four cores each running a suite of tasks significantly outperform one group of eight cores running the complete set. That’s true even in an advanced multicore architecture with fabric connections between the cores and a hypervisor layer spanning independent guest operating systems running on each core.

 

 

Our lunch table challenged me for saying this concept is as big as the changeover from digital logic to microprocessors: “This isn’t new and it’s not that big a transition.” They thought they had seen all these things before a couple of times, except the problem used to be spread across multiple boards instead of across cores within a single processor. I believe there are some parallels, but the world of pipelined microarchitecture, multilevel cache, fabric interconnect, and intelligent peripherals is very different from the world of shared parallel buses, register polling, and mailboxes.

Visibility inside multicore is another big issue – both getting in and keeping out. Wind River officials said they’re seeing a resurgence in JTAG analyzer use cases, and Freescale representatives described their efforts in QorIQ trusted platform technology to make it much more difficult to see inside once an application is fielded.

The value-add on multicore platforms will move into optimizing applications and securing the IP. It’ll take some relearning for developers to get the most out of the technology.

What are your thoughts on the multicore state of things? Are operating systems caught up to multicore processors? Is application development and optimization really easy or really difficult or somewhere in between? What’s changing in your development practices for multicore? Share your ideas with us.

Next up:

Consumer Electronics ShowJanuary 6-9, 2011Las Vegas, NVwww.cesweb.org

@dondingee, @embedded_mag

[email protected]