Intel TBB vs. pthreads

[Khookie]

I'm very new to multithreaded programming, mainly due to all this
interest in multi-core processors.

I recently saw this article on Intel:

http://softwareblogs.intel.com/2007/09/19/threading-building-blocks-pthreads-and-gentoo-linux/

Is that true that pthreads is slower than Intel TBB?

I thought pthreads was lower-level than TBB, hence if someone was good
enough with pThreads, they could produce something faster than TBB.
Or am I wrong here?

Chris

[Chris Thomasson]

Post by Khookie
I'm very new to multithreaded programming, mainly due to all this
interest in multi-core processors.
http://softwareblogs.intel.com/2007/09/19/threading-building-blocks-pthreads-and-gentoo-linux/
Is that true that pthreads is slower than Intel TBB?
I thought pthreads was lower-level than TBB, hence if someone was good
enough with pThreads, they could produce something faster than TBB.
Or am I wrong here?

PThreads is a low level. It can be uses an the slow path of lock-free
algorithms

[r***@gmail.com]

Post by Chris Thomasson

Post by Khookie
I'm very new to multithreaded programming, mainly due to all this
interest in multi-core processors.
http://softwareblogs.intel.com/2007/09/19/threading-building-blocks-p...
Is that true that pthreads is slower than Intel TBB?
I thought pthreads was lower-level than TBB, hence if someone was good
enough with pThreads, they could produce something faster than TBB.
Or am I wrong here?

PThreads is a low level. It can be uses an the slow path of lock-free
algorithms

The point with TBB is that it allows to easily parallelize C++
programs, and it has a built-in scheduler which may be more effective
when having multiple tasks running at the same time: It isolates your
program from the low-level threads and may make an effective use of
them.

AFAIK, what it achieves really well is the parallelization of
algorithms like tbb::parallel_for, tbb::parallel_while. The idea is in
the same spirit of other attempts to 'automatically' parallelize STL
algorithms, such as mptl ( MultiProcessing Template Library,
http://spc.unige.ch/mptl ) , RPA ( Range Partition Adaptors,
http://sourceforge.net/projects/rpa ) and the likes.

[Chris Thomasson]

Post by r***@gmail.com
The point with TBB is that it allows to easily parallelize C++
programs, and it has a built-in scheduler which may be more effective
when having multiple tasks running at the same time: It isolates your
program from the low-level threads and may make an effective use of
them.

Humm... Are they achieving mutual exclusion on the data by using the
scheduler given that C++ has no idea that threads even exist?



[...]

Post by r***@gmail.com
AFAIK, what it achieves really well is the parallelization of
algorithms like tbb::parallel_for, tbb::parallel_while. The idea is in
the same spirit of other attempts to 'automatically' parallelize STL
algorithms, such as mptl ( MultiProcessing Template Library,
http://spc.unige.ch/mptl ) , RPA ( Range Partition Adaptors,
http://sourceforge.net/projects/rpa ) and the likes.

Yeah; it looks good for that indeed.




___P.S.___
I wonder if the new C++ Standard is going to be the _one_true_ "Thread
Building Blocks" of the near future. Interesting...

[blytkerchan]

Post by Khookie
I'm very new to multithreaded programming, mainly due to all this
interest in multi-core processors.
http://softwareblogs.intel.com/2007/09/19/threading-building-blocks-p...
Is that true that pthreads is slower than Intel TBB?
I thought pthreads was lower-level than TBB, hence if someone was good
enough with pThreads, they could produce something faster than TBB.
Or am I wrong here?

Personally, I haven't yet found any use for the TBB and continue to
prefer to do my threading "by hand". I must admit that I haven"t
benchmarked it yet, nor do I have any project in which I could use it
at the moment.

The whole idea of having a user-space scheduler is interesting in some
cases: the ones I see most are data-crunching applications. However, I
generally prefer abstracting parallelism a bit differently than TBB
does: I have a user-space scheduler that basically takes a task you
give it and performs it in the next available free core. As the tasks
I use it for are usually very data-intensive but not internally
parallelizable, which means a parallel_while or a parallel_for
wouldn't really help in most of my cases.

I guess what I'm trying to say is that any approach to "abstracted-
away" parallelism is only going to work as well as the context it is
used in allows for it. TBB will probably work very well in the
contexts it was designed for and, as I gather from following their
blog, that doesn't include the kind of applications I work on.

For the record: I principally work on a distributed architecture for a
real-time embedded system with both soft real-time and hard real-time
components. Most of my parallelism comes from having to handle
asynchronous input from devices (cameras, sensors, laser scanners and
the like) simultaneously. Therefore, I can abstract-away a lot of my
parallelism into a message-passing approach rather than a shared-data
approach, which means I only have to worry about threads where two of
them meet to exchange a message. As my applications are driven by the
input from external devices, there is no way I can "turn off" the
parallelism nor to code as if it wasn't there and have some external
library handle it for me. The only place I could do that is within the
data-crunching tasks that come with having to analyse the input of
those devices, but I already have a user-space scheduler for that.

Just my C$0.02.

rlc