Charm++ parallel programming system

[Eric Bohm <ebohm AT illinois.edu>]

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