I have some interesting data from the front lines of parallel programming to share.

It is common wisdom that parallel programming is hard. I'm an optimist who does not believe it has to be that way, but also a realist who agrees that it requires change which is slow in coming.

I have spent hours reading and hearing pitches on the advances needed to programming languages to make them more suitable for parallel programming. I divide such conversations into two categories: one, high level abstractions that actually make parallel programming easier, and two, critical and essential low level tweaks that make it possible to build the former. I love both types of discussions, but any time I'm in discussions of the work to do in category two, I walk out wondering if there is any hope at all to make progress on category one in our lifetimes.

Fortunately, I have real data that we are making considerable real-world progress. I say fortunately because it helps me survive category-two meetings.

Last year, we did a survey of projects we believe are among the movers and shakers in software development. It includes hundreds of applications and companies around the globe.

We asked two questions:

1. If you added parallelism to your serial application, how did you do it?
2. If you didn't add parallelism to a serial application—why not?

If you added parallelism to your application, how did you do it?

Remembering my strong contention that we need "high level abstractions that actually make parallel programming easier", I cringe when I see the answer to parallelism being raw threads (pthreads, Windows threads, Boost threads, Java threads, etc.).

A pleasant surprise was that only 50% of projects we surveyed still went that route. The other 50% found a higher-level abstraction, as follows:

• 19% Intel Threaded performance libraries (MKL or IPP)
• 17% OpenMP
• 6% Threading Building Blocks
• 3% Threaded libraries (other than ones from Intel)

Using threaded libraries, OpenMP and Threading Building Blocks are exactly the higher-level programming models I see as most available and usable today. Developers appear to agree.

These higher-level programming models let a programmer focus more on writing code and less on the low-level details of the hardware. At the same time, they tend to show excellent results on scaling and make debugging the application bearable. Use of raw threads makes scaling and debugging a larger challenge and one demanding expertise, time and patience. Even when you have the expertise, the time and patience can be most difficult to manage.

I'm excited to see developers up to 50% abstraction usage. This is much higher than what we believe to have been the case only a few years ago. And I expect the trend will continue, much like the trend to leave assembly-language programming behind started decades ago and ended in the 1990s when even gamers and operating system developers abandoned any significant amount of assemble language coding. Higher-level programming languages are more portable and debuggable than assembler. And so it is with parallel programming as well.

If you didn't add parallelism to a serial application, why not?

For those not using parallelism yet, a surprisingly small 27% were willing to say they don't yet think adding parallel programming is needed. The other responses were:

• 55% No time to fit adding concurrency into project schedules
• 14% Concurrency is too technically difficult
• 5% Other or unsure

At the very least, the majority of development teams now find it unfashionable to say they won't be adding parallelism. My more direct experience tells me that developers are serious about adding use of parallelism, but it is now one of many things on their wish list for development that has to compete with other features and ideas. So adding parallelism is now elevated to a planning issue. Of course, we still need the abstractions so that when things are planned they can be done!

These trends are interesting—and put all the more pressure on tool vendors to be up to the task to support the move to parallel programming.