• Pablo Ripolles <in-call gmx.net> Oct 03 2007
• Radu <radu.racariu void.space> Oct 03 2007
• Sean Kelly <sean f4.ca> Oct 03 2007
• "Stewart Gordon" <smjg_1998 yahoo.com> Oct 04 2007
• Nathan Reed <nathaniel.reed gmail.com> Oct 04 2007
• Brad Roberts <braddr puremagic.com> Oct 04 2007

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!

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.

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

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

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

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