ENCM 501 Winter 2017 Assignment 6 for the Week of February 27

Transcription

1 page of 8 ENCM 5 Winter 27 Assignment 6 for the Week of February 27 Steve Norman Department of Electrical & Computer Engineering University of Calgary February 27 Assignment instructions and other documents for ENCM 5 can be found at Administrative details Group work is permitted Please see the rules and advice given in the Assignment 3 instructions Due Dates The Due Date for this assignment is 3:3pm, Thursday, March 2 The Late Due Date is 3:3pm, Friday, March 3 The penalty for handing in an assignment after the Due Date but before the Late Due Date is 3 marks In other words, X/Y becomes (X 3)/Y if the assignment is late There will be no credit for assignments turned in after the Late Due Date; they will be returned unmarked How to package and hand in your assignments Please see the instructions in Assignment Marking scheme A B C total 4 marks 4 marks 5 marks 3 marks Exercise A: 2-dimensional arrays and caches Read This First Processing large multi-dimensional arrays is common in applications such as image and video processing, and scientific and engineering simulation These arrays are often much larger than processor cache capacities, so maximizing spatial locality of reference in memory accesses is often critical in optimizing program performance

2 ENCM 5 Winter 27 Assignment 6 page 2 of 8 Figure : Memory layout for the C array int x[4][3], assuming 32-bit ints and 32-bit memory words increasing addresses of 32-bit words address offsets x[3][2] x[3][] x[3][] x[2][2] x[2][] x[2][] x[][2] x[][] x[][] x[][2] x[][] x[][] In this exercise, we ll look at the relatively simple case of 2-dimensional arrays in C programs Figure shows the memory layout of an array declared as int x[4][3]; It s essentially an array of 4 arrays of 3 ints The elements within each array of 2 ints occupy a contiguous chunk of 2 bytes (assuming that ints are 32 bits wide), so the total size of the 2-d array is 48 bytes What to Do, Part I Suppose that the base address of the array (address of x[][]) in Figure is x9a8 Consider the following code, and assume that i, j and sum are in registers for (i = ; i < 4; i++) for (j = ; j < 3; j++) sum += x[i][j]; Write down the address used for all the data memory accesses as the code runs, in the order in which those accesses occur 2 Repeat the above, for this rearranged code: for (j = ; j < 3; j++) for (i = ; i < 4; i++) sum += x[i][j]; What to Do, Part II The order of element access for a tiny array like the one in Part I very likely does not have any impact on performance But for a much larger array, the impact can be dramatic

3 ENCM 5 Winter 27 Assignment 6 page 3 of 8 Copy the files big2darrayc from the ENCM 5 Assignments Web page You will also need the files query_perfc and query_perfh from Assignment 5 Have a look at the functions count_matches and count_matches2 They do exactly the same work, but do not access array elements in the same order To get more or less consistent results from all students, please use a machine in ICT32 with a Core i7 87 processor To find out what processor model is in a machine, run this command in a Cygwin terminal: head -5 /proc/cpuinfo It will give you the first 5 lines of a file describing the processor chip(s) installed the computer If do not see this: processor : vendor_id : GenuineIntel cpu family : 6 model : 3 model name : Intel(R) Core(TM) i7 CPU GHz log out and find another station (Most of the boxes have Core i7 87 processor chips, but a few have other chips, which may have different clock frequencies and chache capacities) Build an executable with the command gcc -g -O2 big2darrayc query_perfc -o progexe Use an approach similar to that used in previous assignments to find an average running time for the count_matches function Now edit big2darrayc so that main calls count_matches2 instead of count_matches Build another executable with gcc -g -O2 big2darrayc query_perfc -o prog2exe Run the new executable several times and calculate an average running time for count_matches2 Which is faster for the specific array dimensions used in this example: count_matches or count_matches2? Quantify your answer by stating the speedup factor by which one function is faster than the other What to Hand In For Part I, two lists of addresses Part II, measured running times, calculations of average running times, and a speedup factor calculation Remark The simplest thing you can do with a 2-d array is to access each of its elements once If you know how 2-d arrays are laid out in memory, it s pretty easy to do this simplest thing in a cache-efficient way Doing more complicated things, such as matrix multiplication, is harder See textbook pages 89 9 for a brief introduction to cache-aware matrix multiplication Exercise B: Cache and TLB miss counts walking though a -d array Read This First Simple code like this:

4 ENCM 5 Winter 27 Assignment 6 page 4 of 8 double sum(const double *a, int n) { double result = ; int i; for (i = ; i < n; i++) result += a[i]; return result; } will result in quite complicated activity within a computer memory system, if n is large What to Do, Part I Consider the system of Figure 2 Assume the following about the caches: block size in all three caches is 64 bytes; L cache capacities are 32 KB each; L2 cache capacity is 52 KB; it s possible for some instructions or data to be in an L cache but not in the L2 cache Assume the following about virtual memory: page size is 4 KB; each TLB holds 96 VPN-to-PPN translations Suppose the for loop in Read This First is about to start, that n is 5,, and that all of a[] a[499999] are somewhere in DRAM Suppose that the virtual address of a[] is x6fe8 The worst-case scenario is that none of the array elements are cached, and none of the VPN-to-PPN translations for the array are in the D-TLB In this scenario, how many L cache misses will there be as the loop runs to completion? How many L2 cache misses? How many misses in the D-TLB? Show how you obtained your answers, and clearly state any assumptions you had to make Figure 2: Memory system organization for a single-core processor in the era of the Pentium III and Pentium 4 CORE I-TLB D-TLB L I- CACHE L D- CACHE UNIFIED L2 CACHE DRAM CONTROLLER DRAM MODULES

