Threading Building Blocks and C++

By Kevin Farnham (107 posts) on July 26, 2007 at 8:20 pm

The open-sourcing of Threading Building Blocks (TBB) has inspired a lot of commentary on the Internet and also at OSCON, where I've been for the past three days. Among the initial criticisms I've read and heard is the selection of C++ as the foundational language for TBB. Some people think C++ is such an old language, perhaps a language that will soon be irrelevant. Yet, one person at OSCON quoted data that says the number of C++ developers increases each year. Other people think C would have been a much better choice than C++, because C is more ubiquitous.

I don't see anything wrong with the selection of C++ as the foundational language for a new threading library. If the goal is addressing computationally-intensive problems, C++ seems like the perfect language choice to me. C++ is perfect for making it easier to multithread legacy computational libraries of the type I've long worked with (mathematical models, physics simulation codes, image construction, etc.), which were typically written in Fortran, C, or C++. Meanwhile, the needs of modern developers of high-powered graphics-centric programs written for Windows (games, scientific and medical imaging applications, etc.) are also addressed, because so many of these programs are already written in C++. Of course, there are other types of application that can benefit from application of a C++ threading library as well.

The new-language-that-provides-parallelism approach

At OSCON I learned about some new languages that are designed from the start to facilitate parallelism. Haskell is a language that I've wondered about for a while, having seen it talked about in various places as I browsed specifically for other information. I understand it a lot better after seeing the keynote address and session given by Simon Peyton Jones, of Microsoft Research. In his presentations, Simon talked about parallelism-related extensions that are being worked on for Haskell. I also found out about the existence of Erlang, a language that supports concurrent processes, at OSCON.

I don't think there's any doubt that there will be a place in the future for new languages that are designed from the ground up for multicore processors and multiple processors within a single desktop computer, or across a network of computers. But these new languages are not an immediate solution for the immediate problems that are faced by developers of the types of application I described above. Game developers want to take their current code and have it run faster on multicore processors now. Similarly, will new languages designed on new principles be capable of addressing the task of enabling the old computational libraries written in Fortran, C, and C++ to be run in a parallel mode?

So, while new languages for parallelism are without doubt desirable, they do not as of today effectively address the problem of multithreading the very large existing base of computationally-intensive code. Threading Building Blocks is an excellent approach for addressing this problem.

Perl and other modern languages, and TBB

I like Perl a lot. I've done a fair amount of programming using Perl, including a lot of work with the POSIX module, and some experimentation with Perl XS, an interface through which Perl can call a C subroutine. I gave up on the latter before I ever mastered it because project deadlines intervened; but the idea of being able to integrate computational functions written in Fortran, C, and C++ with scripting languages like Perl and Python continued to interest me.

Today, I'd use the Simplified Wrapper and Interface Generator (SWIG) to link Perl and other scripting languages with C and C++ computational libraries (I'd wrap Fortran functions in C). In fact, I plan to start working on this very soon, adding in other languages like Python, Ruby, and Java, because I'd like to demonstrate and illustrate the integration of these languages with TBB.

But, you might ask: is such an experiment relevant? Why would (or will) anyone ever need to do that? To me, this question is related to another question: who needs more processing power on a desktop (or laptop) computer than what we have today? Taking it further: how will processing power such as in the 80-core processor Intel Reseach recently demonstrated ever be used? Isn't that inconceivable?

Who needs high-powered desktop processing?

It's actually very easy for me to think of applications for future many-core desktop computers (and other devices), not only in research and engineering facilities, but also in less computationally-driven offices, and at home. Better, faster, more realistic graphics are an obvious application. The forecasts for future technology portrayed in the movie Minority Report seem very realistic to me. There will be a day when Wii's controller is merged with video cameras and 3D image processing and a wall-sized screen to let the user select and view video as Tom Cruise and his cohorts were able to do in that movie. And everyone will have that device (or, if you don't, your kids will be moping and complaining because all their friends' families have it). I don't think that kind of imaging capability is all that far away, really. Much of it can probably be accomplished today in a research setting.

My point is: that device, which will be as ubiquitous as cell phones are today, will require a ton of processing power. A quad-core simply isn't going to cut it, especially if you want that wall-sized screen to be fully pixelated. No one has to be concerned that developing an 80-core processor is going to be a waste of effort.

Conclusion: OSCON, processors, and back to C++

For me, OSCON was enlightening. I came to an open source convention, but discussion of multicore and parallel processing was quite prevalent if you looked for it. That was a surprise. It also shows that recognition that computing is at the end of one age and the start of another is becoming widespread, at least among researchers.

Processing power on the desktop will continue to increase. No, it's not going to be used by interactive programs such as word processors. People who do that all day use only a tiny fraction of the processing power they have on today's single-core computers. N-core processors, and computers with multiple N-core processors, will definitely be desired in the home some day, that's inevitable. They may not be purchased in the form of "desktop computers" (rather, they may be integrated into individual devices), or perhaps the desktop will still exist in some form. But, they will run parallel applications, and frequently utilize as much processing power as is available...

Coming back to where we are today: is C++ a bad choice for one of the first libraries that readily enables multithreading? Clearly not, since there is an enormous amount of existing Fortran, C, and C++ code that could find application (or improved application) on the desktop if multihreading could be conveniently applied. This is one of the tasks Threading Building Blocks can address.

Kevin Farnham
O'Reilly Media

Categories: Threading Building Blocks

Comments (5)

July 31, 2007 10:48 AM PDT

Mike

I think using SWIG to connect TBB with Python and the other languages you mentioned would be awesome. I thought of doing that the first time I read about TBB last week. If I understood SWIG better, I'd take a stab at it myself. I hope you post updates about how that goes.

August 1, 2007 9:30 AM PDT

Kevin Farnham

Hi Mike. I plan to get something running using TBB and SWIG within the next week or so. In my first post, I'll outline how SWIG is applied (how to configure it, etc.) to make the connection between the scripting language and the TBB multithreaded C++ function. It's great to hear that you saw the cross-language integration potential of TBB right from the start.

August 1, 2007 8:26 PM PDT

Edin

Heh.. This is kind of funny... I just posted a comment on Robert's blog (http://software.intel.com/en-us/blogs/2007/07/27/another-voi.....mment-5098)

about my little project to write a Ruby threading module on top of TBB... and I just saw your blog.

So starting out, a couple of days ago, I downloaded SWIG and created my first C++ extension for Ruby using it. The way I see it (after a first look at it), in order to provide Ruby style API, I will implement a layer on top of SWIG generated code, which will make calls into the SWIG methods...

I am hoping to have at least some TBB API's in Ruby in a few days (unfortunately, I don't get to do this at work--I wish... so I have only evenings here and there). My next challenge (exciting! :) ) is to define some of the TBB API the Ruby way.

Cheers.

August 2, 2007 11:36 AM PDT

Kevin Farnham

Hi Edin. That sounds like a very interesting project. Do keep us informed as your work progresses. I'll be posting about my progress here; I'll probably start with a Perl/SWIG/TBB app as my first experiment.

August 29, 2008 10:31 AM PDT

dinesh

learning the languege

Trackbacks (0)

To obtain technical support, please go to Software Support.

Intel® Software Network