Computer Architecture Assignment 4 - Cache Simulator

Transcription

1 Computer Architecture Assignment 4 - Cache Simulator Instructor : Abhishek Bhattacharjee Due : April 15, 11:55 PM 1 Overview The goal of this assignment is to help you understand caches better. You are required to write a cache simulator using the C programming language. The programs have to run on ilab machines. We are providing real program memory traces as input to your cache simulator. The format and structure of the memory traces are described below. 2 Memory Access Traces The input to the cache simulator is a memory access trace, which we have generated by executing real programs. The trace contains memory addresses accessed during program execution. Your cache simulator will have to use these addresses to determine if the access is a hit or a miss, and the actions to perform in each case. The memory trace file consists of multiple lines. Each line of the trace file corresponds to a memory accesses performed by the program. Each line consists of multiple columns, which are space separated. The first column reports the PC (program counter) when this particular memory access occurred, followed by a colon(:). Second column lists whether the memory access is a read (R) or a write (W) operation. And the last column reports the actual 48-bit memory address that has been accessed by the program. In this assignment, you only need to consider the second and the third columns (i.e. you dont really need to know the PCs). The last line of the trace file will be the string #eof. We have provided you three input traces file (some of them are larger in size). Your submission will be evaluated with the same traces files. Here is a sample trace file: 0x804ae19: R 0x9cb3d40 0x804ae19: W 0x9cb3d40 0x804ae1c: R 0x9cb3d44 0x804ae1c: W 0x9cb3d44 0x804ae10: R 0xbf8ef498 #eof

2 3 Cache Simulator You will implement a cache simulator to evaluate different configurations of caches. It should be able to run with different traces files. The followings are the requirements for your cache simulator: Simulate only one level cache; i.e., an L1 cache. The cache size, associativity, the replacement policy, and the block size are input parameters. Cache size and block size are specified in bytes. You have to implement three cache replacement policies. (1) First In Fist Out (FIFO); (2) Least Recently Used (LRU); and (3) Not Recently Used (NRU). For more details on each of these policies, please refer to Section 5. You have to simulate a write through cache. 4 Cache Simulator Interface You have to name your cache simulator first. Your program should support the following usage interface:./first <cache size><associativity><cache policy><block size><trace file> where: A) <cache size>is the total size of the cache in bytes. This number should be a power of 2. B) <associativity>is one of: direct - simulate a direct mapped cache. assoc - simulate a fully associative cache. assoc:n - simulate an n way associative cache. n will be a power of 2. C) <cache policy>three valid policies for this project are fifo, lru and nru. D) <block size>is a power of 2 integer that specifies the size of the cache block in bytes. E) <trace file>is the name of the trace file. About Improper Format You can assume the input trace files that we test your program follow the format specified in the description. However, your program should be able to catch any improper input argument passed to your program. For instance, your program should report wrong number of inputs, invalid entries (e.g. the cache policy doesn t match any of the three policies), or the cache size or block size is not power of 2.

3 5 Cache Replacement Policy The goal of the cache replacement policy is to decide which block has to be evicted in case there is no space in the set for an incoming cache block. It is always preferable to achieve the best performance to replace the block that will be re-referenced furthest in the future. There are different ways one can implement cache replacement policy. Here we study three policies that are simpler to implement. For more details, please refer to: replacement policies for more information. 5.1 FIFO Using this algorithm, you can always evict the block accessed first in the set without any regard to how often or how many times it was accessed before. So let us say that your cache is empty initially and that each set has two ways. Now suppose that you access blocks A, B, A, C. To make room for C, you would evict A since it was the first block to be brought into the set. 5.2 LRU This algorithm requires keeping track of what was used when per block. General implementations of this technique require keeping age bits for cache-lines and track the Least Recently Used cache-line based on age-bits. Taking the same example as before, you would now need to evict block B to make room for C. You may implement LRU by essentially maintaining a linked list of ways for each set. When a cache block is accessed, it is placed at the head of the linked list. Two scenarios are possible. In the first scenario you have a cache hit (i.e., the line you request is in the cache set). While you do not need to evict a cache block at this point, you do you need to maintain an ordered linked list of cache blocks based on which ones were accessed from the most recent to least recent position. This means that the cache block that experienced a hit needs to be brought to the head of the linked list. In the second scenario, you suffer a cache miss. In this case, you need to bring in the cache block from memory and add it to the head of the linked list. Moreover, you need to evict a cache block you do this by evicting the cache block at the end of the linked list. 5.3 NRU In practice, LRU is difficult to implement using a small number of bits. This is because you are essentially maintaining a linked list and it is not area-effective to add links to each cache line. Therefore, most modern processors approximate LRU using an approach known as Not Recently Used (NRU). NRU uses a single bit per cache block called the nru-bit. An nru-bit value of 0 implies that a block was recently used and the block is predicted to be re-referenced in the near immediate future. An nru-bit value of 1 however, implies that the

