If there is anything that will slow down the multi-core juggernaut, it is the lack of software that will run on them. While commodity multi-core chips are well-know fixtures in servers and high performance computers, the highest volume markets, represented by the desktop and laptop segments, are just now getting used to the idea of dual-core processors. Within a relatively short period of time, multi-threaded software has become everyone's problem.

Intel has a huge stake in making sure future software follows the multi-core model. By the end of next year, the majority of processors shipped by the company will be either dual-core or quad-core. Commodity processors with eight cores and above are already being conceived. Intel can't afford to have all those extra CPUs just spinning with nothing to do. So part of the company's mission has become to convince software developers to "think parallel."

The HPC community has recognized the problem for years. In 1999 during an OpenMP presentation at the Supercomputer Conference, one of the introductory slides stated: "The benefits are clear. To increase the amount of parallel software, we need to reduce the perceived difficulties." Seven years later, the benefits of parallel programming and the perceived difficulties have been extended to the entire IT community.

But Intel is not going to rely on the HPC crowd to drive the paradigm shift of parallel computing into the larger IT community. Supercomputing, while important to Intel, is not perceived as a software technology driver by the company. Back in April, when I spoke with Justin Rattner, Intel's chief technology officer, he had this to say:

"A few years ago, when Intel asked me to look at what we should be doing in HPC, I was struck by how little progress had been made on the programming front. That's my big disappointment. The technologies that were popular a decade or more ago are still in widespread use today. We're still programming in MPI and still working on technologies like OpenMP. I had hoped and expected that after a decade or more we really would have made some fundamental advancements on the software side.

"I think that HPC probably won't drive the fundamental advancements in parallel programming. I think it had that opportunity, but that window of leadership is rapidly closing. The advent of multi-core processors in the high volume spaces is probably going to do more. It's certainly going to attract a lot more investment in creating powerful solutions to the programming problem -- largely out of necessity. If these new architectures are going to be successful, a lot of people are going to have to program them and they're not going to be satisfied with the kinds of tools available in HPC today."

Part of the effort to get developers used to the idea of parallel programming involves education. Earlier this month, Intel announced a worldwide effort to prepare university students for the new multi-core paradigm. Intel will provide expertise, funding, development tools, educational materials, on-site training and collaboration to 45 top universities to incorporate multi-core and multi-threading concepts into their computer science curricula. Related to this, the company has even developed its own software college (information online at http://or1cedar.cps.intel.com/softwarecollege/), a kind of global extension program for programmers.

Intel is also taking a more direct approach to encouraging parallel programming by delivering multi-threading developer tools, such as OpenMP-capable compilers, VTune, Thread Checker and Thread Profiler. This past Monday, Intel introduced a new software package, Threading Building Blocks (TBB), a threading library for C++ developers. I talked to James Reinders, Intel marketing director for the company's Developer Products Division, about the new software and wrote about it in this week's issue.

From what Reinders told me, Threading Building Blocks is targeted for the same types of systems as OpenMP, namely shared memory SMP systems. TBB's main advantage over OpenMP is that it doesn't require a special compiler, since it relies on standard C++ templates, rather than special language pragmas, to implement its parallel constructs. TBB also provides abstractions for task parallelism (being considered for OpenMP 3.0) and critical regions.

And, since the template library provides a more straightforward way to extend language features, it offers programmers more flexibility. The OpenMP pragma-driven model is certainly powerful, but compiler directives are a questionable way to make significant extensions to language functionality. On the other hand, OpenMP has other things going for it: It is an open standard, is portable across multiple languages (C, C++ and Fortran) and already enjoys some market penetration. The OpenMP language committee is in the process of designing version 3.0 of the specification. Read more about some of the issues being discussed in this week's feature article, "The Future of User-Directed SMP Parallel Programming."

Intel already has an investment in OpenMP in its own compilers and has even produced a Cluster OpenMP version for distributed memory systems. The company designed the TBB library to coexist with OpenMP, as well as native threading code, within the same application. So rather than competing with OpenMP, Reinders characterized the TBB product as filling in some of the gaps.

What Intel would really like to accomplish is to wean developers away from native Windows and POSIX threading, a low-level approach to parallel programming that the company views as counter-productive. There's no reason to have thousands of developers devise their own thread management schemes. Not only is re-inventing the wheel time-consuming, it's also error prone. Reinders makes a good case that the sort of high-level threading model encapsulated in the TBB template library is the way to go. Says Reinders:

"We're really able to do some incredibly sophisticated things under the hood. And if you really want to get a scalable threaded application, you need to do these things. But I would not want to try to educate everyone how to write these; or even if I educated them, I wouldn't want to suggest that everyone should spend their time writing wonderful core threading capabilities like task queuing and stack management. Having them written for you and be part of the language is exactly the right thing to do."

Lest you think he is just pushing the company line, here's what Reinders had to say in "Programming for Concurrency: New Tools Arrive" on the Dr. Dobbs Journal site:

"If you don't like what Intel has to offer, please find something else. But try to avoid writing the native threads. You'll waste time and you won't end up with a scalable application."

-----

As always, comments about HPCwire are welcomed and encouraged. Write to me, Michael Feldman, at editor@hpcwire.com.