[mpiwg-hybridpm] Meeting Tomorrow

Tue Apr 4 18:33:08 CDT 2023

Dan and I discussed this and below is an email that I had exchanged with Jim.

My notes seems to differ from what Rohit suggests. I will not be able to join the meeting tomorrow, but hopefully we will get to an agreement.

Thanks

Maria

Jim

Dan and I discuss this a bit today. This is where we landed:

1) Do we need a default?

If there is one, it is well defined and it is only <mpi, system>. This default is just a shortcut and seems unneeded, but it is fine to keep it.

But there is no need to have default.

We do not want a default that is not well defined (or one that can be implementation specific

2)    The user gets what they request (if supported), but they could get more.

If the user requests “ ”, it could get nothing or whatever the library wants to provide.

We recommend to have an advice to users so that they know that if they do not include default or do not include <mpi,system> they may not get it.

3)    Assert can only use default if it is well defined, as <mpi, system>. Otherwise, it cannot use it.

4)    If the user does not request anything through the mechanism in the new proposal, the user always gets mpi and system, as if they had requested mpi and system.

There were a couple of question about:

1) If the user requests (default), should the answer in the provided include (default).

The provided should always include everything that is supported. The answer provided should contain default only if a) default exists (see 1) and b) it was requested. We do not want a default keyword, but if one exists, and it is well defined as <mpi,system>, then it should be returned if it was included in the original request.

2) If the answer includes default, can I use that in the assert()? This should be answered in 3) above.

- If it is well defined, it can be used, as in this case default is just a shortcut for <system,mpi>
- If it not well defined, it should definitely not be used (but we do no want that default, regardless)

Thanks

Maria

On Apr 4, 2023, at 6:25 PM, Rohit Zambre via mpiwg-hybridpm <mpiwg-hybridpm at lists.mpi-forum.org<mailto:mpiwg-hybridpm at lists.mpi-forum.org>> wrote:

Hi,

Jotting down my thoughts from last week’s discussion on defaults in the memory allocation kind proposal.

The main issue, in my view, is regarding the need for the default keyword (underline formatting to represent the keyword) in the standard.
I think both parties, for and against the keyword, agree on the need for the default concept in the standard (italics formatting to represent the concept).

At first, I was on the side of the “against” party, but based on the example and comments made during the discussion, I realized that we may lose some flexibility in what the user is able to request without the default keyword.

Particularly, in cases where an MPI library’s default supports different kinds of memory, without the default keyword, MPI users would lose the flexibility of requesting support for only a subset (e.g. for optimal performance) of the kinds supported in the MPI library’s default. Without the default keyword, the users would need fallback to non-standard library-specific ways of turning off support.

Assume we have two MPI libraries. Both support system, mpi, gpu, xpu, ypu kinds. They differ in their defaults.
libmpi_A’s default includes support for system, mpi, gpu, xpu, ypu
libmpi_B’s default includes support for system, mpi

With the default keyword in the standard
MPI_Info_set(info, “mpi_assert_memory_alloc_kind”, “default, gpu”); <--- In libmpi_A, gpu is part of itsdefault. libmpi_B will add support for gpu kind.
MPI_Info_set(info, “mpi_assert_memory_alloc_kind”, “gpu”); <--- libmpi_A will turn off support for xpu and ypu kinds. libmpi_B will add in support for gpu kind.

Without the default keyword in the standard
MPI_Info_set(info, “mpi_assert_memory_alloc_kind”, “gpu”); <--- it is ambiguous for libmpi_A whether the user wants gpu kind only, or at least gpu kind. libmpi_B will add in support for gpu kind.

I am not sure if there would be a standard way to turn off support for kinds in a library’s defaultwithout the default keyword.

Regards,
Rohit

From: mpiwg-hybridpm <mpiwg-hybridpm-bounces at lists.mpi-forum.org<mailto:mpiwg-hybridpm-bounces at lists.mpi-forum.org>> on behalf of Jim Dinan via mpiwg-hybridpm <mpiwg-hybridpm at lists.mpi-forum.org<mailto:mpiwg-hybridpm at lists.mpi-forum.org>>
Date: Tuesday, April 4, 2023 at 10:09 AM
To: Hybrid working group mailing list <mpiwg-hybridpm at lists.mpi-forum.org<mailto:mpiwg-hybridpm at lists.mpi-forum.org>>
Cc: Jim Dinan <james.dinan at gmail.com<mailto:james.dinan at gmail.com>>
Subject: [mpiwg-hybridpm] Meeting Tomorrow
External email: Use caution opening links or attachments

Hi All,

The HACC WG will meet at the usual time this Wednesday. Let's continue with the discussion of how to handle the defaults in the memory allocation kinds proposal. Given the discussion from last time, I think it would also be helpful if folks are able to re-read the proposal before tomorrow's meeting.

Cheers,
 ~Jim.
_______________________________________________
mpiwg-hybridpm mailing list
mpiwg-hybridpm at lists.mpi-forum.org<mailto:mpiwg-hybridpm at lists.mpi-forum.org>
https://lists.mpi-forum.org/mailman/listinfo/mpiwg-hybridpm

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mpi-forum.org/pipermail/mpiwg-hybridpm/attachments/20230404/62c7a209/attachment-0001.html>