reddit discussion about Go turns to D again

Andrei Alexandrescu SeeWebsiteForEmail at erdani.org
Sun May 15 10:38:14 PDT 2011


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



More information about the Digitalmars-d mailing list