Parallel programming

[downs]

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

Grow a pair and use threads. It's not _that_ hard.

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

Patched GDC supports autovectorization with -ftree-vectorize, although that's single-core.

One of the good things IMHO about D is that its operations are mostly easy to understand, i.e. there's little magic going on. PLEASE don't change that.

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

auto tp = new Threadpool(4);
tp.mt_foreach(Range[4], (int e) { });

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

Please, no hardware specific features. D is x86 dependent enough as it is, it would be a bad idea to add dependencies on _graphics cards_.

> Bye,
> bearophile

IMHO what's really needed is good tools to discover interaction between threads. I'd like a standardized way to grab debug info, like the current back trace of a std.thread.Thread.

This could be used to implement fairly sophisticated logging.

Also, what I have requested before .. single-instruction function bodies should be able to omit their {}s, to bring them in line with normal loop statements.

This sounds like a hack, but which is better?

void test()
{
  synchronized(this)
  {
    ...
  }
}

or

void test() synchronized(this)
{
  ...
}

 --downs