reddit discussion about Go turns to D again

Robert Clipsham robert at octarineparrot.com
Sun May 15 08:41:07 PDT 2011


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/


More information about the Digitalmars-d mailing list