GPGPU. Alan Gray/James Perry EPCC The University of Edinburgh.

Size: px

Start display at page:

Download "GPGPU. Alan Gray/James Perry EPCC The University of Edinburgh."

Bathsheba Osborne
6 years ago
Views:

1 GPGPU Alan Gray/James Perry EPCC The University of Edinburgh

2 Contents Introduction GPU Technology Programming GPUs GPU Performance Optimisation 2

3 Introduction 3

were achieved through increases in the clock frequency of the core.

4 Introduction Central Processing Unit (CPU) of a computer system must be able to perform a wide variety of tasks efficiently. Until recently, most CPUs comprised of 1 sophisticated compute core (for arithmetic), plus complex arrangement of controllers, memory caches, etc Increases in CPU performance were achieved through increases in the clock frequency of the core. This has now reached it s limit mainly due to power requirements and heat dissipation restrictions Today, processor cores are not getting any faster, but instead we are getting increasing numbers of cores per chip. Plus other forms of parallelism such as SSE vector instruction support Harder for applications to exploit such technology advances. 4

chip: the Graphics Processing Unit (GPU) Silicon largely dedicated to high numbers

GPUs work in tandem with the CPU (communicating over PCIe), and are responsible for

5 Introduction Meanwhile. In recent years computer gaming industry has driven development of a different type of chip: the Graphics Processing Unit (GPU) Silicon largely dedicated to high numbers (hundreds) of simplistic cores, at the expense of controllers, caches, sophistication etc GPUs work in tandem with the CPU (communicating over PCIe), and are responsible for generating the graphical output display Computing pixel values Inherently parallel - each core computes a certain set of pixels Architecture has evolved for this purpose 5

6 Introduction GPU peak performance has been increasing much more rapidly than CPU Can we use GPUs for general purpose computation? Yes (with some effort). 6

7 GPGPU GPGPU: General Purpose computation on Graphics Processing Units. GPU acts as an accelerator to the CPU (heterogeneous system) Most lines of code are executed on the CPU (serial computing) Key computational kernels are executed on the GPU (stream computing) Taking advantage of the large number of cores and high graphics memory bandwidth AIM: code performs better than use of CPU alone. Source: NVIDIA CUDA Programming Guide, serial serial stream stream 7

8 GPGPU: Stream Computing Data set decomposed into a stream of elements A single computational function (kernel) operates on each element thread defined as execution of kernel on one data element Multiple cores can process multiple elements in parallel i.e. many threads running in parallel Suitable for data-parallel problems Modern GPUs are more flexible than traditional stream processors Some level of communication is possible between threads, but with restrictions 8

GPUs in HPC Can augment each node of a system with GPU(s) Use MPI between nodes as normal November 2010 Top500 list: GPUs (next generation will have GPUs) GPUs GPUs

9 GPUs in HPC Can augment each node of a system with GPU(s) Use MPI between nodes as normal November 2010 Top500 list: GPUs (next generation will have GPUs) GPUs GPUs GPUs now firmly established in HPC industry They possess those characteristics necessary for approaching the Exascale : very high numbers of simple low-power cores 9

10 Programming Considerations Standard (CPU) code will not run on a GPU unless it is adapted Programmer must decompose problem onto the hardware in a specific way (e.g. using a hierarchical thread/grid model in CUDA) Manage data transfers between the separate CPU and GPU memory spaces. Traditional language (C, C++, Fortran etc) not enough, need extensions, directives, or new language. Once code is ported to GPU, it is usually the case that much more optimization work is required to tailor it to the hardware to achieve decent performance Despite this, many researchers reporting impressive results Across a wide range of application areas 10

11 GPU Technology 11

12 Latest Technology NVIDIA Tesla HPC specific GPUs have evolved from GeForce series Leading product: the focus of this talk Intel AMD Knights Corner many-core x86 chip is a derivative of delayed Larrabee Interesting hybrid chip, not yet released FireStream HPC specific GPUs have evolved from (ATI) Radeon series Lagging behind NVIDIA (both hardware and software) but may catch up in the future 12

NVIDIA Tesla NVIDIA Tesla: derivatives of the GeForce chips with HPC enhancements

memory On-chip automatic caches L2 shared between all cores, L1 per SM (32 cores) 6 GB

13 NVIDIA Tesla NVIDIA Tesla: derivatives of the GeForce chips with HPC enhancements Released May 2010: Tesla 20-series (codenamed Fermi) Tesla C cores 515 Gflops (Double Precision) 1.03 Tflops (Single Precision) Error Correcting Code support For all internal and external memory On-chip automatic caches L2 shared between all cores, L1 per SM (32 cores) 6 GB GDDR5 C2050 variant with lower memory also available Rack-mount unit available (S2050/S2070): contains 4 GPUs 13

