Open naveen-rn opened 5 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.
If you look at the proposal - we have tried to split it as three different sub-levels:
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
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.
Changes
All these routines will be added as part of a separate document and not be included in the main OpenSHMEM specification.