C code in the TBB examples

C code in the TBB examples

Hi,

I was wondering why a lot of the example code is more C code than C++ code. For instance, in the reference manual, cstdio is used instead of iostream, or for the tacheon demo, the whole code is in fact C code (no object, no class, ...).

9 posts / 0 new
Last post
For more complete information about compiler optimizations, see our Optimization Notice.

Quoting - Matthieu Brucher
Hi,

I was wondering why a lot of the example code is more C code than C++ code. For instance, in the reference manual, cstdio is used instead of iostream, or for the tacheon demo, the whole code is in fact C code (no object, no class, ...).

Hi Matthieu,
I don't know a definitive answer to that question, but can speculate. First, why not? A programmer more comfortable with C can still make use of TBB, sometimes without stepping too far into the C++ zone. That could be the case for some of the examples. In other cases, I would bet that an existing serial or parallel code was implemented in C and then parallelized with TBB later. Hopefully someone who knows the history of the TBB examples can share their insight.

Cheers!
Terry

Well, I'm not a TBB developer, but the answer seems very simple - the example should be simple and dense. That's why using object-oriented programming in examples, with defining assignments, copy constructors, other constructors, etc., etc. is a bit anti-climactic. Which does not mean, it is not nice in actual projects.
C and C++ are quite similar, but for plain C is much more dense for short and simple programs.

Quoting - Bartlomiej
Well, I'm not a TBB developer, but the answer seems very simple - the example should be simple and dense. That's why using object-oriented programming in examples, with defining assignments, copy constructors, other constructors, etc., etc. is a bit anti-climactic. Which does not mean, it is not nice in actual projects.
C and C++ are quite similar, but for plain C is much more dense for short and simple programs.

Since we're in the realm of speculation, I'll speculate that the codes as originally required were probably C sources. Regardless of this provenance, they are now all C++ codes requiring a C++ compiler to handle at least their TBB-interface sections. Our purpose after all is to exemplify parallel coding practices with TBB rather than object-oriented programming practices. Maybe someday we can direct some overeager intern with time on their hands to "objectify" the plain C code, but I suspect that this would be pretty low on our priority list.

Quoting - Robert Reed (Intel)

Since we're in the realm of speculation, I'll speculate that the codes as originally required were probably C sources. Regardless of this provenance, they are now all C++ codes requiring a C++ compiler to handle at least their TBB-interface sections. Our purpose after all is to exemplify parallel coding practices with TBB rather than object-oriented programming practices. Maybe someday we can direct some overeager intern with time on their hands to "objectify" the plain C code, but I suspect that this would be pretty low on our priority list.

Robert, I agree with your view, except that a parallel_for on a concurrent vector example, or at least a std::vector, would be really nice, as it isn't trivial (and probably shouldn't be left as anexerciseto the reader either) to get a typical C++ container with iterators to work with the tbb algorithms, right now I looked again (quickly so I might have missed it, but...) and all (or almost all) the examples use c arrays.

(Removed expression of paranoia about what exactly in STL is thread safe.)

Quoting - robert.jay.gould

Robert, I agree with your view, except that a parallel_for on a concurrent vector example, or at least a std::vector, would be really nice, as it isn't trivial (and probably shouldn't be left as anexerciseto the reader either) to get a typical C++ container with iterators to work with the tbb algorithms, right now I looked again (quickly so I might have missed it, but...) and all (or almost all) the examples use c arrays.

I haven't tried yet, but from the specification it seems fairly straightforward. This way, you pass the reference to the container directly through the iterators instead of indirectly to the Body, where it would have been combined with the blocked_range values only in the application operator. Did that not work for you? Examples are always nice to have, of course.

Quoting - Raf Schietekat

I haven't tried yet, but from the specification it seems fairly straightforward. This way, you pass the reference to the container directly through the iterators instead of indirectly to the Body, where it would have been combined with the blocked_range values only in the application operator. Did that not work for you? Examples are always nice to have, of course.

I've done both and all that but I had to figure it out on my own if I remember correctly (anyways this was a way back). My issue is that new folk will also have to figure it out on their own, when an example in the Tutorial would make itundoubtedlyclear :)

For example I could easy imagine trying to fit data into a blocked range using a blocked_range(container.begin(),container.end(),100), or trying to jam a container whole into blocked_range (I think I've mistakenly done both by accident a few times too, of course neither compiles, but these two typical stl use cases fail with tbb, which is a also a first stumbling stone for seasoned C++ programmers trying to decide if they will adopt or not tbb).

It's these little details that matter a lot, because they are issues right there at the entrance. If someone doesn't feel welcomed at the door, they aren't likely to hang around to learn the ropes of the place. So I think that a bit more stl-like (notObject-Oriented examples, besides who said C++ was object oriented? It's all about generics!) use cases in the tutorials should actually be a big priority, if tbb is to gain more traction as a go-to thread library.

Quoting - robert.jay.gould

For example I could easy imagine trying to fit data into a blocked range using a blocked_range(container.begin(),container.end(),100), or trying to jam a container whole into blocked_range (I think I've mistakenly done both by accident a few times too, of course neither compiles, but these two typical stl use cases fail with tbb, which is a also a first stumbling stone for seasoned C++ programmers trying to decide if they will adopt or not tbb).

I don't disagree at all about having examples that lower the learning curve. I guess the issue with the first example is that TBB could use a tbb::make_blocked_range etc., like C++'s std::make_pair, to avoid having to be specific about the template parameters? If the second is about blocked_range(container,100), there's no substitute for looking at the documentation once in a while. :-)

Leave a Comment

Please sign in to add a comment. Not a member? Join today