• Michal Minich <michal.minich gmail.com> Jan 19 2010
• "Simen kjaeraas" <simen.kjaras gmail.com> Jan 19 2010
• "Simen kjaeraas" <simen.kjaras gmail.com> Jan 19 2010
• Sean Kelly <sean invisibleduck.org> Jan 19 2010
• Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> Jan 19 2010
• Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> Jan 19 2010
• Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> Jan 19 2010
• retard <re tard.com.invalid> Jan 19 2010
• retard <re tard.com.invalid> Jan 19 2010

Michal Minich <michal.minich gmail.com> writes:

Will the currently-being-designed message-passing concurrency be supported 
between OS processes? Or only OS threads supported is planned? 

Others may be probably interested in: light-weight threads, cooperative
concurrency 
and communication through network? If the implementation is not planned for 
initial release, is it planned for foreseeable future?

Thank you for answer.

"Simen kjaeraas" <simen.kjaras gmail.com> writes:

On Tue, 19 Jan 2010 14:24:27 +0100, Michal Minich  
<michal.minich gmail.com> wrote:

 Will the currently-being-designed message-passing concurrency be  
 supported between OS processes? Or only OS threads supported is planned?  
 Others may be probably interested in: light-weight threads, cooperative  
 concurrency and communication through network? If the implementation is  
 not planned for initial release, is it planned for foreseeable future?

 Thank you for answer.


The goal is for it to work seamlessly between threads, processes or even  
different computers.

-- 
Simen

"Simen kjaeraas" <simen.kjaras gmail.com> writes:

On Tue, 19 Jan 2010 14:24:27 +0100, Michal Minich  
<michal.minich gmail.com> wrote:

 Will the currently-being-designed message-passing concurrency be  
 supported between OS processes? Or only OS threads supported is planned?  
 Others may be probably interested in: light-weight threads, cooperative  
 concurrency and communication through network? If the implementation is  
 not planned for initial release, is it planned for foreseeable future?

 Thank you for answer.


The goal is for it to work seamlessly between threads, processes or even  
different computers.

-- 
Simen

Sean Kelly <sean invisibleduck.org> writes:

Michal Minich Wrote:

 Will the currently-being-designed message-passing concurrency be supported 
 between OS processes? Or only OS threads supported is planned? 


Both, but initially only between threads.

 Others may be probably interested in: light-weight threads, cooperative
concurrency 
 and communication through network? If the implementation is not planned for 
 initial release, is it planned for foreseeable future?


User threads (fibers) may be used at some point, and this should be invisible
to the user.  Network messaging will definitely be added.  These won't be
available in the initial release however.

Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:

Michal Minich wrote:
 Will the currently-being-designed message-passing concurrency be 
 supported between OS processes? Or only OS threads supported is planned?
 Others may be probably interested in: light-weight threads, cooperative 
 concurrency and communication through network? If the implementation is 
 not planned for initial release, is it planned for foreseeable future?
 
 Thank you for answer.


Right now we don't have time to focus on more than inter-thread 
communication. Sean and I had a pow-wow last week and decided we don't 
have the resources to address more than that. But definitely the design 
has an eye on future extensibility, of which inter-process communication 
is an obvious extension.

Andrei

Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:

retard wrote:
 Tue, 19 Jan 2010 08:32:19 -0800, Andrei Alexandrescu wrote:
 
 Michal Minich wrote:
 Will the currently-being-designed message-passing concurrency be
 supported between OS processes? Or only OS threads supported is
 planned? Others may be probably interested in: light-weight threads,
 cooperative concurrency and communication through network? If the
 implementation is not planned for initial release, is it planned for
 foreseeable future?

 Thank you for answer.


 communication. Sean and I had a pow-wow last week and decided we don't
 have the resources to address more than that. But definitely the design
 has an eye on future extensibility, of which inter-process communication
 is an obvious extension.

 Andrei


 I haven't seen a single mention of what kind of algoritms can be solved 
 efficiently with this framework. Is it good for parallel algorithms like 
 parallel matrix multiplication, merge sort, producer/consumer problems, 
 serving web pages, rendering fractals, blitting images, parallel parsing, 
 handling RPC or GUIs?


Must mean you haven't looked. Message passing is a well-understood paradigm.

Andrei

Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:

