Skip to Content.
Sympa Menu

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

charm AT lists.cs.illinois.edu

Subject: Charm++ parallel programming system

List archive

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


Chronological Thread 
  • From: Sam White <white67 AT illinois.edu>
  • To: Jeff Hammond <jeff.science AT gmail.com>
  • Cc: "charm AT lists.cs.illinois.edu" <charm AT lists.cs.illinois.edu>
  • Subject: Re: [charm] [ppl] Adaptive MPI needs MPI_WIN_BASE (and other attributes)
  • Date: Tue, 26 Jan 2016 17:00:08 -0600

Hi Jeff,

We made a lot of progress on MPI-2.2 support in AMPI the past two weeks, and have bumped the version number to 2.2. Your MPI one-sided code should work now. We implemented the compliant no-op support for Spawn that you pointed out as well. Other than real Spawn support and its associated routines, we are missing the following from 2.2:

MPI_Grequest_complete
MPI_Grequest_start
MPI_Pack_external
MPI_Pack_external_size
MPI_Unpack_external
MPI_Register_datarep
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_set_name
MPI_Type_match_size
PMPI_* profiling interface

We're continuing to work on this, but I just wanted to give an update on our progress so far.

Thanks,
Sam

On Wed, Jan 13, 2016 at 4:54 PM, Jeff Hammond <jeff.science AT gmail.com> wrote:
So I found http://stackoverflow.com/questions/18813731/compile-time-check-if-a-function-is-used-unused-c but I don't know if the answers there meet the need for AMPI.

Jeff

On Wed, Jan 13, 2016 at 2:42 PM, Jim Phillips <jim AT ks.uiuc.edu> wrote:

Is there a clever C++ way to print a "please contact us" message at compile time when a given function prototype is used?

Jim


On Wed, 13 Jan 2016, Jeff Hammond wrote:

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
<https://urldefense.proofpoint.com/v2/url?u=https-3A__trac.mpich.org_projects_mpich_ticket_1699&d=BQMFaQ&c=8hUWFZcy2Z-Za5rBPlktOQ&r=O_hEmVYLR-pQ7tTSMIKUDKO2DElwB1hGdYuMXjnYWNo&m=AuI6bO5SXx8FwMH0m2Habgld936Mi7cYnwLgZoKudTU&s=chCpVWFqVt2QhcQvkYAf8BOH7rRAwUfnn7s5InfaKJ0&e=>
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
<https://urldefense.proofpoint.com/v2/url?u=https-3A__travis-2Dci.org_jeffhammond_PRK_jobs_101958477&d=BQMFaQ&c=8hUWFZcy2Z-Za5rBPlktOQ&r=x3NNBo1sW-0Ro900LIARhw_4yZMfh7AfgFTrqQHfc5M&m=D9MIQNXKu5ce_K0h86s7duG0CIuFQ_iYYIpRPwOuB-E&s=y1vV6_gvWWmT_qHNN3ubavsNAp8S7LxjKWhY-h6wU7M&e=>.
I've already pushed a workaround (
https://github.com/jeffhammond/PRK/commit/a511033a10995594bb8c90a6b0cdce6077bd3347
<https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_jeffhammond_PRK_commit_a511033a10995594bb8c90a6b0cdce6077bd3347&d=BQMFaQ&c=8hUWFZcy2Z-Za5rBPlktOQ&r=x3NNBo1sW-0Ro900LIARhw_4yZMfh7AfgFTrqQHfc5M&m=D9MIQNXKu5ce_K0h86s7duG0CIuFQ_iYYIpRPwOuB-E&s=mQimsoeeLkxvuwiHZFf9a3MHe9vptDFWSZftlee7b_g&e=>),
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/
<https://urldefense.proofpoint.com/v2/url?u=http-3A__jeffhammond.github.io_&d=BQMFaQ&c=8hUWFZcy2Z-Za5rBPlktOQ&r=x3NNBo1sW-0Ro900LIARhw_4yZMfh7AfgFTrqQHfc5M&m=D9MIQNXKu5ce_K0h86s7duG0CIuFQ_iYYIpRPwOuB-E&s=69NlTeGxPcuXXrDd3dGTyDC6Mzm8Xx7DEifsvwJL2ak&e=>






--
Jeff Hammond
jeff.science AT gmail.com
http://jeffhammond.github.io/
<https://urldefense.proofpoint.com/v2/url?u=http-3A__jeffhammond.github.io_&d=BQMFaQ&c=8hUWFZcy2Z-Za5rBPlktOQ&r=O_hEmVYLR-pQ7tTSMIKUDKO2DElwB1hGdYuMXjnYWNo&m=AuI6bO5SXx8FwMH0m2Habgld936Mi7cYnwLgZoKudTU&s=6jdcEyoy19CHQ0Xz6MPx3zWCyC7L13cSftGzKacEqyI&e=>





--
Jeff Hammond
jeff.science AT gmail.com
http://jeffhammond.github.io/
<https://urldefense.proofpoint.com/v2/url?u=http-3A__jeffhammond.github.io_&d=BQMFaQ&c=8hUWFZcy2Z-Za5rBPlktOQ&r=Nq2CXGH0HPA-kebuJZL7bq2LwLLmsz8gZBv3Q0ujxXU&m=LCZhWWNXoeINXxS7_RUiNp89oVU6Lf2bfVPgsnU6cG0&s=jjtjO_R9bF4GDa96maLajVs4fw-nUdbMpGCvL8kLGHE&e=>





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




--




Archive powered by MHonArc 2.6.16.

Top of Page