DIFFERENTIAL. Tomáš Oberhuber, Atsushi Suzuki, Jan Vacata, Vítězslav Žabka

Size: px

Start display at page:

Download "DIFFERENTIAL. Tomáš Oberhuber, Atsushi Suzuki, Jan Vacata, Vítězslav Žabka"

Arabella Mitchell
5 years ago
Views:

1 USE OF FOR Tomáš Oberhuber, Atsushi Suzuki, Jan Vacata, Vítězslav Žabka Faculty of Nuclear Sciences and Physical Engineering Czech Technical University in Prague Mini workshop on advanced numerical methods for parallel computers GP

2 OVERVIEW GP GP

3 NEED FOR MORE COMPUTATIONAL POWER we want to do more and more complex computations they require more powerful CPUs we cannot increase the power of CPU by increasing the clock frequency anymore we may search for more efficient architectures or for parallel computing using multicore CPUs GP

4 IS MULTICORE ENOUGH? However adding more cores is not so simple because of shared memory architecture it is very difficult to build parallel system with shared memory and more then 100 cores for more then 100 cores we usually have to switch to distributed systems the latest mainframe z10 supports up to 64 cores September 26, Intel: 80 cores by GP

5 DISADVANTAGES OF CPU CPU is designed to process general code the main parts of CPU design are pipeline and cache pipeline allows more efficient processing of instructions it needs to predict conditions in code - speculative execution in average there is 1 condition instruction per 6 instructions cache allows to hide big latency of common RAM both require complicated algorithms majority of transistors is spent on cache and speculative execution and not for main computing CPU is not well designed for numerical computing. GP

6 ADVANTAGES OF GPU GPU - graphics processing unit GPU is designed to run simultaneously up to 240 threads - virtually up to threads 1 threads must be independent - it is not known in what order the are going to be scheduled intensive computing and only few conditions is assumed there is no speculative execution there is no cache GPU is optimised for sequential memory access GB/s GP 1 nvidia Tesla

7 ADVANTAGES OF GPU GP FIGURE: Source nvidia Programming Guide

8 COMPARISON CPU VS. GPU For approx EUR one can buy nvidia Intel Core i7-975 TESLA S1060 Extreme Quad-Core Transistors millions 731 millions Clock 1.3 GHz 3.3 GHz Threads Num Peak. Perf. 936 GFlops 50 GFlops Bandwidth 102 GB/s 25.6 GB/s RAM 4 GB 48 GB nvidia predicts 570 times faster GPUs until 2015 GP

9 GPU = graphics processing unit accelerators of algorithms in 3D graphics and visualisation originally aimed for computer games psychological disadvantage of GPU even today typical run transformation of thousands of triangles applying textures projection to frame buffer no data dependency GP

10 GP assume having a rectangle and apply gray scale texture with 800x600 pixels project it one-to-one to framebuffer/screen with resolution 800x600 pixels we can apply two textures and mix them T (i, j) = α 1 T 1 (i, j) + α 2 T 2 (i, j), for all pixels (i, j) it equals weighted sum of two matrices from R 800,600 result of which is stored in framebuffer/screen GPGPU = General-purpose computing on graphics processing units (2003) GP

11 ESSENCE OF GPGPU at the beginnings we had to use OpenGL for GPGPU problems were reformulated in terms of textures and operations on pixels game developers needed more flexible hardware pixel shaders simple programmable processors for operations with pixels support for single precision arithmetic limited number of instructions GP

12 CUDA = Compute Unified Device Architecture - nvidia 15 February 2007 significantly simplifies GPGPU programming completely avoids use of OpenGL and texture-like formulations of problems based on simple extension of C-language support only for nvidia graphic cards (or TESLA cards) It is very easy to write code for CUDA but one must have good knowledge of hardware to get efficient code. GP

13 CUDA ARCHITECTURE I. CUDA device = device for simultaneous processing of thousands of independent threads CUDA thread is lightweight structure - easy and efficient to create communication between processing units is the main difficulty in parallel computing. we cannot hope to be able to synchronise 240 resp threads efficiently CUDA architecture introduces small groups of threads with shared memory which can be synchronised GP

