reddit discussion about Go turns to D again

[Andrei Alexandrescu]

On 5/15/11 9:29 AM, dsimcha wrote:
> On 5/15/2011 10:00 AM, Andrei Alexandrescu wrote:
>> On 5/15/11 6:52 AM, Russel Winder wrote:
>>> On Sun, 2011-05-15 at 09:46 +0200, Paulo Pinto wrote:
>>>> Well, C++ already kind of has, thanks to Intel's TBB and Microsoft's
>>>> PPL and
>>>> Agents libraries.
>>>
>>> TBB is very good in terms of performance but it can be rather awkward to
>>> use. It is thought a great step forward for data parallelism is C++.
>>
>> I wonder how TBB compares to the recent Gnu parallel library
>> http://gcc.gnu.org/onlinedocs/libstdc++/manual/bk01pt12ch31s03.html.
>>
>> Now that we have std.parallelism, we should kick-off a
>> std.parallel_algorithm project building on top of it, and make it high
>> priority. Lambdas make parallel algorithms infinitely more powerful.
>
> Agreed. Let's start gathering a list of what said primitives should be.
> I don't have time to do a comprehensive std.parallel_algorithm but I
> could contribute some stuff, as well as help out with any issues people
> run into with std.parallelism while trying to do this.
>
> We already have map and reduce since in parallelism they're more like
> fundamental primitives than "algorithms".
>
> I've been prototyping parallel sorting. The obvious way to do it is to
> slice up the array into say, # of threads * 2 or # of threads * 4 work
> units, fire off a task to sort each of these, then merge the results. We
> could even template it on the base sorting algorithm. One thing I'm
> waiting on before I start implementing this is getting TempAlloc into
> Phobos so that all the temporary buffers efficiently will be easy to
> manage.
>
> Other than that, I really don't see any obvious candidates for
> parallelization in std.algorithm.

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.

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);
     ...
}

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.)


Andrei