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