Hi Tobias,

I know about PRIF and was involved in the design of Caffeine. Unfortunately did
this intersect with the funding proposal and we did not want to overload the
proposal more. At the moment adding module support to dist. mem. coarrays means
OpenCoarrays patching, yes. In the unlikely event, that this should proceed
faster than expected we might look into PRIF/Caffeine and work on an
alternative implementation. But I expect that besides a proof of concept not
much will come of that, because one needs to implement a rather different
interface for each API call. 

Anyway, did you see my question about me issue with doing gomp-fortran tests: 
https://gcc.gnu.org/pipermail/fortran/2024-June/060542.html

Do you have any insight of what I am doing wrong? 

Regards,
        Andre

On Sat, 8 Jun 2024 21:52:42 +0200
Tobias Burnus <bur...@net-b.de> wrote:

> Andre Vehreschild wrote:
> >> PS That's good news about the funding. Maybe we will get to see "built in"
> >> coarrays soon?  
> > You hopefully will see Nikolas work on the shared memory coarray support, if
> > that is what you mean by "built in" coarrays. I will be working on the
> > distributed memory coarray support esp. fixing the module issues and some
> > other team related things.  
> 
> Cool! (Both of it.)
> 
> I assume "distributed memory coarray support" is still based on Open
> Coarrays?
> 
> * * *
> 
> I am asking because there is coarray API being defined: Parallel Runtime
> Interface for Fortran (PRIF), https://go.lbl.gov/prif
> 
> with an implementation called Caffeine – CoArray Fortran Framework of
> Efficient Interfaces to Network Environments,
> https://crd.lbl.gov/caffeine which uses GASNet or POSIX processes.
> 
> Well, the among the implementers is (unsurprising?) Damian – and the
> idea seems to be that LLVM's FLANG will use the API.
> 
> Tobias
> 
> PS: I think it might be useful in the long run to support both
> PRIF/Caffeine and OpenCoarrays.
> 
> I have attached my hello-world patch for -fcoarray=prif that I wrote
> after ISC-HPC; it only handles this_image() / num_images() + init/stop.
> I got confirmation by the PRIF developers that the next revision will
> permit calling __prif_MOD_prif_init multiple times such that one can use
> it in the constructor for static coarrays, which won't work otherwise.


-- 
Andre Vehreschild * Email: vehre ad gmx dot de 

Reply via email to