Performance evaluation of explicit finite difference algorithms with varying amounts of computational and memory intensity

Abstract

Future architectures designed to deliver exascale performance motivate the need for novel algorithmic changes in order to fully exploit their capabilities. In this paper, the performance of several numerical algorithms, characterised by varying degrees of memory and computational intensity, are evaluated in the context of finite difference methods for fluid dynamics problems. It is shown that, by storing some of the evaluated derivatives as single thread-or process-local variables in memory, or recomputing the derivatives on-the-fly, a speed-up of ∼2 can be obtained compared to traditional algorithms that store all derivatives in global arrays.

Large-scale performance of a DSL-based multi-block structured-mesh application for Direct Numerical Simulation

“…Validation consisted of running OpenSBLI on known problems, comparing its results to the legacy SBLI application solving the same problem. The correctness of different algorithms on CPUs were previously reported in [22]. In the present work, the min, max difference between the algorithms for all the conservative variables were found to be less than 10 −12 on each architecture, and the difference between the runs on CPU, and GPU are found to be less than 10 −12 for the number of iterations and the optimization options considered here.…”

“…It uses source-tosource translation to automatically parallelize applications written using this API. OPS is being used to parallelize a number of applications, including hydrodynamics [6], lattice Boltzmann codes [21] and CFD applications [22,23]. Currently supported parallel platforms include distributed memory clusters (using MPI), multi-core CPUs including Intel's Xeon Phi many-core processors (using SIMD, OpenMP, MPI and OpenCL) and GPUs (using CUDA, OpenCL and OpenACC) including clusters of GPUs.…”

“…extending the data set in the negative x direction). 22 allocated memory */ 23 ops_dat dat3 = ops_decl_dat(B,1, size, base, 24 halo_pos2, halo_neg2, d3, "double", "dat3"); halo_pos3, halo_neg3, d4, "double", "dat4"); ops decl dat(...) declares a dataset on a specific block with a number of data values per data point (1 in this case for all three ops dats) and a size, together with parameters declaring the base index of the data set (i.e. the start index of the actual data), the sizes of the block halos for the data, the initial data values and strings denoting the type of the data and name of the ops dat.…”

“…To reduce computationally expensive divisions, the rational constants, division by constants (like dx0) are evaluated to a constant variable at the start of the simulation. The full list of optimizations performed are given in [22]. For easier debugging the entire algorithm used to generate the code can be written to a LaTeX file.…”

“…Such an algorithm is generated by setting the store derivatives attribute of the grid class to False. In addition to BL and SN, the ease at which such modifications can be performed is explained in detail by generating several other variations of the solver in [22].…”