Lab 11 Assignment F23

.pdf

School

University of Michigan *

*We aren’t endorsed by this school

Course

370

Subject

Computer Science

Date

Dec 6, 2023

Type

pdf

Pages

Uploaded by PresidentScienceKomodoDragon18

Introduction to Computer Organization – Fall 2023 Lab 11 Due: @11:55 PM, Wednesday November 29th The following assignment is intended to be completed during your assigned lab period. One member of your group must submit the assignment to Gradescope by the posted deadline and indicate your group members when submitting the assignment. Each group member must be present during the scheduled lab period in order to receive credit. Group names and uniqnames Pod Member Name Uniqname Alexandra Lavacek alavacek Landon Butcher landonbu Albon Wu albonwu Hongjue Cheng hongjuec For each of the following problems, one person should act as the "scribe" and log the discussions of the group. You should rotate who is the scribe for each problem and indicate in the given space.

Problem 1: Structs in Caches [20 points] Scribe: [Scribe's name here] Consider a byte-addressable architecture with the following data cache: Cache size: 64 bytes Block size: 16 bytes struct example{ char a; //1 byte float b; //4 bytes short c; //2 bytes unsigned int d; //4 bytes char e; //1 byte int f; //4 bytes }; //24 bytes 1. How many example structs fit into our cache (assume the default data types sizes we usually use)? 2 struct example{ float b; //4 bytes unsigned int d; //4 bytes int f; //4 bytes short c; //2 bytes char a; //1 byte char e; //1 byte } // 16 bytes 2. Realign the struct to have minimum padding and size: 3. If we realign the struct to the optimal size, how many can fit now? 4

Problem 2: Investigating CAEN [20 points] Scribe: [Scribe's name here] Let's see if we can reverse-engineer the size of caches used on CAEN computers. What we'll do is have a piece of code that iterates through arrays of these structs to do a fixed amount of work. If we increase the amount of data in the array, but do the same amount of work, we should observe that the overall execution time does not change significantly, as long as the data can be kept in the level of cache closest to the processor (the so-called "L1 cache"). Once we increase the size of the array beyond what can fit in the cache, we should see a performance degradation. By figuring out what size this occurs at, we can make a first-order approximation of the cache size. Note: this will be a very rough estimate. Many other processor features are designed to hide the latencies of cache misses and make it harder to see when this transition occurs. Also, since processors include multiple levels of caches, each one slightly larger and slower than the previous, this performance degradation will be more gradual than if we were going to main memory all the time. For this problem, SSH into "login-course.engin.umich.edu" and transfer over the provided lab11.c file. 1. First, we need to ensure what the sizes of our data types are, since they can vary from system to system. How can we easily do this in a C program? Do any of the data types differ from our assumptions? We could use the C sizeof function with the different data types as arguments, and print the results. 2. Compile the provided program (make sure to NOT specify any optimizations) and run it with several array sizes (passed in as arg1 in the program) that you think will help identify the size of the L1 cache. Target to narrow it down to a factor of 100. Note that running a program using the "time" utility on Linux will report how long the execution took (e.g. "time ./lab10 [argument]". Using either the real time or user time should be fine for this.

Your preview ends here

Eager to read complete document? Join bartleby learn and gain access to the full version