WG Meeting 11 07 2024

Agenda:

Sync on active topics and the OpenSHMEM v1.7 Milestone issues and PRs.

Notes:

Opens:

Larry Stewart proposes we talk about long term OpenSHMEM strategy and what are the standards for API proposals (e.g., working reference code).

How about a separate Github location/repository for files? Something like openshmem-org/specification-extras. Idea: scratch space for v1.7 branch?

Memory kinds - #195, inherent to spaces Spaces, confusion about how ctx associated w/ team Memory Handles: API concerns came up

Clarete volunteers to do a high-level study of spaces - she has experience with OpenFAM (asymmetric allocation/access).

Memory Model: Jim may not have the cycles to lead this complicated effort, seeking volunteers to get involved. Great project for OpenSHMEM "geeks". C and C++ memory model are aligned and well-defined, this theoretically puts us in a good place. Ordering assumptions need to be addressed. Nick Park's WIP Memory model PR a good reference: https://github.com/openshmem-org/specification/pull/477

Brandon Potter tentatively volunteers to move things forming Larry Stewart Muhammed Awad Jim Dinan as consultant

Jim proposes to create a new issue.

Core features for v1.7: Spaces Memory Kinds Memory Model non-blocking Collectives

Reduction on Nans - Dave summarized and proposed we tackle it in OpenSHMEM v1.7

Removing deprecated items? #471 Jim says this could be a beneficial change Would be nice to remove everything, but need to make sense it's reasonable to use them. Should provide a deprecation period to give folks a chance to request.

Larry creating GPU-initated API divergegence - how do we fix it? Dave will create that issue today.

AR: Let's groom the v1.7 milestone - let's try to keep v1.7 have items with owners.