14 Programming GPUs 14

15 Programming Options CUDA C is the proprietary interface to the NVIDIA architecture, and most common programming method at the moment NVIDIA only Cuda Fortran also available through PGI OpenCL: Cross platform API Directives based approaches 15

16 NVIDIA CUDA CUDA allows NVIDIA GPUs to be programmed in C and C++ defines language extensions for defining kernels kernels execute in multiple threads concurrently on the GPU provides API functions for e.g. device memory management PGI provide a commercial Fortran version of CUDA

17 CUDA Concepts The GPU acts as an accelerator to the main CPU Most code still runs on the main CPU including startup code, I/O, user interface Key computational kernels are executed on the GPU Characteristics of kernels: simple operations repeated many times on different data items typically found in innermost loop of code account for a significant proportion of overall runtime CUDA allows us to implement the kernels on the GPU

18 Stream Multiprocessors NVIDIA GPUs are partitioned into Stream Multiprocessors each SM contains a number of cores plus a shared memory

19 Problem Decomposition CUDA enables a 2-level decomposition of a problem into threads: multiple threads per block multiple blocks per grid This is so that the code can map efficiently to a variety of hardware thread blocks map onto SMs (automatically) an SM may run multiple thread blocks no need to change code in order to scale to larger GPUs CUDA allows thread blocks and grid to be 1D, 2D or 3D whichever maps best onto algorithm

20 E.g grid of 2x2=4 blocks, each with 3x2=6 threads (24 threads total) 20

21 CUDA C Syntax CUDA extends C with new syntax for defining and launching kernels The global declaration specifier defines a kernel when called, a kernel runs in parallel in many CUDA threads on the GPU whereas normal C functions run in serial on the CPU New <<<...>>> syntax is used to specify grid and block dimensions when calling a kernel CUDA also adds useful global variables (e.g. threadidx, blockdim) and functions (e.g. cudamalloc, cudamemcpy)

22 CUDA C Example Example kernel and invocation: global void vectoradd(float *a, float *b, float *c) { int i = threadidx.x; c[i] = a[i] + b[i]; } int main() { dim3 dimgrid(1); /* 1 block per grid (1D) */ dim3 dimblock(n); /* N threads per block (1D) */ vectoradd<<<dimgrid, dimblock>>>(a, b, c); } The kernel is executed in parallel by N threads, each processing a single element of the vector

23 2D Example global void matrixadd(float a[n][n], float b[n][n], float c[n][n]) { int i = threadidx.x; int j = threadidx.y; } c[i][j] = a[i][j] + b[i][j]; int main() { dim3 dimgrid(1); /* 1 block per grid (1D) */ dim3 dimblock(n, N); /* NxN threads per block (2D) */ matrixadd<<<dimgrid, dimblock>>>(a, b, c); }

24 Multiple Block Example We need to use multiple blocks in order to utilise multiple SMs on the GPU global void matrixadd(float a[n][n], float b[n][n], float c [N][N]) { int i = blockidx.x * blockdim.x + threadidx.x; int j = blockidx.y * blockdim.y + threadidx.y; } c[i][j] = a[i][j] + b[i][j]; int main() { } dim3 dimgrid(n/16,n/16); /* (N/16)x(N/16) blocks/grid (2D) */ dim3 dimblock(16, 16); /* 16x16 threads/block (2D) */ matrixadd<<<dimgrid, dimblock>>>(a, b, c);

25 Memory Management - allocation The GPU has a separate memory space from the host CPU We cannot simply pass normal C pointers to CUDA threads Need to manage GPU memory and copy data to and from it explicitly cudamalloc is used to allocate GPU memory cudafree releases it again float *a; cudamalloc((void **)&a, N*sizeof(float)); cudafree(a);

26 Memory Management - cudamemcpy Once we've allocated GPU memory, we need to be able to copy data to and from it cudamemcpy does this: cudamemcpy(a, (void *)input, N*sizeof(float), cudamemcpyhosttodevice); cudamemcpy((void *)output, c, N*sizeof(float), cudamemcpydevicetohost); Transfers between host and device memory are relatively slow and can become a bottleneck, so should be minimised when possible

27 CUDA Fortran Allows Fortran codes to take advantage of GPU acceleration Available in the commercial PGI Fortran compiler from the Portland Group Very similar to CUDA C define kernels to be executed on the device with global attribute invoke them using <<< >>> syntax same API functions available (cudamalloc, cudafree, cudamemcpy, etc.)

