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?
A user-level program could import std.parallel_algorithm and
std.algorithm, and choose which version to use by simply qualifying
function calls with the same signature. (That's also why we should think
of a shorter name instead of parallel_algorithm... and with this
parenthesis I instantly commanded the attention of the entire community.)
I'll give my +1 to bearophile's palgorithm unless something better appears.
Andrei
--
Robert
http://octarineparrot.com/