14 CUDA ARCHITECTURE II. 10-Series architecture (GeForce 2xx, TESLA) consists of 30 multiprocessors each has 8 thread processors GP FIGURE: Source nvidia Programming Guide From the hardware architecture thread hierarchy follows:

15 THREAD HIERARCHY threads are grouped into blocks one block is processed on one multiprocessor threads in the same block share very fast memory with low latency 16kB threads in the same block can be synchronised there can be up to 512 threads in one block multiprocessor must switch between them blocks of threads are grouped into grids GP

16 EXECUTION MODEL GP FIGURE: Source nvidia: Getting Started with CUDA

17 MEMORY LAYOUT GP FIGURE: Source nvidia: Getting Started with CUDA

18 MEMORY HIERARCHY GP FIGURE: Source nvidia: Getting Started with CUDA

19 COALESCED ACCES majority of GPU global memory acces consists of texture acces GPU is strongly optimised for sequential global memory acces one should avoid random acces to global memory coalesced memory acces can significantly reduce (up to 16x) number of memory transactions GP

20 COALESCED ACCES GP FIGURE: Source nvidia: nvidia CUDA programming guide

21 PROGRAMMING IN CUDA I. programming for CUDA consists of writing of kernels = code processed by one thread kernels do not support recursion they support branching - it can reduce efficiency The following code in C int main() { float A[ N ], B[ N ], C[ N ];... for( int i = 0; i <= N-1, i ++ ) C[ i ] = A[ i ] + B[ i ]; } GP

