L3: Data Partitioning and Memory Organization, Synchronization

Transcription

1 Outline More on CUDA L3: Data Partitioning and Organization, Synchronization January 21, First assignment, due Jan. 30 (later in lecture) Error checking mechanisms Synchronization More on data partitioning Reading: GPU Gems 2, Ch. 31; CUDA 2.0 Manual, particularly Chapters 4 and 5 This lecture includes slides provided by: Wen-mei Hwu (UIUC) and David Kirk (NVIDIA) see and Austin Robison (NVIDIA) 2 Today s Lecture Establish background to write your first CUDA code Testing for correctness (a little) Debugging (a little) Core concepts to be reinforced - Data partitioning -Synchronization Questions from Last Time Considering the GPU gets a single copy of the array, can two threads access the shared array at the same time? - Yes, if no bank conflicts. But watch out! Can we have different thread functions for different subsets of data? - Not efficiently. Why do I get the same results every time using a random number generator? - Deterministic if starts with the default (or same) seed. 3 4

2 My Approach to Working with New Systems Approach with caution - May not behave as expected. - Learn about behavior through observation and measurement. - Realize that documentation is not always clear or accurate. Crawl, then walk, then run - Start with something known to work. - Only change one variable at a time. Debugging Using Device Emulation Mode An executable compiled in device emulation mode (nvcc -deviceemu) runs completely on the host using the CUDA runtime - No need of any device and CUDA driver - Each device thread is emulated with a host thread When running in device emulation mode, one can: - Use host native debug support (breakpoints, inspection, etc.) - Access any device-specific data from host code and viceversa - Call any host function from device code (e.g. printf) and vice-versa - Detect deadlock situations caused by improper usage of syncthreads 5 6 ECE 498AL, University of Illinois, Urbana-Champaign Device Emulation Mode Pitfalls Emulated device threads execute sequentially, so simultaneous accesses of the same location by multiple threads could produce different results. Dereferencing device pointers on the host or host pointers on the device can produce correct results in device emulation mode, but will generate an error in device execution mode Results of floating-point computations will slightly differ because of: - Different compiler outputs, instruction sets - Use of extended precision for intermediate results - There are various options to force strict single precision on the host 7 ECE 498AL, University of Illinois, Urbana-Champaign Run-time functions & macros for error checking In CUDA run-time services, cudagetdeviceproperties(deviceprop &dp, d); check number, type and whether device present In libcutil.a of Software Developers Kit, cutcomparef (float *ref, float *data, unsigned len); compare output with reference from CPU implementation In cutil.h of Software Developers Kit (with #define _DEBUG or D_DEBUG compile flag), CUDA_SAFE_CALL(f(<args>)), CUT_SAFE_CALL(f(<args>)) check for error in run-time call and exit if error detected CUT_SAFE_MALLOC(cudaMalloc(<args>)); similar to above, but for malloc calls CUT_CHECK_ERROR( error message goes here ); check for error immediately following kernel execution and if detected, exit with error 8 message

3 Simple working code example from last time Goal for this example: - Really simple but illustrative of key concepts - Fits in one file with simple compile command - Can absorb during lecture What does it do? - Scan elements of array of numbers (any of 0 to 9) - How many times does 6 appear? - Array of 16 elements, each thread examines 4 elements, 1 block in grid, 1 grid threadidx.x = 0 examines in_array elements 0, 4, 8, 12 Known as a threadidx.x = 1 examines in_array elements 1, 5, 9, 13 cyclic data threadidx.x = 2 examines in_array elements 2, 6, 10, 14 distribution threadidx.x = 3 examines in_array elements 3, 7, 11, 15 9 Reductions (from last time) This type of computation is called a parallel reduction - Operation is applied to large data structure - Computed result represents the aggregate solution across the large data structure -Large data structure computed result (perhaps single number) [dimensionality reduced] Why might parallel reductions be well-suited to GPUs? What if we tried to compute the final sum on the GPUs? (next class and assignment) 10 Reminder: Gathering and Reporting Results Global, device functions and excerpts from host, main device int compare(int a, int b) { if (a == b) return 1; return 0; Compute individual global void results compute(int for each *d_in, thread int *d_out) { d_out[threadidx.x] Serialize = 0; final resutls gathering on host for (i=0; i<size/blocksize; i++) { int val = d_in[i*blocksize + threadidx.x]; d_out[threadidx.x] += compare(val, 6); int host void outer_compute (int *h_in_array, int *h_out_array) { compute<<<1,blocksize,msize)>>> (d_in_array, d_out_array); cudamemcpy(h_out_array, d_out_array, BLOCKSIZE*sizeof(int), cudamemcpydevicetohost); main(int argc, char **argv) { for (int i=0; i<blocksize; i++) { sum+=out_array[i]; printf ( Result = %d\n",sum); 11 Gathering Results on GPU: Synchronization void syncthreads(); Functionality: Synchronizes all threads in a block - Each thread waits at the point of this call until all other threads have reached it - Once all threads have reached this point, execution resumes normally Why is this needed? - A thread can freely read the shared of its thread block or the global of either its block or grid. - Allows the program to guarantee partial ordering of these accesses to prevent incorrect orderings. Watch out! - Potential for deadlock when it appears in conditionals 12

4 Gathering Results on GPU for Count 6 global void compute(int *d_in, int *d_out) { d_out[threadidx.x] = 0; for (i=0; i<size/blocksize; i++) { int val = d_in[i*blocksize + threadidx.x]; d_out[threadidx.x] += compare(val, 6); global void compute(int *d_in, int *d_out, int *d_sum) { d_out[threadidx.x] = 0; for (i=0; i<size/blocksize; i++) { int val = d_in[i*blocksize + threadidx.x]; d_out[threadidx.x] += compare(val, 6); synthreads(); if (threadidx.x == 0) { for 0..BKSIZE-1 *d_sum += d_out[i]; Also Atomic Update to Sum Variable int atomicadd(int* address, int val); Increments the integer at address by val. Atomic means that once initiated, the operation executes to completion without interruption by other threads Example: atomicadd(d_sum, d_out_array[threadidx.x]); Programming Assignment #1 Problem 1: In the count 6 example using synchronization, we accumulated all results into out_array[0], thus serializing the accumulation computation on the GPU. Suppose we want to exploit some parallelism in this part, which will likely be particularly important to performance as we scale the number of threads. A common idiom for reduction computations is to use a tree-structured results-gathering phase, where independent threads collect their results in parallel. The tree below illustrates this for our example, with SIZE=16 and BLOCKSIZE=4. out[0] += out[2] Your job is to write this version of the reduction in CUDA. You can start with the sample code, but adjust the problem size to be larger: #define SIZE 256 #define BLOCKSIZE 32 out[0] out[1] out[2] out[3] out[0] += out[1] out[2] += out[3] 15 Another Example: Adding Two Matrices CPU C program void add_matrix_cpu(float *a, float *b, float *c, int N) { int i, j, index; for (i=0;i<n;i++) { for (j=0;j<n;j++) { index =i+j*n; c[index]=a[index]+b[index]; void main() {... add_matrix(a,b,c,n); Example source: Austin Robison, NVIDIA CUDA C program global void add_matrix_gpu(float *a, float *b, float *c, int N) { int i =blockidx.x*blockdim.x+threadidx.x; int j=blockidx.y*blockdim.y+threadidx.y; int index =i+j*n; if( i <N && j <N) c[index]=a[index]+b[index]; void main() { dim3 dimblock(blocksize,blocksize); dim3 dimgrid(n/dimblock.x,n/dimblock.y); add_matrix_gpu<<<dimgrid,dimblock>>>(a,b,c,n); 16

5 Closer Inspection of Computation and Data Partitioning Define 2-d set of blocks, and 2-d set of threads per block dim3 dimblock(blocksize,blocksize); dim3 dimgrid(n/dimblock.x,n/dimblock.y); Each thread identifies what single element of the matrix it operates on int i=blockidx.x*blockdim.x+threadidx.x; int j=blockidx.y*blockdim.y+threadidx.y; int index =i+j*n; if( i <N && j <N) c[index]=a[index]+b[index]; Let blocksize = 2 and N = Closer Inspection of Computation and Data Partitioning Define 2-d set of blocks, and 2-d set of threads per block dim3 dimblock(blocksize,blocksize); dim3 dimgrid(n/dimblock.x,n/dimblock.y); Each thread identifies what single element of the matrix it operates on int i=blockidx.x*blockdim.x+threadidx.x; int j=blockidx.y*blockdim.y+threadidx.y; int index =i+j*n; if( i <N && j <N) c[index]=a[index]+b[index]; Let blocksize = 2 and N = 4 BLOCK (0,0) 0,0 0,1 0,0 0, ,0 1,1 1,0 1, ,0 0,1 0,0 0, ,0 1,1 1,0 1, BLOCK (1,0) BLOCK (0,1) BLOCK (1,1) Data Distribution to Threads Many data parallel programming languages have mechanisms for expressing how a distributed data structure is mapped to threads - That is, the portion of the data a thread accesses (and usually stores locally) - Examples: HPF, Chapel, UPC Reasons for selecting a particular distribution - Sharing patterns: group together according to data reuse and communication needs - Affinity with other data - Locality: transfer size and capacity limit on shared - Access patterns relative to computation (avoid bank conflicts) - Minimizing overhead: Cost of copying to host and between global and shared Concept of Data Distributions in CUDA This concept is not completely natural for CUDA - Implicit from computation partitioning and access expressions within threads - Within a block of threads, most is shared, so not really distributed Nevertheless, I think it is still useful - Spatial understanding of computation and data organization (helps conceptualize) - Distribution of data needed for objects too large to fit in shared (i.e., partitioning across blocks in a grid) - Helpful in putting CUDA in context of other languages 19 20

6 Common Data Distributions Consider a 1-Dimensional array CYCLIC: for (i = 0; i<blocksize; i++) d_in [i*blocksize + threadidx.x]; BLOCK: for (i=threadidx.x*blocksize; i<(threadidx.x+1) *BLOCKSIZE; i++) d_in[i]; BLOCK-CYCLIC: Programming Assignment #1, cont. Problem 2: Computation Partitioning & Data Distribution Using the matrix addition example from Lecture 2 class notes, develop a complete CUDA program for integer matrix addition. Initialize the two input matrices using random integers from 0 to 9 (as in the count 6 example). Initialize the ith entry in both a[i] and b[i], so that everyone s matrix is initialized the same way. Your CUDA code should use a data distribution for the input and output matrices that exploits several features of the architecture to improve performance (although the advantages of these will be greater on objects allocated to shared and with reuse of data within a block). a grid of 16 square blocks of threads (>= # multiproc) each block executing 64 threads (> warpsize) each thread accessing 32 elements (better if larger) Within a grid block, you should use a BLOCK data distribution for the columns, so that each thread operates on a column. This should help reduce bank conflicts. 21 Return the output array. 22 Hardware Implementation: Architecture The local, global, constant, and texture spaces are regions of device Each multiprocessor has: - A set of 32-bit registers per processor - On-chip shared - Where the shared space resides - A read-only constant cache - To speed up access to the constant space - A read-only texture cache - To speed up access to the texture space Device Multiprocessor N Multiprocessor 2 Multiprocessor 1 Processor 1 Shared Processor 2 Device Global, constant, texture memories 23 ECE 498AL, University of Illinois, Urbana-Champaign Processor M Instruction Unit Constant Cache Texture Cache Programming Model: Spaces Each thread can: - Read/write per-thread registers - Read/write per-thread local - Read/write per-block shared - Read/write per-grid global - Read only per-grid constant - Read only per-grid texture Host The host can read/write global, constant, and texture 24 ECE 498AL, University of Illinois, Urbana-Champaign Grid Block (0, 0) Local Global Constant Texture Shared Thread (0, 0) Thread (1, 0) Local Block (1, 0) Shared Thread (0, 0) Thread (1, 0) Local Local

7 Threads, Warps, Blocks There are (up to) 32 threads in a Warp - Only <32 when there are fewer than 32 total threads There are (up to) 16 Warps in a Block Each Block (and thus, each Warp) executes on a single SM G80 has 16 SMs At least 16 Blocks required to fill the device More is better - If resources (registers, thread space, shared ) allow, more than 1 Block can occupy each SM 25 ECE 498AL, University of Illinois, Urbana-Champaign Hardware Implementation: A Set of SIMD Multiprocessors A device has a set of multiprocessors Device Each multiprocessor is a Multiprocessor N set of 32-bit processors Multiprocessor 2 with a Single Instruction Multiprocessor 1 Multiple Data architecture - Shared instruction unit At each clock cycle, a multiprocessor executes the same instruction on a group of threads called a warp The number of threads in a warp is the warp size Processor 1 Processor 2 26 ECE 498AL, University of Illinois, Urbana-Champaign Processor M Instruction Unit Hardware Implementation: Execution Model Terminology Review Each thread block of a grid is split into warps, each gets executed by one multiprocessor (SM) - The device processes only one grid at a time Each thread block is executed by one multiprocessor - So that the shared space resides in the on-chip shared A multiprocessor can execute multiple blocks concurrently - Shared and registers are partitioned among the threads of all concurrent blocks - So, decreasing shared usage (per block) and register usage (per thread) increases number of blocks that can run concurrently device = GPU = set of multiprocessors Multiprocessor = set of processors & shared Kernel = GPU program Grid = array of thread blocks that execute a kernel Thread block = group of SIMD threads that execute a kernel and can communicate via shared Location Cached Access Who Local Off-chip No Read/write One thread Shared On-chip N/A - resident Read/write All threads in a block Global Off-chip No Read/write All threads + host Constant Off-chip Yes Read All threads + host Texture Off-chip Yes Read All threads + host 27 ECE 498AL, University of Illinois, Urbana-Champaign 28 ECE 498AL, University of Illinois, Urbana-Champaign

8 Access Times Register dedicated HW - single cycle Shared dedicated HW - single cycle Local DRAM, no cache - *slow* Global DRAM, no cache - *slow* Constant DRAM, cached, 1 10s 100s of cycles, depending on cache locality Texture DRAM, cached, 1 10s 100s of cycles, depending on cache locality Instruction (invisible) DRAM, cached Language Extensions: Variable Type Qualifiers Scope Lifetime device local int LocalVar; local thread thread device shared int SharedVar; shared block block device int GlobalVar; global grid application device constant int ConstantVar; constant grid application device is optional when used with local, shared, or constant Automatic variables without any qualifier reside in a register - Except arrays that reside in local 29 ECE 498AL, University of Illinois, Urbana-Champaign 30 ECE 498AL, University of Illinois, Urbana-Champaign Variable Type Restrictions Pointerscan only point to allocated or declared in global : - Allocated in the host and passed to the kernel: global void KernelFunc(float* ptr) - Obtained as the address of a global variable: float* ptr = &GlobalVar; Relating this Back to the Count 6 Example A few variables (i, val) are going in device registers We are copying input array into device and output array back to host - These device copies of the data all reside in global Suppose we want to access only shared on the devices - Cannot copy into shared from host! - Requires another copy from/to global to/from shared Other options - Use constant for input array (not helpful for current implementation, but possibly useful) - Use shared for output array and just return single result (today s version with synchronization) 31 ECE 498AL, University of Illinois, Urbana-Champaign 32

9 Summary of Lecture Some error checking techniques to determine if program is correct Synchronization constructs Discussion of Data Partitioning First assignment, due FRIDAY, JANUARY 30, 5PM Next Week Reasoning about parallelization - When is it safe? 33 34