reddit discussion about Go turns to D again

[dsimcha]

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.