retard wrote:
 Tue, 19 Jan 2010 11:02:08 -0800, Andrei Alexandrescu wrote:
 
 retard wrote:
 Tue, 19 Jan 2010 08:32:19 -0800, Andrei Alexandrescu wrote:

 Michal Minich wrote:
 Will the currently-being-designed message-passing concurrency be
 supported between OS processes? Or only OS threads supported is
 planned? Others may be probably interested in: light-weight threads,
 cooperative concurrency and communication through network? If the
 implementation is not planned for initial release, is it planned for
 foreseeable future?

 Thank you for answer.


 communication. Sean and I had a pow-wow last week and decided we don't
 have the resources to address more than that. But definitely the
 design has an eye on future extensibility, of which inter-process
 communication is an obvious extension.

 Andrei


 efficiently with this framework. Is it good for parallel algorithms
 like parallel matrix multiplication, merge sort, producer/consumer
 problems, serving web pages, rendering fractals, blitting images,
 parallel parsing, handling RPC or GUIs?


 paradigm.


 You gotta be kidding. If the message passing framework abstracts away all 
 information about communication latencies, how can one tune the algorithm 
 to take advantage of data locality? I have both knowledge of theoretic 
 models such as Hoare's CSP and practical systems such as MPI and MPI-2. I 
 just want to know how your system maps 2+ processes to data parallel SSE 
 instructions when data locality is very high, to threads with shared 
 memory when the locality is a bit lower and how it groups execution into 
 larger chunks on NUMA and multi-computer clusters. Does it handle this 
 all internally when you run a foreach loop or do you have more fine-
 grained control over data?


SIMD-style data-parallel computation is not something we are currently 
addressing explicitly in the type system and in the standard library. 
You are welcome to contribute such APIs though; your level of knowledge 
definitely makes you the most appropriate potential contributor.

Andrei

retard <re tard.com.invalid> writes:

Tue, 19 Jan 2010 08:32:19 -0800, Andrei Alexandrescu wrote:

 Michal Minich wrote:
 Will the currently-being-designed message-passing concurrency be
 supported between OS processes? Or only OS threads supported is
 planned? Others may be probably interested in: light-weight threads,
 cooperative concurrency and communication through network? If the
 implementation is not planned for initial release, is it planned for
 foreseeable future?
 
 Thank you for answer.


 Right now we don't have time to focus on more than inter-thread
 communication. Sean and I had a pow-wow last week and decided we don't
 have the resources to address more than that. But definitely the design
 has an eye on future extensibility, of which inter-process communication
 is an obvious extension.
 
 Andrei


I haven't seen a single mention of what kind of algoritms can be solved 
efficiently with this framework. Is it good for parallel algorithms like 
parallel matrix multiplication, merge sort, producer/consumer problems, 
serving web pages, rendering fractals, blitting images, parallel parsing, 
handling RPC or GUIs?

retard <re tard.com.invalid> writes:

Tue, 19 Jan 2010 11:02:08 -0800, Andrei Alexandrescu wrote:

 retard wrote:
 Tue, 19 Jan 2010 08:32:19 -0800, Andrei Alexandrescu wrote:
 
 Michal Minich wrote:
 Will the currently-being-designed message-passing concurrency be
 supported between OS processes? Or only OS threads supported is
 planned? Others may be probably interested in: light-weight threads,
 cooperative concurrency and communication through network? If the
 implementation is not planned for initial release, is it planned for
 foreseeable future?

 Thank you for answer.


 communication. Sean and I had a pow-wow last week and decided we don't
 have the resources to address more than that. But definitely the
 design has an eye on future extensibility, of which inter-process
 communication is an obvious extension.

 Andrei


 I haven't seen a single mention of what kind of algoritms can be solved
 efficiently with this framework. Is it good for parallel algorithms
 like parallel matrix multiplication, merge sort, producer/consumer
 problems, serving web pages, rendering fractals, blitting images,
 parallel parsing, handling RPC or GUIs?


 Must mean you haven't looked. Message passing is a well-understood
 paradigm.


You gotta be kidding. If the message passing framework abstracts away all 
information about communication latencies, how can one tune the algorithm 
to take advantage of data locality? I have both knowledge of theoretic 
models such as Hoare's CSP and practical systems such as MPI and MPI-2. I 
just want to know how your system maps 2+ processes to data parallel SSE 
instructions when data locality is very high, to threads with shared 
memory when the locality is a bit lower and how it groups execution into 
larger chunks on NUMA and multi-computer clusters. Does it handle this 
all internally when you run a foreach loop or do you have more fine-
grained control over data?