search

openshmem-org / specification

OpenSHMEM Application Programming Interface
http://www.openshmem.org
51 stars 41 forks source link

Adding Fortran bind(C) support for basic OpenSHMEM routines in a separate document #249

Open naveen-rn opened 6 years ago

naveen-rn commented 6 years ago

Problem

As per #194, we are planning to separate the main Fortran replacement interface proposal into multiple smaller parts. This issue tracks the first part of the proposal - to add and support the initial list of Fortran bind(C) routines.

List of supported OpenSHMEM interface

The following are the list of planned OpenSHMEM routines available in the Fortran bind(C) interface.
shmem_init () shmem_ctx_create () atomic_swap shmem_wait_until()
shmem_finalize () shmem_ctx_destroy () atomic_fetch_add barrier
shmem_my_pe () shmem_putmem() atomic_fetch_inc sync
shmem_n_pes () shmem_putmem_nbi() atomic_fetch_and all-to-all
shmem_global_exit () shmem_getmem() atomic_fetch_or all-to-alls
shmem_init_thread () shmem_getmem_nbi() atomic_fetch_xor broadcast
shmem_query_thread atomic_fetch shmem_quiet () reduce
shmem_malloc () atomic_set shmem_fence () collect
shmem_free () atomic_cswap shmem_test () fcollect

Changes

All these routines will be added as part of a separate document and not be included in the main OpenSHMEM specification.

jeffhammond commented 3 years ago

What's the value of standardizing this versus the interested parties providing an implementation to the community as OSS?

There is a real cost to standardization in the form of our time. I'd like to see the implementation in the wild and some evidence that we need more than one implementation of the same API. If there is only going to be one implementation, then there is no need to spend time on standardization.

naveen-rn commented 3 years ago

If you look at the proposal - we have tried to split it as three different sub-levels:

  1. RM all the existing FTN support - DONE
  2. Introduce Fortran Bind(C) based base support - This #249 issue
  3. Introduce the use of standard Coarray features with OpenSHMEM to make (2) more clean - Issue #252

Though our goal is just to have (3) in the spec - introducing the changes as multiple smaller items makes it little easier for standardization. To answer why we need (3) as you have asked in https://github.com/openshmem-org/specification/issues/252#issuecomment-870184975:

We are not expecting users to program both Coarrays and OpenSHMEM together. But, we are trying to make use of standard language features like the coarrays as OpenSHMEM-aware symmetric heap objects. This is similar to the use of global/static variable in C. IMO, this will make it easier for FTN users to adopt OpenSHMEM.

So, addressing the interoperability comes from trying to make the spec more usable. Once we allow using coarrays as SHEAP - then it is required for the OpenSHMEM spec to address the sequential consistency and memory ordering rules of mixing both OpenSHMEM and FTN Coarray features together. This is same as how we are addressing the load/store interoperability with general OpenSHMEM RMA/AMO semantics in C-bindings.

And, again this also the reason why we can't simply maintain a OSS library. To implement (3) - we need more information on the underlying memory management engine in different CAF and OpenSHMEM implementations. We can discuss this further if required.

All said - I agree with the effort statement. That is why the progress is very slow.

Related paper: https://dl.acm.org/doi/10.1145/3418084 WIP branch: https://github.com/naveen-rn/specification/tree/ftn08 - needs update