4,391 Posts served

10,712 Conversations started

TBB is part of the concurrency revolution

By David Mackay (Intel) (15 posts) on September 19, 2008 at 3:40 pm

In my first blog that I said I would blog mostly about threading and performance. This time I am writing about TBB or Intel® Threading Building Blocks. But let me begin by discussing the multi-core transition. Several years ago Intel began shifting to multi-core platforms. This was a shift for Intel (you may remember we called it the right hand turn). We knew it would be a shift for developers too. We began improving and adding more to our software development products for threading. Others in the industry wrote about the change. Herb Sutter wrote several articles. I will reference two of them. One was entitled "The Free Lunch is Over." The point is that performance was no longer going to come from increasing processor clock speed and developers have to actively develop differently to gain performance on the new world of multi-core platforms. Yes, the world is changing and in addition to doing everything we were doing before – now we all get to think about concurrency in order to get performance. Some of my colleagues at Intel liked the article quite well and liked to use this as an introduction to conversations about changes in software development. Yes, software developers relied on faster processor clock speeds for performance improvements, but software development is a competitive environment, and developers work very hard. They never felt like they were getting a free lunch or a free ride. Telling them there is more to do now, didn't seem like a value proposition to me.

Does it mean there is more for software developers to do now? Maybe (undoubtedly there are more ways to make mistakes)? Is it a lot more to do or are there different ways to do things? This is why I preferred to refer to another of Herb Sutter's article where he called the changes going on a concurrency revolution (see http://www.ddj.com/architect/191800187). I used to have a copy of the last couple of paragraphs from this article taped to the outside of my cubicle wall (when we moved around it went away and I did not repost it). I quote a couple of sentences from his article: " Yes, this is a wonderful time to be a software engineer. For the rest of this decade and into part of the next, we're going to do for concurrency what we did for objects and garbage collection: ..."

Rather than thinking of working for lunch now, I like to think of being on the forefront of a transition or revolution (Yes, I like parallel programming. That is what I was doing when I joined Intel in 1992 and when I had a chance to do it at Intel again I took it). There was a big shift years ago to object oriented programming. There is a shift now to concurrency. Did the shift to object oriented programming mean more work than procedural programming styles? I don't think so. But if you had a lot of legacy code the transition wasn't free. Likewise, the transition to concurrency allows for more complexity, and can be more difficult. If we don't design well and use the best tools, we can run into paralyzation instead of parallelization. If we design well and use the best techniques we can minimize the complexity.

One of the reasons Intel created the Threading Building Blocks is to provide an abstraction for threading that provides good performance and removes the developer from the tyranny of trying to explicitly create and manage all of the threads. The developer can focus on the parallel tasks and templates and allow the runtime library to manage scheduling and management of the threads. We also wanted something that was evolutionary – something that works in an environment that is familiar to developers without requiring them to learn a new language or use a special compiler. C++ templates fit that perfectly. We wanted this to help drive a change in the way developers think and develop – that is make thinking parallel a natural part of software development – so we released this as an opensource project (threadingbuildingblocks.org).

We have seen great responses from and adoption by many ISVs (e.g. Autodesk Maya http://softwarecommunity.intel.com/isn/downloads/softwareproducts/pdfs/Brief_TBB.pdf). When my team of engineers visits software developers we sometimes get the response –" that is exactly what I need (parallel pipeline, or concurrent hashmap, or...), Threading Building Blocks will be easier for me than me implementing that by myself, I will just adopt Threading Building Blocks for that". Yes we sometimes meet developers who say, I have already implemented threading with native Windows threads or Posix threads and don't want to change.

One way to look at how the environment is changing is to look at not just how the development community picks up Threading Building Blocks beyond the platforms we developed it on. One of the more recent announcements though was adoption of Threading Building Blocks by Deep Shadows. Now their port was not an academic exercise of will this work well enough to run a benchmark. They wanted to use this in their product (see http://www.developmag.com/news/30160/Deep-Shadows-talks-multiprocessor-optimisation). One of the platforms they develop for is the Xbox game console. By completing a port of Intel Threading Building Blocks to Xbox they can get the parallel performance they want and maintain a more common code base between Xbox and PC versions of a game. They generously contributed that back to the threading building blocks community. Because of their contribution any Xbox developer can download the threading building blocks source to use threading building blocks on Xbox. This is not the only port that the community has contributed. Others have contributed ports for PowerPC Linux.

This summer we launched Intel® Threading Building Blocks 2.1. This included several improvements to increase performance and to clean things up. Several new items were added in response to feedback we received in the Threading Building Blocks forum – for example parallel_do. We appreciate the response and feedback we receive in the threading building blocks forum and in our face to face visits with software developers.

Herb Sutter wrote in the article I referenced above that "The world awaits." Let me ask what are you waiting for? If you are not threading for performance now, what types of abstractions or development products are you looking for or waiting for? What else belongs in Intel Threading Building Blocks? What do you want in the developer's toolkit that is not available now?

Categories: Open Source, Parallel Programming, Software Tools
Tags: TBB

For more complete information about compiler optimizations, see our Optimization Notice.

Comments (3)

October 2, 2008 6:37 AM PDT Dmitriy Vyukov Total Points: 43,814 Black Belt

I'm not sure I get last paragraph. Do you mean that TBB provides everything developer can want? TBB can help *ONLY* in very narrow segment - high performance computations. And we have a number of tools in that segment already - OpenMP, MPI, Cilk etc. TBB can NOT help developer with network servers, application servers, client software, middleware etc. And we are waiting for tools which will be able to help us with other kinds of software.

October 29, 2008 5:22 PM PDT David Mackay (Intel) Total Points: 2,136 Green Belt

My apologies for the late response to your comments on my blog. You refer to several different parallel programming models – OpenMP and MPI. I don’t feel either of these bear comparison to Intel Threading Building Blocks. OpenMP is a fine standard. It is relatively clean and straightforward. The new task queuing capabilities added in 3.0 are a significant extension to the types of parallelism that can be implemented with OpenMP. However, for many C++ codes OpenMP is really insufficient. OpenMP is object ignorant. It doesn’t handle objects well and there are many parallel patterns that can not be implemented with OpenMP in C++. I began parallel programming with message passing libraries. MPI is far better than the proprietary message passing libraries it replaced (I wish I had communicators 2 or 3 years earlier). MPI requires a developer to explicitly manage all the data, placement of tasks – it is just like using native Windows threads or Posix threads. One of the goals of Threading Building Blocks is to allow the developer to think about parallelism at a higher level (e.g. pipelining) and allow TBB to handle the details of managing the threads and such (MPI doesn’t free a developer from the details). A developer should think parallel. A developer should understand data flow and dependencies. These are critical for developing scalable software. Threading Building Blocks allows a developer to express many parallel algorithms in a natural C++. Threading Building Blocks provides basic parallel operations like pipelines, parallel_for, parallel_while, parallel_reduce, that can be standardized across development teams. Threading Building Blocks is designed to work as well for client software as it does for computationally intensive software. It provides much more power than OpenMP and the abstraction it provides to ease development work is leaps and bounds beyond MPI.

November 26, 2008 11:39 PM PST Dmitriy Vyukov Total Points: 43,814 Black Belt

Well, yes, OpenMP, MPI and TBB are quite different. But my main point was that they all are for HPC (i.e. computations). And, let's say, no more than 25% of developers are dealing with computations. And what about the rest 75%? They are still waiting for something.

Trackbacks (0)

Leave a comment