Charm++ parallel programming system

[Tom Quinn <trq AT astro.washington.edu>]

You might want to look at some of the reducers in ChaNGa (Reductions.cpp). 
See, e.g. the "boxGrowth" reducer.  For a really crazy example, look in
salsa/ResolutionServer/Reductions.cpp.  In there is a "pythonReduce" which 
serializes Python objects and implements the "Map/Reduce" paradigm in 
Charm++.

Tom Quinn       Astronomy, University of Washington
Internet:       
trq AT astro.washington.edu
Phone:          206-685-9009

On Mon, 20 Jul 2015, Eric Bohm wrote:

> The sparseReducer library does some of that work already.  However it
> currently only works on sparse arrays of POD data.
>
> On 07/20/2015 03:46 PM, Orion Lawlor wrote:
>       Nikhil, it is true the reduction system only works with a
>       contiguous block of bytes, but the same is actually true of the
>       Charm++ message passing system at the bottom level--parameter
>       marshalling is a fairly thin layer that serializes the C++
>       object to a buffer, sends it as a simple flat message, and
>       unpacks it on the other side.  Couldn't Jozsef do the same thing
>       with a custom reducer type--unpack the inputs from flat bytes,
>       combine them as C++ objects, then reserialize before returning?
> I'd reply to him directly, but it'd be good if somebody tested and
> wrote up a good example for the manual before I mislead customers with
> my decade-old Charm++ knowledge!
>
> On Mon, Jul 20, 2015 at 7:21 AM, Nikhil Jain 
> <nikhil.jain AT acm.org>
> wrote:
>       Hi Jozsef,
>
>       Unfortunately, contributions to reductions have to be a
>       contiguous
>       buffer of data. Advanced support for contributing and
>       reducing non-POD
>       does not exist in Charm++ currently. The round about way
>       you described
>       is the only method I know of.
>
>       --Nikhil
>
>       On Fri, Jul 17, 2015 at 12:50 PM, Jozsef Bakosi
>       
> <jbakosi AT gmail.com>
>  wrote:
>       > Hi folks,
>       >
>       > What is the recommended way to define a custom reduction
>       in which chare
>       > array elements contribute user-defined-type (ptentially
>       non-POD) objects?
>       >
>       > What I have in mind is to convert an existing
>       contribution of chare array
>       > elements using the vanilla entry-method call, estimate()
>       to a typed (or
>       > non-typed) reduction. Example:
>       >
>       > User-defined non-POD type:
>       >
>       > class Cat {
>       >   std::map< int, double > catmap;
>       >   void pup( PUP::er& p ) { ... }
>       > };
>       >
>       > === Inefficient contribution using existing vanilla
>       entry method call to
>       > host from array elements ===
>       >
>       > In some member function of a chare array:
>       >
>       > std::vector< Cat > v;
>       > hostproxy.estimate( v );        // non-reduction
>       contribute a vector of Cats
>       >
>       > In the host's .ci file:
>       >
>       > entry void estimate( std::vector< Cat >& v );
>       >
>       > === Pseudo-code yielding a more efficient reduction to
>       host from array
>       > elements ===
>       >
>       > Now in some member function of a chare array:
>       >
>       > std::vector< Cat > v;
>       > // reduction contribute a vector of Cats
>       > contribute( ... some way to specify the contribution v,
>       hostproxy, and a
>       > custom reduction type on how to merge a Cat across a
>       reduction );
>       >
>       > Now in the host's .ci file:
>       >
>       > entry [reductiontarget] void estimate( some way to
>       receive a std::vector<
>       > Cat > );
>       >
> > I think I should define a new reduction type (as in 16.2), but
> that example
> > defines a custom reduction on a POD data of two short ints.
> What I think I
> > need is a custom reduction on a non-POD type (Cat, containing
> a std::map).
> >
> > One solution I know I can do is to convert the std::map in Cat
> to a POD for
> > the purpose of contributing to a reduction, but I'm wondering
> if there is a
> > better/cleaner way to do this.
> >
> > Thanks,
> > Jozsef
> >
> > _______________________________________________
> > charm mailing list
> > 
> charm AT cs.uiuc.edu
> > http://lists.cs.uiuc.edu/mailman/listinfo/charm
> >
>
>
>
> --
> Nikhil Jain, 
> nikhil.jain AT acm.org,
> http://charm.cs.uiuc.edu/people/nikhil
> Doctoral Candidate @ CS, UIUC
> _______________________________________________
> charm mailing list
> charm AT cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/charm
> _______________________________________________
> ppl mailing list
> ppl AT cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/ppl
>
>
>
>
> --
> Dr. Orion Sky Lawlor   
> lawlor AT alaska.edu
> http://www.cs.uaf.edu/~olawlor/
>
>
> _______________________________________________
> charm mailing list
> charm AT cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/charm