As the supercomputing faithful prepare for exascale computing, there is a great deal of talk about moving beyond the two-decades-old MPI programming model . The HPC programmers of tomorrow are going to have to write codes that are able to deal with systems hundreds of times larger than the top supercomputers of today, and the general feeling is that MPI, by itself, will not make that transition gracefully. One of the alternatives being offered is a PGAS model known as GASPI, which was the subject of an extended session at last week’s International Supercomputing Conference.

GASPI, which stands for Global Address Space Programming Interface, is, as the name suggests, a partitioned global address space (PGAS) API. The GASPI standard is focused on three key objectives: scalability, flexibility and fault tolerance. It follows a single program multiple data (SPMD) approach and offers a small, yet powerful API composed of synchronization primitives, synchronous and asynchronous collectives, fine grained control over one-sided read and write communication primitives, global atomics, passive receives, communication groups and communication queues.

Essentially it uses one-sided RDMA-driven communication in a PGAS environment. As such, GASPI aims to initiate a paradigm shift from bulk-synchronous two-sided communication patterns towards an asynchronous communication and execution model.

With today’s ever increasing number of processes, a transition from bulk-synchronous communication towards an asynchronous programming model seems to be inevitable. Elapsed time for bulk-synchronous communication potentially scales with the logarithm of the number of processes, whereas the work assigned to a single process potentially scales with a factor of 1/(number of processes).

Hence, the scalability of bulk-synchronous communication patterns appears to be limited at best. Despite recent efforts to support true asynchronous communication, the message passing standard of MPI to a large extent still focuses on two-sided semantics and bulk-synchronous communication.

At the same time, fault tolerance also becomes a larger issue as machines expand in size. On systems with large number of processes, all non-local communication should be prepared for a potential failure of one of the communication partners. In GASPI this is accomplished by providing a timeout value as an argument to all non-local communication calls and the possibility to check for the state of each of the communication partners. The model also allows for the dynamic substitution of a failed process.

GASPI does not enforce a specific memory model, like, for example, the symmetric distributed memory management of OpenSHMEM. Rather GASPI offers PGAS in the form of configurable RDMA pinned memory segments. Since an application can request several segments in GASPI symmetric, asymmetric or stack based memory management models can readily coexist.

With PGAS, every thread can asynchronously read and write the entire global memory of an application. On modern machines with RDMA engines, an asynchronous PGAS programming model appears as a natural extension and abstraction of available hardware functionality. For systems with DMA engines (such as tile architectures), this also holds true for a node-local level.

While the GASPI API readily can support the various communication patterns of MPI by means of an add-on library, the reverse is not true. GASPI for example supports RDMA access to arbitrarily distributed data, which allows the programmer a direct RDMA write access from a local send halo of an unstructured mesh into the corresponding remote receive halo.

The GASPI API has been designed to coexist with MPI and hence in principle provides the possibility to complement MPI with a partitioned global address space. We note however, that while such an approach provides an opportunity for increased scalability, fault–tolerant execution will not be possible due to the corresponding limitations of MPI.

GASPI inherits much of its design from the Global address space Programming Interface (GPI), which was developed in 2005 at the Competence Center for High Performance Computing (CC-HPC) at Fraunhofer ITWM. GPI is implemented as a low-latency communication library and is designed for scalable, real-time parallel applications running on cluster systems. It provides a PGAS API and includes communication primitives, environment run-time checks and synchronization primitives such as fast barriers or global atomic counters.

GPI communication is asynchronous, one-sided and, most importantly, does not interfere with the computation on the CPU. Minimal communication overhead can be realized by overlapping communication and computation. GPI also provides a simple, run-time system to handle large data sets, as well as dynamic and irregular applications that are I/O- and compute-intensive. As of today, there are production-quality implementations for x86 and IBM Cell/B.E architectures.

GPI has been used to implement and optimize CC-HPC industry applications like the Generalized Radon Transform (GRT) method in seismic imaging or the seismic work flow and visualization suite PSPRO. Today, GPI is installed on Tier 0 supercomputer sites in Europe, including the HLRS in Stuttgart and the Jülich Supercomputing Centre.

The GPI library has yielded some promising results in a number of situations. In particular, GPI outperforms MPI in significant low-level benchmarks. For process to process communication, GPI asynchronous one-sided communication, as opposed to both MPI one-sided communication and MPI bulk-synchronous two sided-communication, delivers full hardware bandwidth. As a function of message size, GPI reaches its peak performance much earlier than MPI.

A slightly more complex type of low-level benchmark is the two dimensional fast Fourier transformation on a distributed data set. We have compared two almost identical MPI and GPI implementations which feature the same communication pattern. Contrary to MPI, GPI was able to deliver near perfect scalability in a strong scaling setup.

GPI has also shown excellent scalability in a broad spectrum of typical real world HPC applications like the Computational Fluid Dynamics (TAU code from the DLR), or BQCD, a four dimensional nearest neighbor stencil algorithm. GPI has also been used in the implementation of fastest Unbalanced Tree Search (UTS) benchmark on the market.

Since many of the GASPI key objectives are shared by GPI, these results show the inherent potential of GASPI.

In 2010 the request for a standardization of the GPI interface emerged, which ultimately lead to the inception of the GASPI project in 2011. The work was funded by the German Ministry of Education and Science and included project partners Fraunhofer ITWM and SCAI, T-Systems SfR, TU Dresden, DLR, KIT, FZJ, DWD and Scapos.

The standard is currently being implemented in two flavors: a highly portable open source implementation based on GASNet and a commercial implementation aimed at ultimate performance. This latter implementation will be based on GPI. The TU Dresden, ZIH will provide profiling support for GASPI by means of extending the VAMPIR tool suite.

The GASPI project intends to drive the dissemination and visibility of the API by means of highly visible lighthouse projects in specific application domains, including CFD, turbo-machinery, weather and climate, oil and gas, molecular dynamics, as well as in the area of sparse and dense matrices. Amongst other implementations, the GASPI project will provide an asynchronous GASPI version of the Linpack benchmark.

There are a number of other projects that pursue similar goals to GASPI, the closest in spirit being OpenSHMEM. Ultimately the GASPI project aims at establishing a de-facto standard for an API for scalable, fault-tolerant and flexible communication in a partitioned global address Space. Whether that newly emerging standard will be called GASPI, however, remains to be seen.