search

flang-compiler / flang

Flang is a Fortran language front-end designed for integration with LLVM.
Other
800 stars 134 forks source link

Coarray support #64

Open szaghi opened 7 years ago

szaghi commented 7 years ago

Dear flang team,

I would like to know if you have planned to add support for Coarray, as for the Fortran 2008 standard or the draft 2015. The OpenCoarrays team could be very interested to integrate your compiler into their workflow and user like me interested into CAF could be very interested into using your compiler if it will support CAF.

My best regards.

rouson commented 7 years ago

@szaghi Thanks for submitting this.

Dear flang team,

There are two ways in which OpenCoarrays can be used to support CAF:

  1. If flang supports some of the features of TS 29113 Further Interoperability with C (e.g., assumed rank), then it would be relatively easy to support CAF via source-to-source transformations that already exist in a the caffeinate-opencoarrays branch of OpenCoarrays. At least four compilers started supporting the requisite Fortran 2015 features even before reaching full Fortran 2008 support: Cray, Intel, IBM, and GNU Fortran. I advocate cherry-picking some low-hanging Fortran 2015 fruit even before reaching 2008 conformance.

  2. Although some aspects of OpenCoarrays currently appear tailored to gfortran, the goal has always been to support additional compilers, which is one of the primary reasons OpenCoarrays has remained separate from gfortran and the reason OpenCoarrays uses a more liberal license (3-clause BSD). Should a non-GNU compiler team express interest in OpenCoarrays, one of the first steps toward supporting additional compilers would be to adopt TS 29113 array descriptors, which provides yet more motivation for cherry-picking some Fortran 2015 features to implement before finishing Fortran 2008.

MichaelSiehl commented 7 years ago

Dear all, I am glad to read about these possibilities to integrate coarray support with FLANG through OpenCoarrays. As someone who is actively using coarrays through OpenCoarrays, still at an experimental stage yet (see below), I'd like to share some of my current insights and experiences using Fortran 2008 coarrays. Hopefully, this may further convince that implementing support for coarrays with FLANG could be well worth the effort.

Recently, I did succeed with implementing a customized synchronization procedure using Fortran 2008 coarrays with atomic subroutines, here: https://github.com/MichaelSiehl/Atomic_Subroutines--How_the_Parallel_Codes_may_look_like--Part_2 . With the ability to implement such customized synchronizations, programmed as procedures and based on safe use of atomics, I see two major advantages for the Fortran 2008 programmer already: Firstly, the Fortran 2008 programmer can easily break the limits of the underlying SPMD-model: it allows for an extremely flexible MPMD-like parallel development approach that allows to flexibly group the images into (independent) teams already. Secondly, the Fortran 2008 programmer can easily program the most sophisticated synchronization methods her-/himself and is therefore not limited to the Fortran 2008 build-in synchronization methods. (Remember: with coarrays/PGAS, the parallel logic codes are simply based on remote data transfers which need to be synchronized. Sophisticated synchronization methods are required to develop sophisticated parallel logic codes and thus, to develop new classes of algorithms in the near future.)

But at the same time, that way of coarray programming does prohibit the use of many Fortran 2008 coarray-related language features yet. Therefore and personally, I would only demand support for a very small subset of the Fortran 2008 coarray-related language features to start with. That is support for:

With ATOMIC_DEFINE, support for remote access of atomic integer array components (one single -scalar- array element only of course) of derived type coarrays is urgently required. That is supported by OpenCoarrays but not with ifort 18(beta) yet: https://software.intel.com/en-us/forums/intel-fortran-compiler-for-linux-and-mac-os-x/topic/733292 .

And finally, to hopefully further convince, I'd like to share some points of my current personal coarray programming roadmap for the next month:

  1. Will the Intel developers add support for remote referencing to an array component using atomic_define? (See my above link to the Intel Developer Zone Topic). This could further convince me that I am possibly on a right way with that kind of a coarray programming approach.
  2. I plan to develop additional examples of customized synchronization procedures and upload them to GitHub repositories to give further proof for their power.
  3. I plan to develop a simple example of coarray-based library code: In principle it should be no problem to use our coarray programming approach to develop (nearly) independent parallel library codes.
  4. derived from point 3: I would like to suggest a very simple coarray-related extension to the Fortran 2008 language: A build-in counter for the number of times the SYNC MEMORY statement gets executed (just counting locally on each coarray image): Something like an THIS_SEGMENT intrinsic, where SEGMENT means 'execution segment', i.e. the number of times SYNC MEMORY got executed on that image. (This counter would not be limited to the SYNC MEMORY statement itself, but also count for any other build-in synchronization method that does implicitly execute SYNC MEMORY). Such a simple feature could then already allow for development of completely independent parallel library codes based on coarrays. (My current approach does require that all parts of an application, and thus all library codes, do use the same segment / SYNC MEMORY counter, which does prevent completely independent coarray-based library development).

Hope this thoughts are somewhat helpful yet. cheers