Charm++ parallel programming system

[Jeff Hammond <jeff.science AT gmail.com>]

The MPI C++ bindings break every C++ code that attempts to use both
MPI and the C standard library, not just Charm++.  It ranks up there
with not switching to size_t as a tier-1 facepalm...

MPI-3 deletes (not deprecates - it's gone) the C++ bindings but some
implementations still support them due to user demand.  *I'd strongly
encourage C++ users to contact their favorite MPI implementer and beg
them to strictly implement MPI-3, which is to say, ask them to delete
the C++ bindings, or at least make them a non-default option.*

Best,

Jeff

On Tue, Oct 21, 2014 at 3:45 PM, Phil Miller 
<mille121 AT illinois.edu>
 wrote:
> As long as MPI is the 800lb gorilla in this space, and is specified in a way
> that unfavorable implementations can break things for us, we don't really
> get to say "not our problem", or direct users to workarounds indefinitely.
> We're trying to ease adoption as much as possible, and that unfortunately
> means playing nice with other code that's varying degrees of broken.
>
> On Tue, Oct 21, 2014 at 5:33 PM, Jeff Hammond 
> <jeff.science AT gmail.com>
> wrote:
>>
>> Phil: Please do not apologize for the catastrophic failure of the MPI
>> Forum in not foreseeing this issue.  It should have been solved 10
>> years ago with MPI::FILE_SEEK_SET (or something like that).  One
>> should also blame C preprocessing for not respecting C++ namespaces,
>> which is the source of all sorts of absolutely disgusting problems.
>>
>> In any case, doesn't "-DMPICH_IGNORE_CXX_SEEK" solve this trivially?
>> Of course it's nice if Charm++ handles it, but I would have thought
>> that users could work around immediately.  I know this is discussed on
>> the ticket, but your response here seems to hedge as if that's not a
>> sufficient solution...
>>
>> Best,
>>
>> Jeff
>>
>> On Mon, Oct 20, 2014 at 3:21 PM, Phil Miller 
>> <mille121 AT illinois.edu>
>> wrote:
>> > This has actually come up for some other users working with Intel's MPI:
>> > https://charm.cs.illinois.edu/redmine/issues/549
>> > We're trying to work this out in a way that will have the least impact
>> > on
>> > users who wouldn't otherwise be affected by the incompatibility.
>> >
>> > Thanks for the report, and sorry for the trouble it's given you.
>> >
>> > On Mon, Oct 20, 2014 at 5:16 PM, Robert Steinke 
>> > <rsteinke AT uwyo.edu>
>> > wrote:
>> >>
>> >> I'm compiling Charm-6.6.0 with Intel MPI, and it complains that Intel
>> >> MPI
>> >> wants mpi.h #included before stdio.h.  The problem is in the file
>> >> src/ck-core/mpi-interoperate.h included by
>> >> src/ck-core/mpi-interoperate.C
>> >> and src/ck-core/mpi-mainmodule.C.  I worked around it by just adding
>> >> #include <mpi.h> at the top of mpi-interoperate.C and mpi-mainmodule.C.
>> >> That works for me because I am only compiling for MPI, but in
>> >> mpi-interoperate.h the #include <mpi.h> is actually in a #if
>> >> declaration.
>> >>
>> >> I just wanted to let you know in case you feel like fixing this in the
>> >> official source code.  I don't need a fix.  My workaround works for me.
>> >>
>> >> Bob Steinke
>> >>
>> >> _______________________________________________
>> >> 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
>> >
>>
>>
>>
>> --
>> Jeff Hammond
>> jeff.science AT gmail.com
>> http://jeffhammond.github.io/
>
>



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