HPCwire: An HPC Programming Model for the Exascale Age

Since 1986 - Covering the Fastest Computers
in the World and the People Who Run Them

Translation Disclaimer

Subscribe | Sign In

Tabor Communications
Corporate Video

Leading HPC
Solution Providers

June 26, 2012

An HPC Programming Model for the Exascale Age

Christian Simmendinger, T-Systems Solutions for Research and Daniel Grünewald, Fraunhofer ITWM, CC-HPC

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.

Share Options

Subscribe

Subscribe to HPCwire

Discussion

There are 0 discussion items posted.

Join the Discussion

Become a Registered User Today!

Registered Users Log in join the Discussion

RSS Feeds

Feeds by Topic

Feeds by Industry

Feeds by Content Type

Subscribe to All Content

All

July 13, 2012

July 12, 2012

July 11, 2012

July 10, 2012

July 09, 2012

July 06, 2012

July 05, 2012

July 04, 2012

July 03, 2012

Around the Web

New Mexico to Pull Plug on Encanto, Former Top 5 Supercomputer

Jul 12, 2012 | State says supercomputing center can’t pay bills to keep machine running.
Read more...

Computer Program Learns Games by Watching People

Jul 11, 2012 | Computer scientist builds intelligent machine with single-core laptop and some slick algorithms.
Read more...

Helix Nebula Cloud Targets European Scientific Research

Jul 10, 2012 | Science cloud in proof-of concept stage.
Read more...

Plug In and Power Down

Jul 09, 2012 | EU project offers software that makes datacenters more energy-efficient.
Read more...

Keeping Moore’s Law Alive

Jul 05, 2012 | Processor speed and power consumption are now at odds, which will force chipmakers to rethink their designs..
Read more...

Read more headlines...

Tackling the Data Deluge: File Systems and Storage Technologies

06/25/2012 | NetApp | A single hour of data collection can result in 7+ million files from just one camera. Collection opportunities are limited and must be successful every time. As defense and intelligence agencies seek to use the data collected to make mission-critical battlefield decisions, there’s greater emphasis on smart data and imagery collection, capture, storage and analysis to drive real-time intelligence. The data gathered must accurately and systematically be analyzed, integrated and disseminated to those who need it – troops on the ground. This reality leads to an inevitable challenge – warfighters swimming in sensors, drowning in data. With the millions, if not billions, of sensors providing all-seeing reports of the combat environment, managing the overload demands a file system and storage infrastructure that scales and performs while protecting the data collected. Part II of our whitepaper series highlights NetApp’s scalable, modular, and flexible storage solution to handle the demanding requirements of sophisticated ISR environments.

View the White Paper Library

Michael Wolfe Webinar: PGI Accelerator with OpenACC

Join Michael for a look at the first PGI Accelerator Fortran and C compilers to include comprehensive support for OpenACC, the new open standard for programming accelerators using compiler directives.