How We See Embedded Processing

Before we take a look at the landscape of multicore programming and what is happening within it, there’s one thing that we need to bear in mind, a key fact that often gets overlooked:

Software engineers did not ask for multicore architectures!

Let’s be really clear about this because there’s some unfair and unnecessary finger-pointing going on at the moment. Competitive products demand more performance at lower power consumption. Silicon and processor providers decided, undoubtedly for the right reasons, that multicore architectures were the only cost effective way to service these requirements, shifting the burden of unlocking the benefits to the software teams. Yet, it’s really the responsibility of the entire team, software and hardware groups alike, to solve the programming issues introduced, as the entire team is also responsible for time-to-market.

When it comes to the main challenge of how to migrate sequential software onto these multicore platforms, plenty of advice is available. There are two rather extreme camps pushing what software engineers need to do. On one side we have the ‘do nothing’ camp. This group believes that the saviour of this situation comes from an unlikely source - the operating system vendors. Get yourself a multicore-aware OS, give it all your existing sequential applications, and let the scheduler figure out how to load and balance the underlying processing elements. Sounds great doesn’t it? This approach will run your apps correctly, and, if you’re lucky enough to find a multicore-aware OS that doesn’t slow you down too much, and if you are lucky enough to have applications which all have similar performance demands and execution profiles, and if the number of apps running nicely matches the available multicore resources, then you may be able to build a system which pleases you. Most people going down this route won’t be so lucky. They will be functionally fine, but they will not reap the promised benefits of multicore and will quickly realize that more work is needed. This is a great example of no more free lunch if I ever saw one.

On the other hand, we have the ‘change everything’ camp. This group says that the old methodologies and languages have had their time, and software developers need to aggressively embrace new languages, programs, class libraries and parallelizing compilers. This, by the way, means that if you have existing software applications written using last century’s syntax, you have a bit of work to do. Doesn’t that sound great? Actually, since engineers love to learn new stuff, then perhaps it will be fun. But then again, you do have a day job and so don’t forget all the work you have to get done and the timeline you are working against - a morale deflator for sure. If you do have the time to re-write your complete application, or you’re writing a new parallel application from scratch, maybe you can go this route. Keep in mind of course that if the new parallel language and/or compiler you choose doesn’t emerge as the de facto standard, you’ll have more re-work on your hands.

Having said all this, there are, of course, products in the market which are based on multicore platforms and which successfully run software. Which makes you wonder, what’s actually going on in the software development community with respect to multicore programming? Have programmers ‘done nothing’ or ‘changed everything’?

Not surprisingly, they’ve done neither. They’ve actually done what engineers typically do when they face a new challenge under a tightly constrained time budget – they innovate within and around the environment and methods that they have immediately available to them and with which they are most familiar. In other words, the approach taken is evolutionary rather than revolutionary. They recognize of course that there is no free lunch and something will have to change in order to realize the benefits of multicore architectures. They also know that, at least for now, changes need to be based around today’s languages, flows and methods.

I believe there are three evolutionary change elements needed in the software development domain to successfully adopt and deploy multicore platforms. The first is education. There are new concepts and terminologies to be understood and assimilated, and there are best practice methods to be learnt. Education is a key pillar on which multicore migration will be based, and the work being done within the Multicore Association’s Multicore Programming Practices (MPP) working group is an excellent example of this. 

Partnerships are the second element. Mass adoption must be stimulated by efforts from all parties in the food chain, working together to build an eco-system. It’s not enough for platform suppliers to consider their work done when the silicon is defined; neither is it enough for tool providers to build solutions that don’t recognize a software developer’s typical starting point. Acknowledging and building on each other’s strengths is critical to putting together productive and relevant development environments.

The final change element is tools. The fact that multicore software exists in some of today’s products sends out a very clear message that manual approaches can work - up to a point. It is likely that these approaches are brute force efforts and not very efficient or productive. The tools that will really make an impact in this emerging world of multicore are those that deliver significant productivity gains within the context of existing development environments, languages and methods.

Let’s give the software developer a break. They didn’t ask for the burden of multicore programming. We have to recognize that migration to multicore is an industry-wide challenge, and everyone has a part to play. “Do-Nothing”, “Change Everything”, and “It’s Magic” won’t work. “Get Real” is the camp to be in, recognizing that multicore is necessary, that programming migration has to be practical, and that it will take a little effort. The good news is that pieces of the puzzle are already there, and the benefits are significant.

- David Stewart, CEO, CriticalBlue

If you missed the previous guest post, check out what John Goodacre from ARM had to say about multicore.