Why only C++

[haja_maideen]

Why this library is limited to C++, why not for other dev tools/languages?, Is it possible to port it to .NET dev languages?(C# or VB.NET)

[Alexey-Kukanov]

TBB FAQ contains the answer. I could extend it a bit with the reasons why it was decided to go with C++ first. The main reasons are: a) C++ is a popular, widely-used language; b) traditionally, CPU-intensive applications that would take most benefit from parallelismare mainly written on C/C++; c) C++ has better support for generic programming than other languages in the field (and generic programming is exceedingly important to makethe library highly customizable, efficient, and yet compiler-independent).

Nevertheless, we are interested in exploring if the parallel programming paradigm that TBB proposes can be efficiently implemented for other programming languages and/or runtime environments. And generally speaking it should be possible to "port" TBB to .NET, though I believe there are some challenges awaiting. Why wouldn't you make a try? :-)

[Kevin_Farnham]

Haja, I wrote a blog last week telling why I think C++ was a good language for TBB's starting point:

"Threading Building Blocks and C++"

Now that TBB is an open source project, where it goes next is subject to where the community would like to take it.

[uj]

Quoting - haja_maideen@hotmail.com

Why this library is limited to C++, why not for other dev tools/languages?, Is it possible to port it to .NET dev languages?(C# or VB.NET)

C#and Java already have multi-threading as an integral part of the languages. Both languages will sport "parallel extension packages" inupcoming versions supportingfine-grained threading similar to that ofTBB.

[Anton_Pegushin]

And the most interesting part of this thread for me is that it managed to hit almost 1600 views in just two days. This can be an indication that the community is curious why C++ was chosen in the first place or if TBB developers are looking into porting TBB to some other language/environment.

I'm thinking Alexey gave a pretty good answer to why C++ was chosen initially, right?

So if I could, I would like to encourage everyone to post questions, comments or even better reports on the activities taken in order to port or use TBB in the officially unsupported platforms, environments.

Thanks!

[Alexey-Kukanov]

Quoting - Anton Pegushin (Intel)

> the most interesting part of this thread for me is that it managed to hit almost 1600 views in just two days.

I am sorry to disillusion you, but have you looked at the date of the first post? :)

[jimdempseyatthecove]

Quoting - Alexey Kukanov (Intel)

TBB FAQ contains the answer. I could extend it a bit with the reasons why it was decided to go with C++ first. The main reasons are: a) C++ is a popular, widely-used language; b) traditionally, CPU-intensive applications that would take most benefit from parallelismare mainly written on C/C++; c) C++ has better support for generic programming than other languages in the field (and generic programming is exceedingly important to makethe library highly customizable, efficient, and yet compiler-independent).

Nevertheless, we are interested in exploring if the parallel programming paradigm that TBB proposes can be efficiently implemented for other programming languages and/or runtime environments. And generally speaking it should be possible to "port" TBB to .NET, though I believe there are some challenges awaiting. Why wouldn't you make a try? :-)

Alexey,

The support of generic programming by C++ outweighs all the other reasons by at least an order of magnitude. The effect of generic programming is to introduce essentially what ammounts to a new language (or at least language features). The most fundimental feature of C++ that permits this is the support of templates.

I have been looking at this problem as it relates to Fortran with a threading tool that I have developed and have concluded to do a rather good port, one where the Fortran implementation does not induce an undue programming burden, that Fortran will require template capabilities. The best place to introduce templates into Fortran would be in the compiler itself (as it has access to the variable type information). Not having access to the compiler, the approach I am left with taking is to modify the FPP, most likely as a shell, to process the templates in addition to the FPP modifications.

Are you aware of any template implementations used by Fortran programmers?

Jim Dempsey

[Alexey-Kukanov]

Quoting - jimdempseyatthecove

> The support of generic programming by C++ outweighs all the other reasons by at least an order of magnitude. The effect of generic programming is to introduce essentially what ammounts to a new language (or at least language features). The most fundimental feature of C++ that permits this is the support of templates.

Here I fully agree with you, Jim. C++ templates is what allowed us to efficiently implement a kind of small domain-specific language; I mean TBB generic parallel algorithms.

The interface to the core TBB scheduler does not require templates; though such C++ features as classes, inheritance, and virtual methods are used. But those could be either emulated in C, or not used; so the core TBB scheduler could be implemented in C. But always dealing directly with tasks would probably cause roughly the same level of parallelization pain as with using threads.The expressive power and ease of use comes with TBB parallel algorithms, which are mostly templates.

> Are you aware of any template implementations used by Fortran programmers?

I am not aware of any;but it means nothing, because I am not a Fortran user and do not keep track of what exists in its field.

[uj]

If the idea was to start out with C++ and then continue with other languages, then the decision to base TBB so heavily on generics must be considered a mistake. This means that for TBB to be fairly easy portable to other languages there mustalso be a more traditional procedural version of the TBB libraries. Or as an alternative TBB is introduced as a language extensions. Then is added the burden ofmaintaining precompilers for different languages.

Introducing TBB in the land of "managed" languages will be an uphill struggle. Both Java and C# have multithreading already built into the languagesand packages to support fine-grain parallelisms are in the pipeline. Especially Microsoft seems quite aggressive about this which much support for parallel programming in VS2010. Also for native C++ programming actually, so there's increased competition for TBB there.

[Alexey-Kukanov]

Quoting - uj
> If the idea was to start out with C++ and then continue with other languages, then the decision to base TBB so heavily on generics must be considered a mistake. This means that for TBB to be fairly easy portable to other languages there mustalso be a more traditional procedural version of the TBB libraries. Or as an alternative TBB is introduced as a language extensions. Then is added the burden ofmaintaining precompilers for different languages.

As I wrote above, it would not be too hard to make C interface to the scheduler itself, with further possibilities to bind it to this or that language. But the algorithm interfaces would need complete rehaul for near every language, I guess. C++ templates allow achieveing great flexibility; TBB functions can be applied equally to a wide range of problems while the compiler takes care of type safety and optimization. For languages that do not support some kind of generics, this is hard to achieve; I guess type safety would be the first thing to drop.

> Introducing TBB in the land of "managed" languages will be an uphill struggle. Both Java and C# have multithreading already built into the languagesand packages to support fine-grain parallelisms are in the pipeline. Especially Microsoft seems quite aggressive about this which much support for parallel programming in VS2010. Also for native C++ programming actually, so there's increased competition for TBB there

I agree with you. After 1.5 years since TBB 2.0 was released (and my first reply in this thread was written), the landscape changes, especially in .NET with new MS initiatives (TPL, PLINQ etc).