Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Re: parallel computing in C++

2 views
Skip to first unread message
Message has been deleted

Ian Collins

unread,
Apr 25, 2009, 6:01:32 PM4/25/09
to
carlosp wrote:
> I am programing something that could greatly benefit from parallel
> computing in C++, in parts of the program, where user defined classes
> are passed. I have googled but I cannot find the proper tool. Any
> experienced programmer could give me a hint, namely some good
> keywords?

You don't have a ask twice!

Look for openMP.

--
Ian Collins

Juha Nieminen

unread,
Apr 26, 2009, 6:30:53 AM4/26/09
to
Ian Collins wrote:
> Look for openMP.

This is a good tutorial for those fluent in C++:

http://bisqwit.iki.fi/story/howto/openmp/

Rui Maciel

unread,
Apr 26, 2009, 7:16:17 AM4/26/09
to
carlosp wrote:

> I am programing something that could greatly benefit from parallel
> computing in C++, in parts of the program, where user defined classes
> are passed. I have googled but I cannot find the proper tool. Any
> experienced programmer could give me a hint, namely some good
> keywords?

What's wrong with pthreads?


Rui Maciel

namekuseijin

unread,
Apr 26, 2009, 5:05:59 PM4/26/09
to

Hey, Warp! Nice to see you here... ;)

Jeff Schwab

unread,
Apr 27, 2009, 8:40:49 AM4/27/09
to

It's very low-level, and does not provide most of the tools one need for
real-world parallel processing: thread pools, data structures that
support concurrent access, etc. (I'm partial to Intel TBB.)

Rui Maciel

unread,
Apr 27, 2009, 7:18:34 PM4/27/09
to
Jeff Schwab wrote:

> It's very low-level, and does not provide most of the tools one need for
> real-world parallel processing: thread pools

Isn't that a common design pattern that is easy to implement?

> data structures that
> support concurrent access

What's wrong with mutexes and read-write locks?

Rui Maciel

Chris M. Thomasson

unread,
Apr 28, 2009, 8:22:17 AM4/28/09
to
"Rui Maciel" <rui.m...@gmail.com> wrote in message
news:49f63d4b$0$29372$a729...@news.telepac.pt...

> Jeff Schwab wrote:
>
>> It's very low-level, and does not provide most of the tools one need for
>> real-world parallel processing: thread pools
>
> Isn't that a common design pattern that is easy to implement?

Of course.


>> data structures that
>> support concurrent access
>
> What's wrong with mutexes and read-write locks?

Nothing. However, if your looking for extremely scaleable high-performance
data-structures, well... That's another story... Perhaps best discussed over
on `comp.programming.threads'.

Jeff Schwab

unread,
Apr 28, 2009, 8:58:54 AM4/28/09
to
Rui Maciel wrote:
> Jeff Schwab wrote:
>
>> It's very low-level, and does not provide most of the tools one need for
>> real-world parallel processing: thread pools
>
> Isn't that a common design pattern that is easy to implement?

Not well.

>> data structures that
>> support concurrent access
>
> What's wrong with mutexes and read-write locks?

Those are large categories of things. There are lots of different types
of locks, and some of them become performance-prohibitive when there is
too much competition for them.

Jeff Schwab

unread,
Apr 28, 2009, 9:00:21 AM4/28/09
to
Chris M. Thomasson wrote:
> "Rui Maciel" <rui.m...@gmail.com> wrote in message
> news:49f63d4b$0$29372$a729...@news.telepac.pt...
>> Jeff Schwab wrote:
>>
>>> It's very low-level, and does not provide most of the tools one need for
>>> real-world parallel processing: thread pools
>>
>> Isn't that a common design pattern that is easy to implement?
>
> Of course.

Not really. In particular, assigning tasks to threads at random kills
cache coherency and performance. You can write "a thread pool," but it
takes multiple person-months to get something competitive with COTS
solutions.

SaticCaster

unread,
Apr 28, 2009, 1:43:45 PM4/28/09
to
OpenMP Parallel Programming
http://www.viva64.com/links/parallel-programming/

Chris M. Thomasson

unread,
Apr 28, 2009, 4:13:01 PM4/28/09
to
"Jeff Schwab" <je...@schwabcenter.com> wrote in message
news:abSdnQBDqaF4YGvU...@giganews.com...

> Chris M. Thomasson wrote:
>> "Rui Maciel" <rui.m...@gmail.com> wrote in message
>> news:49f63d4b$0$29372$a729...@news.telepac.pt...
>>> Jeff Schwab wrote:
>>>
>>>> It's very low-level, and does not provide most of the tools one need
>>>> for
>>>> real-world parallel processing: thread pools
>>>
>>> Isn't that a common design pattern that is easy to implement?
>>
>> Of course.
>
> Not really.

You can create full-blown lock-based work-stealing schedulers in POSIX that
have pretty darn good scalability. Wait-free work-stealing algorithms are
another story... Here is a pretty good one:

http://groups.google.com/group/comp.programming.threads/browse_frm/thread/8ad297f61b369a41


> In particular, assigning tasks to threads at random kills cache coherency
> and performance.

That depends on several factors. Anyway, a simple way to get good cache
performance is to batch up similar actions together and execute them all on
a single CPU:

http://www.usenix.org/events/usenix02/full_papers/larus/larus.pdf


> You can write "a thread pool," but it takes multiple person-months to get
> something competitive with COTS solutions.

Sometimes. Intel TBB and Clik++ are both based on work-stealing, and those
algorihtms are not rocket science, IMVHO of course...

Chris M. Thomasson

unread,
Apr 28, 2009, 5:13:48 PM4/28/09
to
"Chris M. Thomasson" <n...@spam.invalid> wrote in message
news:gt7o07$1qgm$1...@news.ett.com.ua...

> "Jeff Schwab" <je...@schwabcenter.com> wrote in message
>>
>> You can write "a thread pool," but it takes multiple person-months to get
>> something competitive with COTS solutions.
>
> Sometimes. Intel TBB and Clik++ are both based on work-stealing, and those
> algorihtms are not rocket science, IMVHO of course...


However, COTS are OH SO CONVENIENT. AFAICT, Intel TBB is a very good choice.

:^)

0 new messages