4 block was not recently used and the block is predicted to be re-referenced in the distant future. For all cache fills (new cache blocks) block, NRU always predicts that the missing block will have a near-immediate re-reference (i.e., nru-bit set to 0). Upon a cache hit, NRU again anticipates that the block referenced will have a near immediate re-reference (set to 0). On a cache miss, NRU selects the victim cache block whose predicted re-reference is in the distant future (i.e., a block whose nru-bit is 1). But multiple blocks in the referenced set may have a distant re-reference prediction, so we need to break ties. To break ties, the NRU victim selection policy always starts the victim search from the first block of the set, until it finds a cache block whose nru-bit is 1. The first such cache block with an nru-bit of 1 gets evicted. In the event that all nru-bits are 0 (i.e., all blocks in the set are predicted to be re-referenced in the near-immediate future), NRU updates the re-reference predictions of all cache blocks in that set to be in the distant future (i.e., NRU sets all the bits to 1) and then repeats the victim search as described above. 6 Sample Run Your program should print out the number of memory reads (per cache block), memory writes (per cache block), cache hits, and cache misses. You should exactly follow the same format as shown below. (the result values shown below are not correct!) $./first 32 assoc:2 fifo 4 trace1.txt Memory reads: 1234 Memory writes: 5678 Cache hits: 9012 Cache misses: 3456 $./first 64 assoc nru 16 trace1.txt Memory reads: 1234 Memory writes: 5678 Cache hits: 9012 Cache misses: 3456 $./first 64 direct lru 8 trace1.txt Memory reads: 1234 Memory writes: 5678 Cache hits: 9012 Cache misses: 3456

5 7 Some Important Details 1. (a) When your program starts, there is nothing in the cache. So, all cache lines are empty (invalid). (b) you can assume that the memory size is Therefore, memory addresses are 48 bit. (c) the number of bits in the tag, cache address, and byte address are determined by the cache size and the block size; (d) Your simulator should simulate the operation of a cache according to the given parameters for the given trace 2. For a write-through cache, there is the question of what should happen in case of a write miss. In this assignment, we assume we have a write-allocate cache which means the block loaded from the memory to the cache (i.e., one read memory), and followed by a memory write (one memory write). 3- You do not need to simulate the memory in this assignment. Because, the traces doesnt contain any information on data values transferred between the memory and the caches. 4. You have to use -Wall and -Werror flags in your makefile. 8 Submission You have to e-submit the assignment using Sakai. Put all files (source code + header file + Makefile ) into a directory named pa4. Then, create a tar file (follow the instructions in the previous assignments to create the tar file). Your submission should be only a tar file named pa4.tar. You have to e-submit the assignment using Sakai. Your submission should be a tar file named pa4.tar. To create this file, put everything that you are submitting into a directory named pa4. Then, cd into the directory containing pa4 (that is, pa4s parent directory) and run the following command: $tar cvf pa4.tar pa4 To check that you have correctly created the tar file, you should copy it (pa4.tar) into an empty directory and run the following command: $tar xvf pa4.tar This should create a directory named pa4 in the (previously) empty directory. Your pa4 folder should contain the following: source code: all source code files necessary for building your programs. Your code should contain at least two files: first.c and first.h. Makefile: There should be at least two rules in your Makefile: first: build the executables (first). clean: prepare for rebuilding from scratch.

6 9 Grading Policy 1. We should be able build your program by just running make. 2. Your program should follow the format specified above for the usage interface. 3. Your program should strictly follow the input and output specifications mentioned above. (Note: This is perhaps the most important guideline: failing to follow it might result in you losing all or most of your points for this assignment. Make sure your programs output format is exactly as specified.