Hi Jerry,
<snip>
> Andre, one of the the other things I have not got to yet is reviewing the
> interface between gfortran and the caf_shmem. Is this interface generic
> enough to allow other libraries to be used. For example, we have the
> caf_shmem library and we have the OpenCoarrays library, down the road there
> may be others and we should make sure we don't artificially constrain another
> approach. I hope I am making sense here. One of things I have learned over
> the years is 'interfaces' between software objects/components/parts is likely
> the most critical thing.
The interface of gfortran for CAF-support libraries is exactly the same for
caf_shmem and OpenCoarrays. It was only a little bit corrected for both to fix
bugs (in both libs) and unify the handling of for example error message returns.
Or so to say the interface for OpenCoarrays and caf_shmem is quite stable. What
isn't stable is the interface over the different gcc versions. When you look at
that, you'll see, that with every evolution the interface gets adapted to the
needs of the libraries. I think this is better than limiting the interface to a
fixed one and having to cope with issues in the library or the compiler. I know
there is caffeine, which strives to define an interface for coarray libraries
on clang. Btw OpenCoarrays strived to be the interface for coarray libraries on
gfortran and others and is still only used for gfortran.
I totally understand that interfaces should ensure forward and backward
compatibility. On the other hand are we in an area where speed is crucial.
Assume that the compiler knows about a certain attribute of a coarray, but the
interface is fixed. Now the library needs to use an expensive heuristic to
compute the attribute. Would you rather use that heuristic or change the
interface? I would prefer to change the interface as need be.
I was only involved at the start of the caffeine project and there interface
was not that far away from what we had in gfortran back then. With gcc-15 and
the remote execution of caf accessors this diverge significantly. Again, I
haven't looked at it for quite some time. I am curious to see which approach is
the most flexible and performs better. That could be the job of a master thesis
or so. Anyone?
I hope my ramblings and opinions give an idea why what was done. I am open for
suggestions and other ideas. So feel free to add your opinion.
Regards,
Andre
--
Andre Vehreschild * Email: vehre ad gmx dot de
