On 5/15/11 10:41 AM, Robert Clipsham wrote:
On 15/05/2011 15:43, Andrei Alexandrescu wrote:
Whoa. Did you skim the list at
http://gcc.gnu.org/onlinedocs/libstdc++/manual/bk01pt12ch31s03.html? A
_ton_ of algorithms in std.algorithms are parallelizable, and many in
trivial ways too.
I should find an excuse to use more algorithms in my apps :>
Just take std.algorithm and go down the list thinking of what algorithms
can be parallelized. I wouldn't be surprised if two thirds are.
What we need is a simple design to set up the minimum problem size and
other parameters for each algorithm, and then just implement them one by
one. Example:
import std.parallel_algorithm;
void main()
{
double[] data;
...
// Use parallel count for more than 10K objects
algorithmConfig!(count).minProblemSize = 10_000;
// Count all negative numbers
auto negatives = count!"a < 0"(data);
...
}
Automatically using a parallel algorithm if it's likely to improve
speed? Awesome. I assume that std.parallelism sets up a thread pool upon
program start so that you don't have the overhead of spawning threads
when you use a parallel algorithm for the first time?
No need. In all likelihood startup overheads are negligible for an
application that's serious about parallel use, and should be nonexistent
for an application that's not. Creating a pool upon a need basis should
be perfect.
Andrei
