Charm++ parallel programming system

[Jozsef Bakosi <jbakosi AT gmail.com>]

That's awesome! It works! Thanks a lot, everyone, for the help.

Though I did not understand everything 100%, it turns out that the online documentation was enough to teach me the important concepts, so that I actually had the correct implementation with cereal (the external serialization library) as well. I was pretty sure, though, that this should be possible with Charm's PUP serialization framework too, but I did not know how to use the PUP::fromMem, PUP::toMem functionality until Nikhil showed it with the attached example. Thanks, Nikhil. I will use the PUP framework then.

Nikhil's example might be useful for others too, so it may be a good idea to put it among the reduction examples. I have one minor observation: In the custom reducer, findHigherClass(), I would not be comfortable with freeing the memory *after* the return statement, so I would replace the following:

char *flatData = new char[size_pup.size()];

PUP::toMem packer(flatData);

packer | final;

return CkReductionMsg::buildNew(size_pup.size(), flatData);

delete [] flatData;

with

std::unique_ptr< char[] > flatData = std::make_unique< char[] >( size_pup.size() );

PUP::toMem packer( flatData.get() );

packer | final;

return CkReductionMsg::buildNew( static_cast< int >( size_pup.size() ), flatData.get() );

Though std::unique_ptr is C++11 and std::make_unique is C++14.

But this is really a minor thing and orthogonal to the functionality in question, I only pointed out in case you guys will put it among the examples.

Thanks again for the excellent and quick help, everyone.

Jozsef

On Mon, Jul 20, 2015 at 3:58 PM, Nikhil Jain <nikhil.jain AT acm.org> wrote:

Orion,

What you have said holds true for current versions of Charm++. I see
it as one of the implementation for doing what Joszef wants, i.e. to
serialize and deserialize non-POD at appropriate time to reduce them.

Initially, I din't realize that Joszef din't choose the pup-based
implementation path because its working was not obvious to him, and
the online documentation does not cover use of pup in that way. Thanks
for suggesting this route.

Joszef,

Please see attached an example on how pup can be used in this context.

--Nikhil


On Mon, Jul 20, 2015 at 4:17 PM, Tom Quinn <trq AT astro.washington.edu> wrote:
> 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
>>
>>
>>
>
> _______________________________________________
> 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