D and multicore

Fawzi Mohamed fawzi at gmx.ch
Sun Nov 14 02:10:47 PST 2010


On 14-nov-10, at 02:44, Fawzi Mohamed wrote:

> [...]
> Sometime the problem you have is not so costly that you need to  
> commit all resources to it, you just want to solve it efficiently  
> and if possible taking advantage of the parallelization.

> In this case a good model is the actor model where objects  
> communicate with messages to each other.
> One can have thread objects with mailboxes and pattern matching to  
> select the message, or objects with an interface and a remote  
> procedure call to invoke them.
> You can organize the network of messages in several ways, you can  
> have a central server, and clients that connect, you can have a  
> central database to communicate, you can have a peer to peer  
> structure, you can have producer/consumer relationships.
> Normally given a problem one can see how to partition it optimally.
>
> I use blip.parallel.rpc to give that kind of messaging between  
> objects.
> Note that one has to think about failure of one part in  this model,  
> not necessarily a failure of one process should stop all processes  
> (in some cases it might even be undetected).
> At this level one could theoretically migrate processes/objects  
> automatically, but given that the latency increase can be very large  
> (~10^6) this automatic distribution is doable only for tasks that  
> were considered by the programmer, a fully automatic redistribution  
> of any object is not realistic.

I forgot to say that if that part of your problem fits a simple  
parallelization pattern, for example costly basically independent  
tasks, for which you might (for example) use a client/server approach,  
or a data parallel approach with huge amount of distributed data on  
which you want to apply something like map/reduce.
In these examples the actor model might work well allowing one to be  
more dynamic about the work distribution than MPI (that has no nice  
partial failure), and still use all system resources (in fact I use it  
exactly for those reasons).



More information about the Digitalmars-d mailing list