Charm++ parallel programming system

[Phil Miller <mille121 AT illinois.edu>]

A wholly alternative approach to this issue would be to actually use the Charm++-MPI interoperability features available on (at least) the MPI, GNI (Cray XE/XK/XC), and PAMILRTS (Blue Gene Q) network layer builds of Charm++. This would let you actually write the portions of your code using BSP-style libraries in MPI, and call back and forth to and from Charm++ code.

There was a mailing list discussion about this sort of usage a few months back:
http://lists.cs.uiuc.edu/pipermail/charm/2014-May/001704.html

And is lightly documented in the Charm++ manual:
http://charm.cs.illinois.edu/manuals/html/charm++/25.html

On Tue, Aug 12, 2014 at 1:07 PM, Jeff Hammond <jeff.science AT gmail.com> wrote:

> I suppose one solution would be to call MPI_Barrier directly, but I don't
> like that solution.  First of all, is it safe to do that from within my
> Charm++ code?  Will it always be safe in future versions of Charm++?  It
> seems like a dangerous use of undocumented functionality.  Also, the code
> would not be portable to Charm++ installs that were not compiled to use MPI.

Calling MPI from Charm++ is definitely not safe in the general case,
if for no other reason than you can't assume MPI is even linked into
the application.  Charm++ has native network ports (i.e. bypass MPI)
on a number of systems.  Furthermore, there is the obvious difference
in the execution model: MPI is a static execution model based off of
CSP.  Charm++ is decidedly not.

Best,

Jeff, who is not a Charm++ guru but claims some expertise in MPI

--
Jeff Hammond
jeff.science AT gmail.com
http://jeffhammond.github.io/

_______________________________________________
charm mailing list
charm AT cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/charm