Threading Building Blocks and Parrot: Initial Investigation

I've spent some time investigating the possible methods for making code that implements Threading Building Blocks available to developers of scripting languages like Perl, Python, Ruby, along with many other possibilities including Java and the .NET family. In my initial experiments I worked with the Simplified Wrapper and Interface Generator (SWIG).

Last night, on the #tbb IRC channel (on the Freenode network), there was a lot of discussion about the possibility of employing Parrot as an interface between a broad spectrum of languages and C++ libraries that have been multithreaded using Threading Building Blocks. Parrot had been mentioned to me a while back on the channel, and I'd taken an initial look; but what I found out last night and in this morning's research makes Parrot seem worthy of much more investigation in this regard.

What is Parrot?


Parrot is (quoting from the ParrotCode.org front page):
a virtual machine designed to efficiently compile and execute bytecode for dynamic languages. Parrot currently hosts a variety of language implementations in various stages of completion, including Tcl, Javascript, Ruby, Lua, Scheme, PHP, Python, Perl 6, APL, and a .NET bytecode translator.

Among the languages listed above, we don't see C++. But, when you go to the Parrot Language Implementations page, you do see c99.

Parrot, C++, and C


Parrot is an open source project; hence, we're all free to suggest enhancements, and work on implementation -- in case someone would like to take up the challenge of bringing C++ support into Parrot. An implementation of generalized support for C++ doesn't sound like an easy task to me, though. I say this in part based on my study of SWIG. SWIG includes some C++ support, but... Well, C++ is an unusual language. For example, through templates it can be turned into almost anything you want it to be. For example, highly templated C++ code can be virtually unrecognizable and unintelligible to a developer who is expert in C, C++'s original base.

My guess is that it will be easier to integrate Parrot and TBB C++ libraries on a case-by-case basis, using C as glue between Parrot and the C++. I've seen (and heard on the channel) about integration of the Qt Framework (a C++ class library) with Parrot via C. So, linking Parrot and C++ libraries apparently has been successfully accomplished already.

The Parrot Native Call Interface (NCI)


Parrot includes a Native Call Interface (NCI):
The NCI is designed to allow Parrot to interface to most of the functions in a C library without having to write any C code for that interface. ... Using the NCI, parrot automatically wraps the C functions and presents them as prototyped subroutines that follow normal parrot calling conventions, and can be called like any other parrot subroutine.

Hence, if we can wrap C++ libraries threaded using TBB, then the Parrot NCI should make it possible for all the languages that have Parrot support to call those libraries. Then, high level scripting languages such as Ruby, Python, and Perl will have convenient access to computationally-intensive libraries that have been threaded for optimal performance on multicore processors.

This indeed sounds promising!

Kevin Farnham
O'Reilly Media
TBB Open Source Community
For more complete information about compiler optimizations, see our Optimization Notice.