Is [*] declaration necessary?

[lstag...@gmail.com]

I've noticed that the coarray declaration [*] is not always necessary. 

For instance

program test
    implicit none
    integer::s !! or s[*]

    s = this_image()
    call co_sum(s)
    write(*,*) s
end program

works whether or not s is declared as a coarray. 

Is the coarray declaration only needed when I need to access a value on another image? 

Is there any performance penalty for not declaring the variable as a coarray?

-Luke 

[Zaak Beekman]

Hi Luke,

I haven’t dug out the standard, but I am 99.9% sure that collectives can operate on any variable and do not require the variable to be declared as a coarray. I think this is true for some of the atomics as well, but I’m less confident on that point. Implementing collectives in an optimal way is fairly challenging to do. Using a well optimized low(er) level communication library, like MPI, allows OpenCoarrays to take advantage of these highly optimized, extant collective procedures and make them available to the CAF programmer with a simple, standardized interface.

OpenCoarrays provides the opencoarrays module that lets you use these intrinsics with other compilers, even if they don’t support F2018 collectives yet.

To my knowledge there is no performance advantage or disadvantage of declaration of the argument to a collective as being a coarray, but I have not checked this in the source nor have I performed any tests to verify this hypothesis.

Best,
Izaak “Zaak” Beekman

[Alessandro Fanfarillo]

Yep, the standard doesn't require to have a coarray variable as
argument of a collective function.
Coarray "memory" is a precious resource and should be used only when
strictly needed. I would avoid as much as possible to use a coarray
variable for collectives if that is not required.

Cheers,
Alessandro

> --
> You received this message because you are subscribed to the Google Groups
> "OpenCoarrays" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to opencoarrays...@googlegroups.com.
> Visit this group at https://groups.google.com/group/opencoarrays.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/opencoarrays/ab8d632f-f94a-41f3-abd2-25f4fe2b5ba6%40googlegroups.com.
>
> For more options, visit https://groups.google.com/d/optout.



--

Alessandro Fanfarillo

[lstag...@gmail.com]

Thanks for the replys.

I have been attempting to use OpenCoarrays in the code I develop FIDASIM (work is being done here) and while it has been far easier than I feared I'm sure I'll have more questions.

-Luke

[Zaak Beekman]

Glad to hear it’s going well! Generally using Coarrays is MUCH easier/fast than other parallel programming models like MPI. There are a few areas where the Fortran standard needs some fixing. First, it can be quite a pain to use them on unstructured grids. Second is that there are a few regressions and rough corners in less common use cases.

If you know of any way to secure funding for OpenCoarrays/GFortran development do chime in. We’re close to full support for some really great features from Fortran 2018 like Coarrays with allocatable and pointer components. A lot of GFortran and OpenCoarrays development was funded directly by Sourcery Institute.

You received this message because you are subscribed to a topic in the Google Groups "OpenCoarrays" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/opencoarrays/mCdUjcBlHQM/unsubscribe.
To unsubscribe from this group and all its topics, send an email to opencoarrays...@googlegroups.com.

Visit this group at https://groups.google.com/group/opencoarrays.

To view this discussion on the web visit https://groups.google.com/d/msgid/opencoarrays/fd013de5-3dec-4def-8b7a-bfd98178c196%40googlegroups.com.

[Damian Rouson]

The first argument in a collective subroutine does not need to be a coarray. In my view this is a subtlety that gives the language great power. In fact, I would estimate that 30-40% of the researchers with whom parallel programming are studying applications for which the researchers’ parallel algorithmic needs are fully met by non-coarray parallel features of Fortran 2018, including collective subroutines, synchronization, error termination, etc. Such applications need not declare a single coarray. This is one reason I have begun to replace “Coarray Fortran” with simply “Fortran 2018.”

Damian

To view this discussion on the web visit https://groups.google.com/d/msgid/opencoarrays/CAAbnBwbMP5m9xtoofem%2B4V-DPb3Ka-648h%2BZqQaGk7BDMxBCwg%40mail.gmail.com.