28 CUDA Fortran Example! Kernel declaration attributes(global) subroutine vectoradd(a, b, c) real, dimension(*) :: a, b, c integer :: i i = threadidx%x c(i) = a(i) + b(i) end subroutine! Kernel invocation call vectoradd<<<1, 64>>>(a, b, c)

29 Compiling CUDA Code CUDA C code is compiled using nvcc: nvcc o example example.cu CUDA Fortran is compiled using PGI compiler either use.cuf filename extension for CUDA files or pass Mcuda to the compiler command line

30 OpenCL Overview OpenCL is an open standard for developing parallel applications on heterogeneous architectures originally developed by Apple supports CPUs, GPUs (not just NVIDIA) and other devices analogous to OpenGL and OpenAL now on version 1.1 Many similarities with CUDA ability to define kernels which execute on the GPU device similar C APIs multi-dimensional problem space with multiple levels of decomposition NVIDIA support both CUDA and OpenCL as APIs to the hardware. But put much more effort into CUDA CUDA more mature, well documented and performs better See

31 Example OpenCL kernel kernel void vectoradd(global const float *a, global const float *b, global float *c) { int i = get_global_id(0); c[i] = a[i] + b[i]; } kernel and global are OpenCL extensions to C get_global_id is OpenCL function Performs similar role to CUDA s blockidx/threadidx

32 Accelerator Directives Language extensions, e.g. Cuda or OpenCL, allow programmers to interface with the GPU This gives control to the programmer, but is often tricky and time consuming, and results in complex/non-portable code An alternative approach is to allow the compiler to automatically accelerate code sections on the GPU (including decomposition, data transfer, etc). There must be a mechanism to provide the compiler with hints regarding which sections to be accelerated, parallelism, data usage, etc Directives provide this mechanism Special syntax which is understood by accelerator compilers and ignored (treated as code comments) by non-accelerator compilers. Same source code can be compiled for CPU/GPU combo or CPU only c.f. OpenMP 32

33 Accelerator Directives Compiler Availability PGI Accelerator Compiler for C/Fortran Using directives, translates to CUDA (future releases to PTX) NVIDIA GPUs only CAPS HMPP compiler Using directives, translates to CUDA or OpenCL NVIDIA or AMD GPUs Recently announced Pathscale compiler supports NVIDIA GPUs through HMPP programming model Cray compiler Under development to incorporate accelerator directives Not yet released All of above are commercial products Directives different but similar across products 33

34 OpenMP Accelerator Directives There is an effort underway to standardise accelerator directives. Cray, PGI, CAPS (plus several other organisations including EPCC) have formed a subcommittee of the OpenMP committee, looking at extending the OpenMP directive standard to support accelerators. The Cray directives are a prototype of such an OpenMP standard 34

35 GPU Performance Optimisation 35

36 Hardware NVIDIA accelerated system: Memory Memory 36

37 GPU vs CPU: Theoretical Peak capabilities NVIDIA Fermi AMD Magny-Cours (6172) Cores 448 (1.15GHz) 12 (2.1GHz) Operations/cycle 1 4 DP Performance (peak) 515 GFlops 101 GFlops Memory Bandwidth (peak) 144 GB/s 27.5 GB/s GPU theoretical advantage is ~5x for both compute and main memory bandwidth Application performance very much depends on application Typically a small fraction of peak Depends how well application is suited to/tuned for architecture 37

38 GPU performance inhibitors Lack of available parallelism Copying data to/from device Global memory latency Global memory bandwidth Code branching Device under-utilisation This lecture will address each of these And advise how to maximise performance Concentrating on NVIDIA, but many concepts will be transferable to e.g. AMD 38

39 Exploiting parallelism GPU performance relies on parallel use of many threads Amdahl s law for parallel speedup: P αp + (1 α) P: number of parallel tasks α: fraction of app which is serial P is very large, even within a single GPU α must be extremely small to achieve good speedup Effort must be made to exploit as much parallelism as possible within application May involve rewriting/refactoring 39

40 Host Device Data Copy CPU (host) and GPU (device) have separate memories. All data read/written on the device must be copied to/from the device (over PCIe bus). This very expensive Must try to minimise copies Keep data resident on device May involve porting more routines to device, even if they are not computationally expensive Might be quicker to calculate something from scratch on device instead of copying from host 40

Data copy optimisation example Loop over timesteps

expensive_routine_on_device(data_on_device) copy data from device to host End

outside of loop copy data from host to device Loop over timesteps

41 Data copy optimisation example Loop over timesteps inexpensive_routine_on_host(data_on_host) copy data from host to device expensive_routine_on_device(data_on_device) copy data from device to host End loop over timesteps Port inexpensive routine to device and move data copies outside of loop copy data from host to device Loop over timesteps inexpensive_routine_on_device(data_on_device) expensive_routine_on_device(data_on_device) End loop over timesteps copy data from device to host 41

