Prueba de Compatibilidad

During the course of this work, a select number of benchmarks were used to acquire information about various machine characteristics.

3.2.1

Network Interconnect Micro-Benchmarks

The use of network interconnect benchmarks enables us to explore the underly- ing latency and bandwidth performance of various hardware without the com- plicating factor of a scientific application’s additional interactions, such as con- tention, synchronisation or load-balancing that may misrepresent the potential peak performance. The two interconnect benchmarks used in this thesis are:

Intel MPI Benchmark

The Intel MPI Benchmark (IMB) [82] captures the performance of MPI net- work operations, including point-to-point, collective and I/O operations [83].

SKaMPI

The SKaMPI benchmark [167, 12] is an alternate network benchmark that is similarly capable of capturing both MPI point-to-point and collective oper- ations, useful for validation of the IMB benchmark output. It is also exten- sible, enabling the provision of custom tests for exploring alternate network scenarios other than the tests provided by default.

3.2.2

Memory Micro-Benchmarks

Given the significant data processing elements of many scientific applications, ensuring sufficient throughput of data for compute is key to maintaining a good degree of performance. Memory benchmarks provide an insight into the un- derlying capabilities of a target machine or architecture, highlighting potential bottlenecks that could prove to be an inhibitor of high performance.

STREAM

STREAM [111] is a memory benchmark that by default uses a large block of memory to measure the bandwidth performance of a machine’s Random Access Memory (RAM). It has both C and Fortran implementations, as well as being capable of executing in either a single-thread, OpenMP or MPI setup. Using a large fixed-size block of memory, the benchmark captures the bandwidth of a number of different operations (with differing byte and Floating-Point Operation (FLOP) counts), summarised in Table 3.1.

The STREAM benchmark is particularly useful for capturing the be-

haviour of multi-core contention. When the memory bandwidth is sub-

stantially restricted, Central Processing Units (CPUs) can become memory starved due to the inability of the memory subsystem to sustain sufficient

Operation Kernel Bytes FLOPs

Copy a(i) =b(i) 16 0 Scale a(i) =q∗b(i) 16 1 Sum a(i) =b(i) +c(i) 24 1 Triad a(i) =b(i) +q∗c(i) 24 2

Table 3.1: STREAM Benchmark Operations [111]

throughput. By scaling up the number of cores used per node, the degree to which performance can suffer as a result of an increased load on the memory bus can be captured. Any such memory-starving should manifest itself as poor scaling when the number of cores is increased. It is crucial to identify such behaviour as any applications that process a substantial amount of data (common in scientific simulations) can exhibit memory-bound performance if the bandwidth is insufficient.

CacheBench

CacheBench [121] is a tool designed to capture the bandwidth performance

of the multiple levels of cache that a machine may possess. As part of

LLCbench [120], it provides useful insights into the underlying performance of cache-level memory accesses, a key component of many scientific appli- cations that can process a substantial amount of data. In particular, it can reveal the potential cost of a cache-miss for different levels of cache, crucial given the variety of possible memory access patterns that can arise from dif- ferent data processing requirements. Tests include read performance, write performance and Read/Write/Modify (RWM) performance.

3.2.3

Macro-Benchmarks

Unlike the previous micro-benchmarks designed to capture a single aspect of a system, these macro-benchmarks are intended to be more representative of real-world applications, stressing multiple characteristics of a machine at once. This work focuses on two macro-benchmarks of interest, explored within the

context of performance analysis and modelling.

Hydra

Hydra is a benchmark 3D Eulerian structured mesh hydrocode implemented in Fortran, with which the explosive compression of materials, shock waves, and the behaviour of materials at the interface between components can be investigated. The Hydra benchmark code simulates a cube of mixed mate- rials under stress by discretising the data onto a 3D grid of cells given by

Nx×Ny×Nz and using message passing for parallelisation. Thus, in a

typical Single Program Multiple Data (SPMD) fashion, the 3D cube of data is decomposed onto a number of processing elements (PEs) during execu- tion. During the course of this work Hydra is used as part of a case-study, demonstrating both the performance and optimisation prediction capabili- ties of our performance analysis and modelling efforts. Further information on the Hydra benchmark can be found in Chapter 4.

Orthrus

While simple in description, solving forxin a linear systemAx=B proves

to be an expensive and common problem across a range of high-performance scientific domains [77, 86, 103]. Orthrus is a benchmark 2D/3D radiation solver developed at AWE, intended to explore the use of different linear solver solutions such as Conjugate Gradient (CG) or Algebraic Multi-Grid (AMG). It captures the behaviour of a structured, 7-point stencil, sparse linear system that passes linear solver capabilities to external third-party libraries such as PETSc.

This work modifies the Orthrus benchmark to use one of PETSc’s newer Application Programming Interfaces (APIs), the Distributed Array struc- tured interface introduced in version 3.2. This allows the exploration of per- formance when ghost cells, underlying matrix memory allocation and grid decomposition are all handled exclusively by PETSc, and the correspond-

ing performance of a linear solver approach such as CG within a parallel environment. Further details can be found in Chapter 7.