[mpiwg-hybridpm] Meeting Tomorrow

[Rohit Zambre]

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 its default. 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 default without the default keyword.

Regards,
Rohit

From: mpiwg-hybridpm <mpiwg-hybridpm-bounces at lists.mpi-forum.org> on behalf of Jim Dinan via mpiwg-hybridpm <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>
Cc: Jim Dinan <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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mpi-forum.org/pipermail/mpiwg-hybridpm/attachments/20230404/05f07bc0/attachment-0001.html>