Charm++ parallel programming system

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

Also, while I was tempted to suggest that you implement stubs for all of these functions that print a message telling the user to send a mail to you all with the feature request, having discussed the topic a few times with members of the PETSc, you should not to do this, because that will cause false positives for feature tests in configure because of useless stub symbols, and runtime failures are much worse than configure failures.  It's a bad idea to get on the PETSc team's naughty list, because it's effectively impossible to ever get off of it (e.g. dying appears to be insufficient)... :-)

Anyways, just my $0.02, and maybe another dime from PETSc.

Jeff

On Wed, Jan 13, 2016 at 2:09 PM, Sam White <white67 AT illinois.edu> wrote:

Thanks, I took MPI_Win_unlock_all off of my master list when honing it down to 2.2 features, but forgot MPI_Win_lock_all :)

I will bump the version number to 2.2 sooner rather than later!

-Sam

On Wed, Jan 13, 2016 at 3:48 PM, Jeff Hammond <jeff.science AT gmail.com> wrote:

MPI_Win_lock_all was added in MPI 3.0.  You do not need that for MPI 2.2 compliance.

MPI_Type_create_subarray is used heavily in ARMCI-MPI, but we can work around its absence (since we have needed to work around its low performance or brokenness in some contexts).

Most of the rest of the functions are not used by any code I've seen and have been broken or unsupported by implementations that declare themselves to be MPI 2.2 compliant.  You might be able to make that bump, at which point you will figure out what codes you are breaking via bug reports :-)

Jeff

On Wed, Jan 13, 2016 at 8:19 AM, Sam White <white67 AT illinois.edu> wrote:

Thanks for the tip on MPI_Spawn compliance. I have just recently been putting together a list of missing features and have started working more on 2.2 compliance since our 6.7.0 release.

Here's a list of all the functions that AMPI is missing from MPI-2.2 as of now:

MPI_Add_error_class

MPI_Add_error_code

MPI_Add_error_string

MPI_Close_port

MPI_Comm_accept

MPI_Comm_call_errhandler

MPI_Comm_connect

MPI_Comm_disconnect

MPI_Comm_get_name

MPI_Comm_get_parent

MPI_Comm_join

MPI_Comm_remote_group

MPI_Comm_remote_size

MPI_Comm_spawn

MPI_Comm_spawn_multiple

MPI_Comm_set_name

MPI_Comm_set_parent

MPI_Exscan

MPI_Grequest_complete

MPI_Grequest_start

MPI_Open_port

MPI_Pack_external

MPI_Pack_external_size

MPI_Publish_name

MPI_Register_datarep

MPI_Request_get_status

MPI_Status_set_cancelled

MPI_Status_set_elements

MPI_Type_create_darray

MPI_Type_create_indexed_block

MPI_Type_create_keyval

MPI_Type_create_resized

MPI_Type_create_subarray

MPI_Type_get_name

MPI_Type_get_true_extent

MPI_Type_match_size

MPI_Unpack_external

MPI_Unpublish_name

MPI_Win_create_errhandler

MPI_Win_create_keyval

MPI_Win_free_keyval

MPI_Win_get_errhandler

MPI_Win_get_attr

MPI_Win_lock_all

MPI_Win_set_attr

MPI_Win_set_errhandler

MPI_Win_set_group

MPI_Win_set_name

PMPI_* profling interface

We haven't had any driving need for strict 2.2 compliance from applications, so our development has been pretty demand-driven in that regard. We are also looking to implement features from MPI-3 like neighborhood collectives and the non-blocking collective routines that we are missing in the near future. We understand that not having 2.2 (or 3.1) compliance might turn off some potential users now or in the future, though, so we would like to get there!

-Sam

On Tue, Jan 12, 2016 at 6:48 PM, Jeff Hammond <jeff.science AT gmail.com> wrote:

What's missing for MPI 2.2 support?  I can't find a list in the documentation...

If it is just spawn, there's a way to be compliant with a no-op implementation (see https://trac.mpich.org/projects/mpich/ticket/1699 for details).

Jeff

On Tue, Jan 12, 2016 at 3:15 PM, Sam White <samt.white AT gmail.com> wrote:

I'll update you once this change has been merged. I'll also note that AMPI only officially supports MPI-1.3 (MPI_VERSION=1, MPI_SUBVERSION=3).

-Sam

On Tue, Jan 12, 2016 at 5:03 PM, Bohm, Eric J <ebohm AT illinois.edu> wrote:

Thanks Jeff,

I have submitted this to our Redmine Issue tracker.

https://charm.cs.illinois.edu/redmine/issues/942

On 01/12/2016 04:41 PM, Jeff Hammond wrote:

I am using Charm++ 6.7.0 for testing of the PRK.  I recently added code that fetches the MPI_WIN_BASE attribute on RMA windows.  This attribute was introduced in MPI 2.0, so it is not new.

Adaptive MPI does not define MPI_WIN_BASE, as demonstrate in https://travis-ci.org/jeffhammond/PRK/jobs/101958477.  I've already pushed a workaround (https://github.com/jeffhammond/PRK/commit/a511033a10995594bb8c90a6b0cdce6077bd3347), but it leads to a memory leak (this doesn't really matter, since the program terminates almost immediately thereafter, but it is shameful programming to do such things intentionally).

In short, all your MPI_WIN_BASE do not belong to us :-) <groan>

And if Adaptive MPI is setting MPI_VERSION=3 (I have not looked), then it needs the window attributes added in MPI 3.0.

I don't think these are too hard to add, and I imagine that I could contribute a patch, but I don't have any free cycles at the moment.  Sorry.

Thanks,

Jeff

--

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

--

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

--

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

--

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