Automatic Generation of Massively Parallel Codes from ExaSlang

Abstract

Domain-specific languages (DSLs) have the potential to provide an intuitive interface for specifying problems and solutions for domain experts. Based on this, code generation frameworks can produce compilable source code. However, apart from optimizing execution performance, parallelization is key for pushing the limits in problem size and an essential ingredient for exascale performance. We discuss necessary concepts for the introduction of such capabilities in code generators. In particular, those for partitioning the problem to be solved and accessing the partitioned data are elaborated. Furthermore, possible approaches to expose parallelism to users through a given DSL are discussed. Moreover, we present the implementation of these concepts in the ExaStencils framework. In its scope, a code generation framework for highly optimized and massively parallel geometric multigrid solvers is developed. It uses specifications from its multi-layered external DSL ExaSlang as input. Based on a general version for generating parallel code, we develop and implement widely applicable extensions and optimizations. Finally, a performance study of generated applications is conducted on the JuQueen supercomputer.

Code generation approaches for parallel geometric multigrid solvers

“…Additionally, communication can be added automatically for functions originating from layer 3. At this point, specifics about memory layouts such as the number of ghost layers required for distributed memory parallelization are deduced and exposed as well [38]. All in all, the (generated) layer 4 description is complete in the sense that it can be used to generate target code without requiring layers 1 through 3.…”

Towards generating efficient flow solvers with the ExaStencils approach

“…The memory layout required for the field declaration is specified in a similar fashion, this time providing the following options: the data type of the information stored at each of the d5scretization points, the localization of the data points, where currently Cell and Node are allowed for cell‐ and node‐centered discretizations respectively, and specialized information about some regions of the field, e.g., ghost layers; a more complete description of regions is given in recent work from Kuckuk et al …”

“…Optionally, a direction can be specified to allow selecting only distinct interfaces, and the modifier on boundary can be added to omit inner boundaries, that is, boundaries between different fragments of the domain partition. Further information about the domain partitioning and regions can be found in recent work from Kuckuk et al To facilitate taking care of executing boundary handling kernels, it is also possible to summarize them in 1 function. As evident from listing 9, this function can then be registered with the field and executed through the common interface of apply bc.…”

“…by C≈ − t∇ T ∇ (scaled discrete Poisson operator for the pressure), and in Equation 22, the operator is approximated by its diagonal D = diag(A).…”

“…In particular, the implementation of boundary conditions is a frequent issue. 22 To facilitate taking care of executing boundary handling kernels, it is also possible to summarize them in 1 function.…”