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? However, Github also can host links to documents in issues/comments/wiki.

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 sure (esp. w/ users) it's reasonable to do so. Should provide a deprecation period to give folks a chance to request.

Larry brought up GPU-initiated API divergence - how do we fix it? Dave will create that issue today.

AR: Let's groom the v1.7 milestone - let's try to have v1.7 items with distinct owners and a motive to drive for v1.7 or v1.8+.