Coarray Fortran - An Alternate Perspective

An Alternate Perspective

A group at Rice University is pursuing an alternate vision of coarray extensions for the Fortran language. Their perspective is that the Fortran 2008 standard committee's design choices were shaped more by the desire to introduce as few modifications to the language as possible than to assemble the best set of extensions to support parallel programming. They don't believe that the set of extensions agreed upon by the committee are the right ones. In their view, both Numrich and Reid's original design and the coarray extensions proposed for Fortran 2008, suffer from the following shortcomings:

• There is no support for processor subsets; for instance, coarrays must be allocated over all images.
• The coarray extensions lack any notion of global pointers, which are essential for creating and manipulating any kind of linked data structure.
• Reliance on named critical sections for mutual exclusion hinders scalable parallelism by associating mutual exclusion with code regions rather than data objects.
• Fortran 2008's sync images statement doesn't provide a safe synchronization space. As a result, synchronization operations in user's code that are pending when a library call is made can interfere with synchronization in the library call.
• There are no mechanisms to avoid or tolerate latency when manipulating data on remote images.
• There is no support for collective communication.

To address these shortcomings, the Rice University group is developing a clean-slate redesign of the Coarray Fortran programming model. Rice's new design for Coarray Fortran, which they call Coarray Fortran 2.0, is an expressive set of coarray-based extensions to Fortran designed to provide a productive parallel programming model. Compared to Fortran 2008, Rice's new coarray-based language extensions include some additional features:

• process subsets known as teams, which support coarrays, collective communication, and relative indexing of process images for pair-wise operations,
• topologies, which augment teams with a logical communication structure,
• dynamic allocation/deallocation of coarrays and other shared data,
• team-based coarray allocation and deallocation,
• global pointers in support of dynamic data structures,
• support for latency hiding and avoidance, and
  • asynchronous copies,
  • asynchronous collective operations, and
  • function shipping.
• enhanced support for synchronization for fine-grain control over program execution.
  • safe and scalable support for mutual exclusion, including locks and lock sets,
  • events, which provide a safe space for point-to-point synchronization,
  • cofence, which forces local completion of asynchronous operations,
  • finish, a barrier-like SPMD construct that forces completion of asynchronous operations across a team,