5 ENCM 5 Winter 27 Assignment 6 page 5 of 8 What to Do, Part II Repeat Part I for the best-case scenario: the caches and D-TLB start with exactly the right information to mimimize cache and TLB misses as the loop runs What to Hand In Detailed calculations for Parts I and II Exercise C: x86-64 page tables Read This First As will be mentioned in the lecture Tuesday February 28, 48-bit virtual addresses in x86-64 systems are used to search a four-level tree-like page table, with virtual page numbers split into four 9-bit chunks: 36-bit virtual page number VPN VPN 2 VPN 3 VPN 4 page offset Consider a tiny Linux-ish process that uses only three pages of virtual memory: VPN x4 x4 x7fffffffe Use instructions and read-only data readable/writeable static data stack These VPNs split as follows for page table access: VPN VPN VPN2 VPN3 VPN4 x4 2 x4 2 x7fffffffe Those VPN splits result in the page table structure shown in Figure 3 It s not terribly space-efficient seven pages are needed for a page table supporting only three pages used by the process but it s much, much better than a simple array with indexes to x7ffffffff! What to Do Determine the memory footprint memory used for virtual pages plus memory used for a page table for a x86-64 Linux process with the fake but realistic use of virtual memory listed in Figure 4 To keep things relatively simple, count all of the pages related to shared libraries, despite the fact that that part of the footprint is probably shared with other processes Hints: Adding up the number of virtual pages is simple arithmetic You can use the program vpn-splitc to quickly split VPNs into 9-bit chunks To count directories, start by finding out how many page upper directories are needed For each page upper directory, find out how many page middle directories are needed Then for each page middle directory, find out how many last-level page tables are needed I m not sure if it s possible to create a process this tiny on a real 64-bit Linux system

6 ENCM 5 Winter 27 Assignment 6 page 6 of 8 Figure 3: x86-64 page table organization for a process with only three pages The character represents a null pointer in the directories, and indicates no such page in the last-level page tables Each cell in a directory and each PTE is 64 bits wide, so the total memory footprint of the page table is 7 52 cells 8 bytes/cell = 7 4 KB page global directory page upper directories 5 page middle directories last-level page tables useful PTE useful PTE useful PTE Figure 4: Fake but fairly realistic information about how an x86-64 Linux process might use virtual memory VPN range x4 to x43 x6 to x62 x63 to x9d3 x34e8 to x34ef52 x7fff35c5 to x7fff35c7 Use instructions and read-only data readable/writeable static data heap shared-library instructions and data stack

7 ENCM 5 Winter 27 Assignment 6 page 7 of 8 What to Hand In Hand in your calculations and results Describe your calculations with enough clarity and detail that a reader could understand exactly what your method was Remark The fake data for this exercise was generated by looking at the virtual memory layout of a real 64-bit Linux process, then simplifying it to make solving the exercise quite a bit less tedious See Figure 5 for more information, if you re curious

8 ENCM 5 Winter 27 Assignment 6 page 8 of 8 Figure 5: Demonstration of finding the virtual memory layout of a Linux process I suspended a process, used ps to find its process ID, then used one of the facilities in the Linux /proc system This is real output, edited very slightly so that it wouldn t be too wide to fit legibly on letter-size paper --- remote:~/5/assign5 --> /aout sum of junk is ^Z []+ Stopped /aout --- remote:~/5/assign5 --> ps PID TTY TIME CMD 255 pts/ :: bash 2587 pts/ :: aout 2588 pts/ :: ps --- remote:~/5/assign5 --> cat /proc/2587/maps 4-4 r-xp :f /nfs/engfs/[]/aout 6-6 rw-p :f /nfs/engfs/[]/aout 6-4a2 rw-p : [heap] 34e8-34e8c r-xp 8: /lib64/ld-25so 34eac-34ead r--p c 8: /lib64/ld-25so 34ead-34eae rw-p d 8: /lib64/ld-25so 34ec-34ed4f r-xp 8: /lib64/libc-25so 34ed4f-34ef4e ---p 4f 8: /lib64/libc-25so 34ef4e-34ef52 r--p 4e 8: /lib64/libc-25so 34ef52-34ef53 rw-p 52 8: /lib64/libc-25so 34ef53-34ef58 rw-p : 34f8-34f86 r-xp 8: /lib64/libpthread-25so 34f86-34fa6 ---p 6 8: /lib64/libpthread-25so 34fa6-34fa7 r--p 6 8: /lib64/libpthread-25so 34fa7-34fa8 rw-p 7 8: /lib64/libpthread-25so 34fa8-34fac rw-p : r-xp 8: /lib64/librt-25so p 7 8: /lib64/librt-25so r--p 7 8: /lib64/librt-25so rw-p 8 8: /lib64/librt-25so 7f446666d-7f446666f rw-p : 7f446668a-7f446668d rw-p : 7fff94c3d-7fff94c5e rw-p : [stack] 7fff94da7-7fff94da8 r-xp : [vdso] ffffffffff6-ffffffffff6 r-xp : [vsyscall]