Charm++ parallel programming system

["Kale, Laxmikant V" <kale AT illinois.edu>]

A few quick suggestions and a question:

1. Add [notrace] as an entry method tag to it.  This stops some but not all 
tracing associated with the entry method. 
2. Reduce the number of calls by processing K buckets each time the 
nextBucketSmooth entry method is called. (K can be small like 4 or 8.. which 
will give you the reduction, hopefully without reducing prioritization of 
remote message significantly.

We are thinking about other enhancements. 

Also, is your concern about not being able to use projections because of the 
large logsize? That can have additional remedies that we will work on. 
(sumDetail is another option.. see: sec 1.1.2 of the projections manual 
(http://charm.cs.illinois.edu/manuals/html/projections/manual-1p.html )


Laxmikant (Sanjay) Kale         http://charm.cs.uiuc.edu 
<http://charm.cs.uiuc.edu/>
Professor, Computer Science     
kale AT illinois.edu
201 N. Goodwin Avenue           Ph:  (217) 244-0094
Urbana, IL  61801-2302 

On 11/2/16, 6:15 PM, "Tom Quinn" 
<trq AT astro.washington.edu>
 wrote:

    In ChaNGa, we have a "loop" that looks like the following:
    
    void TreePiece::nextBucketSmooth(dummyMsg *msg){
    
       smoothNextBucket();
       currentBucket++;
    
       if (currentBucket<numBuckets) {  // Queue up the next set
         thisProxy[thisIndex].nextBucketSmooth(msg);
       } else {
         delete msg;
       }
    }
    
    The point of sending a message to itself is to allow other entries to 
    execute.  The obvious problem with this loop is that it generates a ton 
of 
    projection events.  Is CthYield() a better way to do this?  Is there a 
way 
    of detecting whether the current PE has messages waiting in the execution 
    queue?
    
    Tom Quinn   Astronomy, University of Washington
    Internet:   
trq AT astro.washington.edu
    Phone:              206-685-9009