Parallel programming for realists

By David Stewart |  No Comments  |  Posted: September 1, 2008
Topics/Categories: Embedded - Architecture & Design  |  Tags: , ,

Sharing industry-driven best practices in parallel programming is the only way to unlock the benefits of efficient use of multicore silicon platforms and dramatically increase their rate of adoption.

It is now widely agreed that the largest single brake on the adoption rate for multicore platforms is the ability of software developers to program them. Much has been written about the many different ways in which this can and will be addressed, but the industry is not about to stand still and wait for an all-encompassing solution to emerge.

There is already some parallel software running on multicore platforms within many of the day-to-day electronic gadgets that we take for granted. The immediate issue surrounding the creation of multicore-ready software is not if it can be done, but how quickly, efficiently and painlessly it can be done within constraints set by existing tools. Ever since the power consumption issue forced hardware developers down the multicore path, programmers have been creating the best parallel software they can with the techniques and tools available to them.

The current state-of-play might therefore be summed up in pretty straightforward terms: if you have been writing parallel code for a while, then you have probably made most of the mistakes you typically can make, and taught yourself how to avoid them; if you are just starting your parallel coding effort, you have some pain ahead of you. But let’s take a step back. The market is tough and companies need to differentiate themselves from their competitors. We all understand that. However, since every company appears to be facing the same challenges in getting their developers ready to effortlessly write quality parallel code, there would seem to be a perfect opportunity for collaboration.

The reality is that each medium-sized to large company has a virtual pyramid of software developers. A few at the top understand the challenges of multicore software development and have developed pragmatic methods, largely through trial and error, that ‘get the job done’. Unfortunately, they probably have not documented any of these methods. In the middle of the pyramid there is a fair-sized group of developers who are ascending the multicore programming learning curve. They now understand the basic principles, but still have a lot more to learn. The final group, at the foot of the pyramid, contains the majority of developers. They are most likely eyeing this problem space with some trepidation because they believe their next project will require parallel programming and they are not yet up to speed on what that will entail. The latter two groups will learn from their mistakes as they make them and eventually work their way up the pyramid, but some emphasis here needs to fall on eventually.

Given that parallel programming for multicore is an area where no company yet stands out as having a longterm solution to the problem, the logical conclusion is that the current challenge lies in giving software developers the skills and knowledge to get the job done using existing infrastructure. Not only would this benefit software development by allowing projects to keep more closely to schedule, it should also stimulate the overall multicore silicon market. A classic win-win.

These observations, among a few others, led me to propose the formation of the Multicore Programming Practices (MPP) working group under the auspices of the Multicore Association. When the association approved my proposal, Max Domeika from Intel agreed to co-chair the group. The idea behind this initiative is to provide hardworking developers with some well-grounded guidelines based on the experiences of other engineers who have learned how to write parallel software the hard way. The working group is already pursuing its goal. Its first face-to-face meeting was attended by 15 companies in early June. The work has continued since then and we are formulating an outline for our best practices guide, a standard method of illustrating such practices through code examples, and a distilled list of the top multicore programming issues that we will cover.

There is still a lot to do, and while we have a core group of willing volunteers, we can always accommodate more. So, if you are an experienced multicore software developer, why not get involved and share your experiences with the rest of the group – and ultimately the industry at large? Or if you are a software developer facing that arduous climb up the parallel programming learning curve, or one who would just like to network with experienced multicore software developers, you are also more than welcome. Signing up is easy and you can find all the information at the association’s website. I believe this is a real opportunity to contribute to an effort that will have short-to-medium term but vitally needed benefits across our entire industry. It specifically addresses a clearly identified bottleneck preventing the mainstream use of multicore architectures across a range of applications. Imagine how good it will feel to be part of the initiative that overcomes that challenge? Well, you do not need to imagine it. There is plenty of room at the table.

David Stewart is the CEO of Critical Blue and co-chairs the Multicore Association’s working group on Multicore Programming Practices with Max Domeika of Intel. More information on the initiative, including details on how to join, is online at

The Multicore Association

Pretty much everyone now accepts that multicore technology is here to stay. Furthermore, processor and third-party tool vendors acknowledge that a huge financial opportunity awaits them in developing tools, services and other products that facilitate the adoption of multicore technology. In a sense, this feeding frenzy has the potential to bring about extreme chaos as each vendor scrambles to gain competitive advantage. On the other hand, system developers are looking for aids that will not lock them into a specific vendor’s product.

This is where the value of industry standards comes into play. Several years ago, a few industry constituents addressed the idea for a consortium that would derive multicore-specific standards to support system developers and the entire ecosystem. This has since become the Multicore Association.

During its first two years of existence, the consortium developed an API in support of high performance, low latency inter-core communications. This specification, MCAPI, helps software developers build applications that can run on a wider variety of multicore architectures, enlarging their design options and minimizing the amount of time spent porting and tuning applications for different implementations.

With MCAPI completed, the consortium has turned its focus to three other working group charters. The main article considers the Multicore Programming Practices group. A second is the Multicore Resource Management API working group (MRAPI). Its goal is an industry-standard API that specifies essential application-level resource management capabilities needed to coordinate concurrent access to system resources. Resource management is a crucial capability for high-performance embedded systems, yet there is currently no suitable standard solution in the embedded application space.

The third working group is working on a variety of areas that support hypervisor portability and associated multicore capabilities with a focus on communications, resource management, load balancing, and debugging APIs. Virtualization software in the form of hypervisors is rapidly becoming very popular in the embedded world, yet here also the industry lacks standards.

Comments are closed.


Synopsys Cadence Design Systems Siemens EDA
View All Sponsors