This week Intel once again proved it is serious about getting multicore tools into the hands of developers. On Tuesday, the company announced it was making its Threading Building Blocks (TBB) template library available to the open source community under the GNU General Public License. The library extends the C++ language in order to make it easier to write scalable, parallel applications for multicore processor environments. Intel will still sell the TBB product commercially, as well as bundle it with their own C++ compiler.

In a nutshell, the TBB template library provides high level C++ constructs for concurrency via a task-based model. This enables developers to avoid some of the thornier aspects of parallel programming, like low-level thread management and maintaining thread-safe data. By offering platform-independent methods to express parallel algorithms, declare concurrent containers (thread-safe data objects), and do scalar memory allocations, the programmer is freed from dealing with OS-level threads, locks, and mutexs. For those who need more low-level control, TBB also offers access to atomic operations and the task scheduler. Encapsulated in the implementation is the flexibility to transparently scale the level of parallelization as applications are moved to processors with more (or fewer) cores.

While early adopters of the product were impressed by its capabilities, they also had some reservations. According to James Reinders, Intel’s director of software development products, the decision to take the year-old product to the open source community was driven by customer concerns about investing in a proprietary programming model and their desire to see the software supported on a wider range of OS/hardware platforms. Although Intel has contributed to open source projects in the past and continues to do so, this represents the first time the company has moved a commercial product into the open source realm.

The fact that Intel is willing to let its software be used on non-Intel processors is an indication of the company’s interest in the multicore ecosystem. In truth, even before it went open source, TBB could run on AMD’s x86 chips as easily as Intel’s. So taking TBB to the open source community isn’t going to give its arch-rival an additional edge. For Intel, the chipmaker with the largest share of the general-purpose processor market, the calculation is that it has the most to gain from more widespread parallel software tools. When a rising tide lifts all boats, the Queen Mary benefits the most.

Generally speaking, open source has proven to be the most effective way to spread software across hardware platforms. Currently supported on x86 (32 and 64 bits) on Linux, Windows and Mac OS, TBB will soon have source builds for G5/Mac OS as well as x86/Solaris and Sparc/Solaris 10. FreeBSD source builds are also in the works. To help kickstart the TBB open source project, Reinders says that Intel will be adding engineers to the effort.

A website for the open source project has been set up at www.threadingbuildingblocks.org. And for those who want to delve even deeper, you can now buy Reinders own TBB book — Intel Threading Building Blocks, Outfitting C++ for Multi-core Processor Parallelism. This O’Reilly Nutshell Handbook is geared for the programmer who may not be conversant in concurrent programming.

However, TBB is not an all-inclusive parallel programming model. It’s specifically designed to take advantage of a multicore-based, shared memory environments, as opposed to a distributed memory model found in cluster architectures. Intel reports early success with application segments like digital content creation, animation, financial services, electronic design and automation and design simulation. At this point, the TBB implementation can scale up to 32 cores or so, giving it at least a few years of breathing room as processors catch up. There has been some interest in applying TBB to high performance accelerators like the Cell processor, GPUs or even FPGAs. However, these DMA-based architectures, with lots of parallel units for static data parallelism, are not a great fit for TBB.

Although not suitable for MPI-based applications, if users are interested in using a hybrid approach combining MPI with node-based multicore parallelism, Reinders thinks TBB might worth considering. But even he admits that the hybrid programming model on clusters, hasn’t taken off yet due to the extra programming burden. At this point, most users are content to rely on MPI implementations that make use of node locality to optimize thread management and communication.

Looking forward to manycore processors, TBB will need to address architectural changes that will arrive when core counts start getting into the triple digits. Intel’s own Terascale program is developing processors at this scale. As the core count begins to ratchet up, designers will likely be forced to utilize non-uniform memory architectures (NUMA) to support reasonable memory access times. In order to keep the level of abstraction consistent, TBB will have to pay attention to memory locality and find a way to automate data layout for the user. Manycore architectures will also attract a more varied range of software as they become hosts for workloads that would have required an entire mainframe or cluster in the past.

“TBB is good at programs which are computationally intensive, but when you get into event-driven applications or programs with a lot of I/O, TBB is not ready for that yet, explained Reinders.” And that’s an area of interest for us, because as we get to manycore, programs will be doing more diverse things; we need to be willing to let a processor stall on I/O occasionally. We’d like to expand the programming model to support that.”