42 Code Branching On NVIDIA GPUs, there are less instruction scheduling units than cores Threads are scheduled in groups of 32, called a warp N.B. It may take multiple cycles to process all threads in a warp, e.g. 4 cycles on Tesla 10-series SM, which only has 8 cores Threads within a warp must execute the same instruction in lock-step (on different data elements) The CUDA programming allows branching, but this results in all cores following all branches With only the required results saved This is obviously suboptimal Must avoid intra-warp branching wherever possible (especially in key computational sections) 42

43 Branching example E.g you want to split your threads into 2 groups: threadid = blockidx.x*blockdim.x + threadidx.x; if (threadid%2 == 0) else Threads within warp diverge threadid = blockidx.x*blockdim.x + threadidx.x; if ((threadid/blockdim.x)%2 == 0) else Threads within warp follow same path 43

44 Occupancy and Memory Latency hiding Programmer decomposes loops in code to threads Obviously, there must be at least as many total threads as cores, otherwise cores will be left idle. For best performance, actually want #threads >> #cores Accesses to global memory have several hundred cycles latency When a thread stalls waiting for data, if another thread can switch in this latency can be hidden. NVIDIA GPUs have very fast thread switching, and support many concurrent threads Fermi supports up to 1536 concurrent threads on an SM, e.g. if there are 256 threads per block, it can run up to 6 blocks concurrently per SM. Remaining blocks will queue. But note that resources must be shared between threads: High use of on-chip memory and registers will limit number of concurrent threads. Best to experiment measuring performance NVIDIA provide a CUDA Occupancy Calculator spreadsheet to help. 44

thread/block ID Loop over j from 1 to 512 independent iteration 2D

45 Occupancy example Loop over i from 1 to 512 Loop over j from 1 to 512 independent iteration Original code 1D decomposition Calc i from thread/block ID Loop over j from 1 to 512 independent iteration 2D decomposition Calc i & j from thread/block ID independent iteration 512 threads 262,144 threads 45

46 Memory coalescing Global memory bandwidth for graphics memory on GPU is high compared to CPU But there are many data-hungry cores Memory bandwidth is a botteneck Maximum bandwidth achieved when data is loaded for multiple threads in a single transaction: coalescing This will happen when data access patterns meet certain conditions: 16 consecutive threads (half-warp) must access data from within the same memory segment E.g. condition met when consecutive threads read consecutive memory addresses within a warp. Otherwise, memory accesses are serialised, significantly degrading performance Adapting code to allow coalescing can dramatically improve performance 46

Memory coalescing example Condition met when consecutive threads read consecutive memory addresses In C, outermost index runs fastest row = blockidx.x*blockdim.x + threadidx.

47 Memory coalescing example Condition met when consecutive threads read consecutive memory addresses In C, outermost index runs fastest row = blockidx.x*blockdim.x + threadidx.x; for (col=0; col<n; col++) output[row][col]=2*input[row][col]; Not coalesced col = blockidx.x*blockdim.x + threadidx.x; for (row=0; row<n; row++) output[row][col]=2*input[row][col]; coalesced 47

48 Use of On-Chip Memory Global Memory accesses can be avoided altogether if the on-chip memory and registers can be utilised. But these are small Shared memory: shared between threads in a block Prefix variable declarations with shared qualifier Fermi has 64 kb configurable as shared or cached partitioned as 16KB/48KB or 48KB/16KB Automatic caching in Fermi GPUs, but you may get better results doing it manually (but can be very involved) Constant memory: 64kB read only memory Prefix variable declarations with constant qualifier and use cudamemcpytosymbol to copy from host (see programming guide) Registers: will be utilised automatically, but sometimes you can manipulate this in you favour by e.g. copying key data to small temporary data structures. 48

49 Conclusions GPUs offer performance advantages over CPUs And are now firmly established in the HPC industry Programming GPUs is more complex than CPUs NVIDIA GPUs are currently leaders in the field CUDA is the most prominent (and mature) programming model But for NVIDIA GPUs only OpenCL, similar to CUDA, is a cross-platform alternative (but is not so mature) Directives based techniques are promising for the future Performance optimisation is essential to get the most from GPUs It is important to have a good understanding of the application, architecture and programming model. 49

GPU Performance Optimisation. Alan Gray EPCC The University of Edinburgh

GPU Performance Optimisation. Alan Gray EPCC The University of Edinburgh GPU Performance Optimisation EPCC The University of Edinburgh Hardware NVIDIA accelerated system: Memory Memory GPU vs CPU: Theoretical Peak capabilities NVIDIA Fermi AMD Magny-Cours (6172) Cores 448 (1.15GHz)