Charm++ parallel programming system

[Phil Miller <mille121 AT illinois.edu>]

On Fri, Feb 28, 2014 at 4:02 PM, Neha Gholkar <ngholka AT ncsu.edu> wrote:

4. I intend to implement something like point to point blocking send receive in the charm++ framework. I understand that CHARM++ is based on the message-passing paradigm but could it be possible to do this?

We implement constructs that act like blocking send and receive in several different ways, in various parts of the provided infrastructure

1. Futures

2. Entry methods with the 'sync' attribute returning a value

3. AMPI_Ssend

In general, however, they're not something to be sought out in Charm++ application design. Asynchronous message passing satisfies data dependences of interacting parallel objects. Synchronization is only desirable for parallel algorithms that gain additional information from it - e.g. Hoefler's Dynamic Sparse Data Exchange, Langer et al. on AMR [1], and so forth.

I have been looking into the load balancing framework of charm++. I have a few questions.

1. How does charm++ ensure barriers when sending and receiving data? 

2. How are barriers in general implemented in charm++?

With the above in mind, barriers take the synchronization expense of blocking communication and generalize it to the entire parallel job. Again, there needs to be something gained from them to make them worthwhile.

As such, Charm++ provides some such constructs, but their use should be minimized

1. Array reductions carrying no data - if you need to synchronize multiple chare arrays, do a reduction over each, and only proceed after getting a signal from each of them

2. Quiescence Detection - this is a heavy hammer, in that it globally senses when the entire system has gone idle. Thus, it's utterly non-composable across modules or across multiple instances of a single module

3. Termination detection library - this is a more localized library (relative to QD) that can be used in Charm++ programs, though I don't think we've included it in the main repository. if you have a need for it, I can make sure the code is available.

 

3. I came across this part of the code which implements blocking. Could you please help me under stand what happens exactly when RegisteringObjects and UnregisteringObjects is used?
 // enfore the barrier to wait until centralLB says no
  LDOMHandle h;
  h.id.id.idx = 0;      /////// necessary
  theLbdb->getLBDB()->RegisteringObjects(h);

One of the developers who hacks on the load balancing infrastructure can comment on this if they wish. I'm curious what, exactly, led you to this snippet of code? Are you working on applications development, load balancer strategy development, or making the Charm++ load balancing framework itself do something new? I can only see an answer to this providing any meaningful insight in the last case. If you're just writing a new load balancer, note that we use a modular plugin design such that each individual kind of load balancer need not concern itself with actually gathering data about the parallel objects or migrating them around, only with determining where they should each live and work.

[1] http://ppl.cs.illinois.edu/papers/12-35