Parallel programming

[Sean Kelly]

bearophile wrote:
> How much time do we have to wait to see some parallel processing features in D? People are getting more and more rabid because they have few ways to use their 2-4 core CPUs.
> Classic multithreading is useful, but sometimes it's not easy to use correctly.
> 
> There are other ways to write parallel code, that D may adopt (more than one way is probably better, no silver bullet exists in this field). Their point is to allow to use the 2-4+ core CPUs of today (and maybe the 80-1000+ cores of the future) in non-speed-critical parts of the code where the programmer wants to use the other cores anyway, without too much programming efforts.
> 
> I think Walter wants D language to be multi-paradigm; one of the best ways to allow multi-processing in a simple and safer way is the Stream Processing (http://en.wikipedia.org/wiki/Stream_Processing ), D syntax may grow few constructs to use such kind of programming in a simple way (C++ has some such libs, I think).
> 
> Another easy way to perform multi processing is to vectorize. It means the compiler can automatically use all the cores to perform operators like array1+array2+array3.
> 
> Another way to perform multi processing is so add to the D syntax the parallel_for (and few related things to merge things back, etc) syntax that was present in the "Parallel Pascal" language. Such things are quite simpler to use correctly than threads. The new "Fortress" language by Sun shows similar things, but they are more refined compared to the Parallel Pascal ones (and they look more complex to understand and use, so they may be overkill for D, I don't know. Some of those parallel things of Fortress look quite difficult to implement to me).
> Time ago I have seen a form of parallel_for and the like in a small and easy language from MIT, that I think are simple enough.

I asked for parallelization support for foreach... well, ages ago.  At 
the time Walter said no because DMD was years away from being able to do 
anything like that, but perhaps with the new focus on multiprogramming 
one can argue more strongly that it's important to get something like 
this in the spec even if DMD itself doesn't support it.  My request was 
pretty minimal and partially a reaction to foreach_reverse.  It was:

foreach( ... ) // defaults to "fwd"
foreach(fwd)( ... )
foreach(rev)( ... )
foreach(any)( ... )

Thus foreach(any) is eligible for parallelization, while fwd and rev are 
what we have now.  This would be easy enough with templates and another 
keyword:

apply!(fwd)( ... )
etc.

But passing a delegate literal as an argument isn't nearly as nice as 
the built-in foreach.  And Tom's (IIRC) proposal to clean up the syntax 
for this doesn't look like it will ever be accepted.

> Other ways to use parallel code are now being pushed by Intel, OpenMP, and the hairy but usable CUDA by Nvidia (I am not sure I want to learn CUDA, it's a C variant, but seems to require a large human memory and a large human brain to be used, while I think D may have simpler built-in things. Much more "serious" D programmers may use external libs that allow them any fine control they want). I to me they look too much in flux now to be copied too much by D.

D already has coroutines, DCSP, and futures available from various 
programmers (Mikola Lysenko for the first two), so I think the state of 
multiprogramming in D is actually pretty good even without additional 
language support.


Sean