www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.announce - Parallel Programming

reply Pablo Ripolles <in-call gmx.net> writes:
Hello,

as many of you have already read, there is an ongoing discussion about the
different paradigms/environments/approaches of parallel programming,
particularily aimed towards how to exploite the evenly more common multi-core
processors.

http://www.artima.com/weblogs/viewpost.jsp?thread=214627
http://blogs.intel.com/research/2007/10/parallel_programming_environme.html

I'd like to hear about D community point of view!  Is the std.thread our
solution? Is there anyone expecting or following another approach?

Thanks!
Oct 03 2007
next sibling parent Radu <radu.racariu void.space> writes:
Pablo Ripolles wrote:
 Hello,

 as many of you have already read, there is an ongoing discussion about the
different paradigms/environments/approaches of parallel programming,
particularily aimed towards how to exploite the evenly more common multi-core
processors.

 http://www.artima.com/weblogs/viewpost.jsp?thread=214627
 http://blogs.intel.com/research/2007/10/parallel_programming_environme.html

 I'd like to hear about D community point of view!  Is the std.thread our
solution? Is there anyone expecting or following another approach?

 Thanks!
   

how to approach this matter. Personally, I like the CSP implementation available at http://assertfalse.com/projects.shtml, it is a good start and could offer a potential solution. CSP is a relatively old concept with a strong mathematical basis (http://en.wikipedia.org/wiki/Communicating_sequential_processes). Nevertheless the debate around concurrency and parallelism will continue as obviously no single solution has the potential to cover all the issues at hand.
Oct 03 2007
prev sibling next sibling parent Sean Kelly <sean f4.ca> writes:
Pablo Ripolles wrote:
 Hello,
 
 as many of you have already read, there is an ongoing discussion about the
different paradigms/environments/approaches of parallel programming,
particularily aimed towards how to exploite the evenly more common multi-core
processors.
 
 http://www.artima.com/weblogs/viewpost.jsp?thread=214627
 http://blogs.intel.com/research/2007/10/parallel_programming_environme.html
 
 I'd like to hear about D community point of view!  Is the std.thread our
solution? Is there anyone expecting or following another approach?

This is probably more appropriate for d.D, but the D community has been working on other approaches as well. Mikola Lysenko has implemented coroutines and a variant of CAR Hoare's CSP. And I believe someone has implemented Herb Sutter's futures as well. Also, Tango contains a clustering model that could be applied to in-process parallel programming fairly easily. In short, while I think threads are a necessary part of parallel programming, I don't think that explicit thread management is how most people will be doing parallel programming in D. Sean
Oct 03 2007
prev sibling next sibling parent "Stewart Gordon" <smjg_1998 yahoo.com> writes:
"Pablo Ripolles" <in-call gmx.net> wrote in message 
news:fdvsdk$cu3$1 digitalmars.com...
 Hello,

 as many of you have already read, there is an ongoing discussion
 about the different paradigms/environments/approaches of parallel
 programming, particularily aimed towards how to exploite the evenly
 more common multi-core processors.

 http://www.artima.com/weblogs/viewpost.jsp?thread=214627
 http://blogs.intel.com/research/2007/10/parallel_programming_environme.html

 I'd like to hear about D community point of view!  Is the
 std.thread our solution?

Possibly. Threads and shared memory might be the best way to implement parallel programs that are only going to run on a single multi-core machine, rather than be split across many machines.
 Is there anyone expecting or following another approach?

A while ago I posted some bindings for part of LAM MPI: http://tinyurl.com/394akj But it's been quite a long time since I had the means to try it out. And I don't know if these bindings are any use for MPI implementations other than LAM. Stewart. -- My e-mail address is valid but not my primary mailbox. Please keep replies on the 'group where everybody may benefit.
Oct 04 2007
prev sibling parent reply Nathan Reed <nathaniel.reed gmail.com> writes:
Pablo Ripolles wrote:
 Hello,
 
 as many of you have already read, there is an ongoing discussion about the
different paradigms/environments/approaches of parallel programming,
particularily aimed towards how to exploite the evenly more common multi-core
processors.
 
 http://www.artima.com/weblogs/viewpost.jsp?thread=214627
 http://blogs.intel.com/research/2007/10/parallel_programming_environme.html
 
 I'd like to hear about D community point of view!  Is the std.thread our
solution? Is there anyone expecting or following another approach?
 
 Thanks!

Is anyone interested into transactional memory (TM) in D? TM has a lot of overhead with respect to locks when you have a single thread or few threads, but it becomes better than locking when you have more threads (depending on the problem, of course - for certain problems, locking will beat TM no matter how many threads there are). And TM is far easier for mortals to program with than mutexes/locks/monitors/whatever. There are software TM libraries available for C++ and Java, so I'm sure something similiar could be cooked up for D. If this was part of the standard library (or, even better, a built-in part of the language...) then I think D could have a big advantage for people who write concurrent programs. Thanks, Nathan Reed
Oct 04 2007
parent Brad Roberts <braddr puremagic.com> writes:
On Thu, 4 Oct 2007, Nathan Reed wrote:

 Pablo Ripolles wrote:
 Hello,
 
 as many of you have already read, there is an ongoing discussion about the
 different paradigms/environments/approaches of parallel programming,
 particularily aimed towards how to exploite the evenly more common
 multi-core processors.
 
 http://www.artima.com/weblogs/viewpost.jsp?thread=214627
 http://blogs.intel.com/research/2007/10/parallel_programming_environme.html
 
 I'd like to hear about D community point of view!  Is the std.thread our
 solution? Is there anyone expecting or following another approach?
 
 Thanks!

Is anyone interested into transactional memory (TM) in D? TM has a lot of overhead with respect to locks when you have a single thread or few threads, but it becomes better than locking when you have more threads (depending on the problem, of course - for certain problems, locking will beat TM no matter how many threads there are). And TM is far easier for mortals to program with than mutexes/locks/monitors/whatever. There are software TM libraries available for C++ and Java, so I'm sure something similiar could be cooked up for D. If this was part of the standard library (or, even better, a built-in part of the language...) then I think D could have a big advantage for people who write concurrent programs. Thanks, Nathan Reed

The short answer.. yes, there's interest. The more indepth answer: http://d.puremagic.com/conference2007/speakers.html#bartosz Later, Brad
Oct 04 2007