Charm++ parallel programming system

Text archives Help


Re: [charm] Adaptive MPI needs MPI_WIN_BASE (and other attributes)


Chronological Thread 
  • From: Jeff Hammond <jeff.science AT gmail.com>
  • To: Sam White <white67 AT illinois.edu>
  • Cc: "Bohm, Eric J" <ebohm AT illinois.edu>, "charm AT lists.cs.illinois.edu" <charm AT lists.cs.illinois.edu>
  • Subject: Re: [charm] Adaptive MPI needs MPI_WIN_BASE (and other attributes)
  • Date: Wed, 13 Jan 2016 13:48:02 -0800

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,






--



Archive powered by MHonArc 2.6.16.

Top of page