As computer systems with multiple CPUs become spread across the IT landscape, programmers will need a new set of development tools to take advantage of this new hardware model. This week, Intel announced a new high-level threading library aimed at software developers who are looking to exploit the parallelism of multi-core and multi-processor SMP systems. The new product, called Threading Building Blocks (TBB), extends C++ to provide thread-level parallelism for shared memory platforms based on x86 and Itanium processors. Intel also announced upgraded versions of its Thread Checker and Thread Profiler products, which will work in conjunction the new TBB product.

Intel's threading software products are part of the company's overall strategy to keep software applications in sync with the multi-core processors that are becoming mainstream in the marketplace. The chipmaker is highly motivated to make it easier for software developers to program those new chips since Intel is predicting that nearly all of the microprocessors it ships will be multi-core by the end of 2007. It's worth noting that AMD processors will get a free ride with TBB, since the x86 targeted code will work transparently with AMD's x86 offerings.

According to James Reinders, Intel marketing director for the company's Developer Products Division, his group has a fair amount of experience with multi-core and multi-processor software development, at both the very high end in high performance computing -- with some of their tools for MPI -- and in the workstation and server environments.

"That experience gives us an understanding of the challenges that the industry and we face when you look at the problem of exploiting parallelism," says Reinders. "I have no doubt that this transformation is going to happen. In fact, I'm very confident that ten years from now, virtually every programmer is going to say that they understand and think about parallelism."

But Reinders also understands there are very significant challenges that need to be understood. One of them is scalability: Can you get an 8X performance increase when you go from two threads to sixteen? Another has to do with a new set of problems that threading introduces, specifically, deadlocks and race conditions.

"The third big challenge is ease of programming," says Reinders. "Right now, some of the ways of introducing threading add a lot of complexity to a program. And we don't believe that's necessary. But it's just a fact of life when you're dealing with programming languages that haven't been extended or that don't comprehend parallelism."

C++ is one such language. TBB extends C++ via a run-time library that uses the language's template feature to abstract parallel programming constructs. The run-time library invokes the low-level thread and mutex capabilities of the target operating system to provide high-level thread management. This allows C++ developers to perform parallel programming without having to be concerned with native thread management or the maintenance of critical regions. The thread library API is portable across Linux, Windows, or Mac OS platforms (although, in version 1.0, support for 64-bit x86 is missing for Mac OS and Itanium is only supported on Linux). The TBB run-time library is royalty free, so with a single unit price of $299, ISVs can ship as many applications as they want without having to give Intel a piece of the action.

Using TBB to implement parallelism results in a much smaller amount of source code as compared to a native thread implementation. In the latter case, the application-specific algorithms can get lost in all the code devoted to thread management and breaking up the problem.

"At the end of the day, you may have over three quarters of your code devoted to managing threads," observes Reinders. "That's overwhelming. I do not believe we will succeed if we tell people that they need to write all this [code] to take advantage of threading."

The template library supplies a broad set of generic parallel algorithms -- simple ones, like fors and reduces, and more complex ones, like whiles and pipelines. The library also provides an abstraction for thread-safe containers -- data structures (e.g., hash maps, vectors and queues) that are protected from mutual access by multiple threads. This frees the developer from having to explicitly create them and then enforce their protection with mutexes. Interfaces to low-level features like atomic operations, scalable memory allocation, locks and mutexes are also supplied in the library.

"We're really able to do some incredibly sophisticated things under the hood," says Reinders. "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."

While the superiority of TBB as compared to programming with low-level Windows or Linux (POSIX) threads is fairly obvious, its advantages over OpenMP, an open standard that supports shared-memory parallelism, are more subtle. Both TBB and OpenMP provide high-level parallel programming constructs, but the latter does so via language pragmas and environment variables. Therefore OpenMP requires special compiler support. Microsoft has added support for OpenMP within the last year, but as of today, GCC still has still not implemented it in its compilers -- although the GNU community is reportedly working on it.

In contrast, the language-based approach of the TBB template library avoids the problem of third-party compiler support. That means developers can theoretically use the product with anyone's standard C++ implementation, although it has mainly been tested with the Microsoft and GNU compilers.

And there's an additional advantage to the template library model. For a variety of reasons, users often cling to older versions of compilers, upgrading only sporadically. Since TBB uses only standard C++, it can be used regardless of compiler version.

"The beauty of using templates is that they will work with all C++ compilers," says Reinders. "We're not adding a language feature that requires you to add a specific compiler. This is much easier to slip in."

And unlike standard OpenMP, TBB provides a generalized abstraction for task parallelism (task queueing). Intel has incorporated task queueing into the OpenMP implementation for its compilers, but this is not yet supported in the standard. With Intel's encouragement, this feature is being considered for OpenMP 3.0 (see the related article in this issue, "The Future of User-Directed SMP Parallel Programming").

According to Reinders, Threading Building Blocks was created to help fill in some of these weaknesses in other parallel programming models. But he doesn't envision it replacing OpenMP or even native threading programming. In fact, TBB was designed to work easily in a mixed threading model.

"We've seen some applications that use OpenMP and native threading in different parts of the application," says Reinders. "That's been something we've been careful to support. Based on that experience, we've made Threading Building Blocks so that it can coexist with these other models. To have that flexibility seems really important."

The encapsulation of all this functionality into a library offers another advantage. As processors get more cores and add enhanced hardware threading capabilities, the thread library can be retuned and optimized for the more advanced hardware. Reinders says the TBB software is designed to evolve with the hardware innovation that will occur, while providing the same level of abstraction and supporting the ability to work on older processors.

One might infer that this level of abstraction is going to exact a performance penalty. According to Reinders, this is not the case. In the example of a 2D ray tracing implementation he showed me, the high-level TBB code outperformed the native threading version, while scaling from two through eight processors. Also, it's worth noting that the TBB code maintained linear scalability through this range; the native implementation did not. Reinders surmises that the lower performing native implementation example is the result of an inefficient task queue algorithm, although optimizing it would probably increase the size and complexity of the code even more.

According to Reinders, the initial implementation of TBB will be practical for no more than 16 to 32 threads. He believes that could be extended today with additional software refinements, but hardware innovations will probably be needed to scale it beyond 128 threads.

"We think Threading Building Blocks is the right abstraction to move people into this space," says Reinders. "The proof will be a few years as we refine Threading Building Blocks and come out with new versions."