22 PROGRAMMING IN CUDA II. can be replaced by global void vecadd( float* A, float* B, float* C ) { int i = threadidx.x; C[ i ] = A[ i ] + B[ i ]; } int main() { // allocate A, B, C on the CUDA device... vecadd<<< 0,N-1 >>>( A, B, C ); } GP

23 ALLOCATING MEMORY ON THE CUDA DEVICE // Allocate input vectors h_a and h_b in host memory float* h_a = malloc(size); float* h_b = malloc(size); // Allocate vectors in device memory float* d_a; cudamalloc((void**)&d_a, size); float* d_b; cudamalloc((void**)&d_b, size); float* d_c; cudamalloc((void**)&d_c, size); // Copy vectors from host memory to device memory cudamemcpy(d_a, h_a, size, cudamemcpyhosttodevice); cudamemcpy(d_b, h_b, size, cudamemcpyhosttodevice); // Invoke kernel VecAdd<<< 0, N-1 >>>(d_a, d_b, d_c); // Copy result from device memory to host memory // h_c contains the result in host memory cudamemcpy(h_c, d_c, size, cudamemcpydevicetohost); // Free device memory cudafree(d_a); cudafree(d_b); cudafree(d_c); GP Compile with nvcc

24 PDES IN CUDA I. Consider the following parabolic PDE u t (x, t) + F (x, u, u, 2 u, t) = 0 on (0, T ] Ω, where Ω is domain in R 2. u(x, 0) = u ini (x), on Ω, u(x, t) = g(x), on Ω, GP

25 PDES IN CUDA II. Assume that Ω [0, 1] [0, 1] and define a numerical grid ω h = {(ih, jh) i = 1 N 1, j = 1 N 1}, ω h = {(ih, jh) i = 0 N, j = 0 N}, ω h = ω h \ ω h, for N N + and h := 1/N. GP

26 PDES IN CUDA III. After discretisation in space (using e.g. the finite difference method) we obtain the following system of ODEs d dt u ij (t) + F ij (u h, u h, 2 u h, t) = 0 on (0, T ] ω h, u ij (0) = u ini (ih, jh), on ω h, u ij (t) = g(ih, jh), on ω. GP

27 PDES IN CUDA IV. This system of ODEs can be also written as with initial values d dt u ij (t) = f(u h, t) ij, for i, j = 0, N, u ij (0) = u ini (ih, jh), for i, j = 0, N. We solve it by the following Runge-Kutta-Merson method with adaptivity in time: GP

28 PDES IN CUDA V. 1. Set τ := τ 0 for arbitrary τ 0 > Compute the grid functions k 1 ij, k2 ij, k3 ij, k4 ij, k5 ij as: ( kij 1 := τf t, u h) ij ( ) kij 2 := τf t + τ/3, u h + k 1 /3 ij ( ) kij 3 := τf t + τ/2, u h + k 1 /6 + k 2 /2 ij ( ) kij 4 := τf t + τ/2, u h + k 1 /8 + 3k 3 /8 ij ( kij 5 := τf t + τ, u h + k 1 /2 3k 3 /2 + 2k 4). ij for i = 0, N 1 and j = 0,, N Evaluate the error of the approximation with the current time step τ as 1 e := max 1 i=0,,n1 3 5 k1 ij 9 10 k3 ij k3 ij 1 10 k5 ij. j=0,,n2 4. If this error is smaller then given tolerance ) ɛ update u h as u h ij := uh ij (k + ij 1 + 4k4 ij + k5 ij /6 for i = 0, N 1, j = 0,, N 2 and set t := t + τ. 5. Independently { on the previous condition update τ as: τ := min τ 4 ( } ɛ 5 5, T t. e)1 6. Repeat whole process with the new τ i.e. go to the step 1. GP

29 PDES IN CUDA VI. Evaluation of each k 1,, k 6 as well as e and arguments of f is implemented in separate kernels. GP

30 APPLICATION TO MEDICAL IMAGE SEGMENTATION BY MODIFIED ALLEN-CAHN EQUATION ξu t = ξ (g (I ) u) + g (I ) u(x, 0) = u ini(x) on Ω, u(x, t) = g(x)on Ω, where «1 f0 + ξf u on(0, T ] Ω, ξ I = G σ I g(s) = 1/(1 + λs) is the Perrona-Malik function f 0(u) = u(1 u)(u 1/2) F = F (x) is a forcing term GP V. Žabka, 2008

31 MRI SEGMENTATION GP FIGURE: Segmentation of MRI data by the Allen-Cahn equation

32 SPEEDUP OF THE METHOD IN LINES IN CUDA Comparison of CPU time vs GPU time on Intel Core 2 Duo E cores at 2.33 GHz, 4 MB L2 cache 12.8 GB/s GPU time (nvidia GeForce 8800 GT cores at 1.62 GHz, 512 MB RAM 60.8 GB/s Resolution CPU (s) GPU (s) Speedup GP

33 METHOD IN CUDA we implemented GMRES method for solving linear system Ax = b - J. Vacata, 2008 by Google, in March 2009 we were the only one having GMRES for sparse matrices in CUDA implementing GMRES in CUDA is straightforward we need format for storing sparse matrices fulfilling coalesced memory acces when computing matrix-vector product GP

34 CSR FORMAT FOR SPARSE MATRICES values[] columns[] row pointers Figure 4: CSR format GP

35 PCSR FORMAT FOR SPARSE MATRICES Figure 5: Parallel CSR format values[] columns[] non zero els[] block pointers[] GP

36 We tested CUDA GMRES solver on the following matrices - helm2d03, language and cage14. GP

37 CUDA GMRES SPEEDUP Results obtained in the single-precision arithmetic on Intel Core 2 Duo E cores at 2.33 GHz, 4 MB L2 cache 12.8 GB/s nvidia GeForce 8800 GT cores at 1.62 GHz, 512 MB RAM 60.8 GB/s Matrix Non-zero els. CPU (s) GPU (s) Speedup helm2d03 2,741, language 1,216, cage14 27,130, GP

38 FUTURE OF GP GPU is much better designed for numerical computations However it is still understood as a computer games device even with CUDA, the code development takes a lot of time libraries only by nvidia weak support of double precision limited memory 4GB almost no experience with GPU clusters GPU is still quickly developing therefore it is changing a lot possible fusion with CPU it would avoid necesity of CPU GPU data transfer but common RAM is not sequentialy optimised!!! GP

39 FUTURE OF CUDA? nvidia is now leader in GPGPU thanks to CUDA CUDA does not support GPU by AMD new standard OpenCL CUDA still does not have good support for computation on more cards GP

40 THANK YOU To start with CUDA visit or just type "CUDA" into Google. GP

Accelerator cards are typically PCIx cards that supplement a host processor, which they require to operate Today, the most common accelerators include

3.1 Overview Accelerator cards are typically PCIx cards that supplement a host processor, which they require to operate Today, the most common accelerators include GPUs (Graphics Processing Units) AMD/ATI