Re: [boost] Is there interest in parallel versions of <algorithm> functions?

From: Cory Nelson (phrosty_at_[hidden])
Date: 2006-06-16 19:18:24

On 6/16/06, Matt Calabrese <rivorus_at_[hidden]> wrote:
> >
> >
> > I can't say that I agree with your conclusion that parallel algorithms
> aren't very useful for general applications nor that manually multithreading
> applications is the best option. On the contrary, I think it's going to be
> very important that the average programmer has high-level generic tools for
> working with parallel algorithms for even seemingly trivial applications in
> the not-too-far future.
>
> Coincidentally, my summer of code project for Boost, Boost.Act, is all about
> parallel algorithms along with active objects and simple asynchronous
> function calls. You can see the full proposal at
> http://2006.planet-soc.com/node/201 . Be sure to check out the included
> preliminary documentation for code samples and rationale. Right now, in
> terms of the algorithms side of the project, my library just allows you to
> easily work with a few common algorithms such as for_each, copy, generate,
> and fill, with the execution model able to be toggled via policies, though I
> plan to have all or nearly all standard algorithms implemented by the end of
> the summer. At this point in time I do not have any plans for parallel
> containers for the immediate future, but once everything else is completed,
> I would definately like to pursue them as a next step.
>
> Currently, my library is implemented using a combination of
> Boost.Threadsand OpenMP. I've read up a bit on STAPL thanks to this
> thread and I'm
> looking into the possibility of using it internally in future versions of
> the project, pending their willingness to release the source.

While we are on the subject- is there any interest in a scalable
lock-free data structures library?  I have some code that works in x86
and x64 w/ vc++7.1 and gcc 4.1, but I'm not familiar enough with other
compilers/architectures so I'd need some help with implementing them
(should be very easy).

This would include thread-safe versions (which do not use a mutex) of
a stack, queue, some simple freelist memory pools, and maybe a linked
list.

-- 
Cory Nelson
http://www.int64.org