From: Clint Levijoki (clevijoki_at_[hidden])
Date: 2006-06-16 17:39:02
OK, I have done a lot more work and unfortunately I don't think that the
parallel containers/algorithms idea is very useful outside of very specific
applications, and in those applications it's easy and clearer just to make
your program multithreaded manually.
I can still post what I came up with if anybody is interested but I don't
see much future in it.
The problem is that timing issues between threads are just too great to
overcome. It takes longer for the computer to resume from a
boost::conditional wait than it does to search through a million intergers.
Also I would like to vote that some easier way of sleeping is put into
boost::thread, right now it is too awkward to use.
On 6/10/06, Clint Levijoki <clevijoki_at_[hidden]> wrote:
> Thanks for the link, they have some brilliant ideas. I will have to do
> some thinking on things, after more testing my initial task_master idea is
> only beneficial for very narrow type of calculations.
> The idea of parallel containers sounds like it could solve a lot of the
> issues I am having.
> On 6/9/06, Benjamin A. Collins < ben.collins_at_[hidden]> wrote:
> > On Thu, Jun 08, 2006 at 03:53:46AM -0600, Clint Levijoki wrote:
> > Hey all,
> > This is actually a 2 part interest inquiry:
> > 1. I think there could be some usefulness in parallel versions of the
> > algorithm functions, like for_each and find and unique_copy.
> > 2. In the couple days of r&d I have come up with a class named
> > parallel_task_master which runs a thread function many times over and
> > manages them so you keep your thread counts low and working as hard as
> > possible. So if you have a quad-core cpu it can be specified so you
> > go over a 4 thread limit. It's also setup so you can keep adding tasks
> > recursively and it will keep the thread count fixed and never deadlock.
> > Because the tasks in parallel_task_master run relatively in order, I
> > some sort of queue could be made to parallelize functions that needed to
> > return output in a serial form. So it could be used to decode video
> > packets for example.
> > This parallel_task_master in itself may have some value alone, but it
> > written to assist in creating parallel version of the functions in
> > <algorithm>. Some of them are not so parallelizable, some are
> > embarrassingly so.
> I think this could be interesting. My there is a research group at
> alma mater that deals with parallel algorithms and such, and has a
> project along these lines. I know the people involved (some of them),
> but I don't know if they'd be willing to share project sources. I
> suspect that they would. Either way, the papers are published and you
> may find them useful. Note that Bjarne is one of the faculty members
> involved in this project.
> Go here to find out about STAPL (Standard Template Adaptive Parallel
> Benjamin Collins <ben.collins_at_[hidden] >
> Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
> - Clint Levijoki
> "I'd rather have a bottle in front of me than a frontal lobotomy" - Tom
-- - Clint Levijoki "I'd rather have a bottle in front of me than a frontal lobotomy" - Tom Waits
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk