Lugano, July 18, 2018 - by Valentina Tamburello

Eurohack is a GPU-programming hackathon organized by CSCS since 2015. The goal of EuroHack18 is to port scalable applications to GPU accelerators and/or optimize an existing GPU-enabled application on a state-of-the-art GPU system.

But what is a hackathon? The word comes from the combination of “hack” and “marathon” and refers to a workshop in exploratory programming. Hackathons typically begin with some presentations about the specific topic that will be treated and the problems which can arise. Participants can give suggestions and organize themselves in teams, based on individual interests and skills, in order to improve software or solve problems. Once the hackathon starts, it can last from several hours to several days. At the end of a hackathon, the teams present and share their results, making it possible for people to learn from the ideas generated.

To learn something more about this exciting event, I have interviewed one of the organizers of the Eurohack 18, William Sawyer, who kindly answered to all my questions with precision and patience.

Why does CSCS yearly organize a hackathon and what are the advantages for CSCS and for the participants?

CSCS is one of several world computing centers with a GPU-based system as its flagship platform. GPUs involve additional programming complexity for our clients to successfully run their simulations. CSCS recognizes the large user investment required to port existing CPU applications to these GPUs and supports these efforts in a number of ways, including programming courses, user support and online documentation.  But these do not necessarily cover an important class of users, namely researchers who would like to invest even more resources in optimizing their codes and take full advantage of running on GPUs.

EuroHack provides such groups with an opportunity to ‘jumpstart’ their porting effort.  Application teams are provided with the assistance they need to get a representative mini-application running on GPUs.  This prototype then provides a basis for the subsequent port of their entire application.  In recent years numerous teams have also come to the hackathon with an existing GPU application which they optimize with the support of the team mentors.

The result is of mutual benefit to the application teams — who can have a greatly increased throughput and therefore achieve better scientific results with the same resource allocation — as well as to CSCS, which sees a higher GPU utilization. 
 

Since there is mutual benefit, Eurohack is offered for free. How does it work?

The hackathon is an opportunity for users to implement their representative application with the support of experienced GPU programmers. The costs are divided:  the teams pay their travel and accommodation costs for the week, while CSCS picks up the costs for the venue and infrastructure, as well as lunches and coffee breaks.  We also receive the support of vendors, such as Cray Inc., Portland Group and NVIDIA, who provide programming experts as mentors.  In recent years the latter has generously sponsored a workshop dinner, bringing all the participants together for a relaxed evening during the otherwise intense week.

Is EuroHack18 the first Hackathon you organized? What is your role?

I’m happy to say that I have organized all four EuroHacks from 2015 until this year.  My responsibilities are to promote the workshop in and around our user community, keep close contact with the selected application teams and close tabs on the infrastructure.  Fortunately, we are a big team to share the responsibilities: the CSCS Staff Unit organizes the venue and is responsible for logistics, while IT Services ensures the best possible network infrastructure for the participants.

 

General-purpose Graphics Processing Units (GPGPUs) can offer exceptionally high memory bandwidth and performance for a wide range of applications. What are the difficulties in programming GPGPUs and how and which extensions to C++ & Fortran can help scientists?

There are many different approaches to programming GPUs, and the hackathon mentors encourage the teams to choose the paradigm which is most appropriate for their application.  Our concern is for solutions which allow the scientists to concentrate on science, rather than addressing the intricacies of software optimization, while still providing long-term portability, even to platforms which may still emerge and potentially replace GPUs.  Many teams do choose to program the GPUs directly with the CUDA language, which is essentially an extension of C++ targeting NVIDIA GPUs.  We also support solutions based on compiler directives or ‘pragmas’ for Fortran or C/C++, which may provide performance portability to other emerging architectures.  However, depending on the application area, still other solutions are available to make possible a separation of concerns between the scientist and the software engineer.  

These include the Kokkos package from the Trilinos (Sandia NL) which provides a C++ programming model for high-performance architectures, and Domain-Specific Languages (DSLs), which allow the scientist to program these devices at a high level, while the complexity inherent to the architecture is managed through a ‘back-end’ supported by computer scientists.
 

Which kind of applications can run on GPUs?

Almost any application which runs on traditional CPUs can run on GPUs, albeit possibly without exceptional performance gains.  The most applicable GPU applications act on data which are largely independent, thus requiring a minimum of communication and synchronization.  In past hackathons there have been a number of success stories for Computational Fluid Dynamics (CFD), astrophysics, and environmental science applications, which one can find on the EuroHack pages, e.g., https://github.com/fomics/EuroHack17/wiki​​​​​​​​​​​​​​.

What are your expectations at the end of the week?

Our hope is that the participants can take home a representative test case running on GPUs which serves as a prototype for the subsequent port of their entire application.  At the very least, they should have a concrete roadmap for this port.  Teams which have come with an existing GPU application should go home with a version with significant performance gains which hopefully outperforms the CPUs by a factor reflecting the performance and memory bandwidth benefits of the GPU.