get_cache_size

166 views
Skip to first unread message

Trevor Bonas

unread,
Nov 8, 2020, 3:17:20 AM11/8/20
to cmpt-295-sfu
SFU ID: tbo...@sfu.ca
Github username: trevorbonas
Github Link: g...@github.com:CMPT-295-SFU/assignment-4-trevorbonas.git
Line and file: Lines 41-91, cache-test-skel.c
Expected behavior: Prints "65536 bytes" per cache_65536c_2e_16k.o test
Observed behavior: Prints "65536 bytes"
Question: I can get get_cache_size to work but only by doing two loops longer than I would imagine any cache could be. I had another idea I thought would work, which I left commented in there, but it seems access_cache "remembers" an address if I repeatedly access it and refuses to eject that address.

Much help would be appreciated in pointing me in the direction of getting either of my solutions to work without having to do two massive loops.

Trevor Bonas

unread,
Nov 8, 2020, 8:15:10 PM11/8/20
to cmpt-295-sfu
I figured out a way to get my initial method to work, and pushed the changes to my above repo, for both get_cache_size and get_cache_assoc, and to get around access_cache "remembering" the the certain address and refusing to ever eject it, but it requires accessing addresses, flushing, re-adding those addresses I just flushed, over and over, making the performance something like O(n!), which means the cache_1048576c_256e_256k.o test takes way way too long. Is there anyway to get access_cache to not "hold onto" a single address I'm accessing repeatedly? If so, that would make everything run super well.

b.minh96

unread,
Nov 9, 2020, 3:01:05 PM11/9/20
to cmpt-295-sfu
That's the purpose of the cache, which is to keep what you're accessing repeatedly for fast access.
Looking at your code, it seems that you're not utilizing the information of block size. Correct usage of that could improve the run time of your program.
You only need to flush once at the beginning. Once you have a data in cache, you can figure out the size by just keep adding more data to cache (by accessing/reading more vaues) until the very first value is removed.

Trevor Bonas

unread,
Nov 9, 2020, 3:23:34 PM11/9/20
to cmpt-295-sfu
I'll try to incorporate block size and see what happens.

The idea I started with was adding data to the cache, then adding more data, until the very first value is removed, with the idea that when the cache is full and I add new data the first block is replaced. However I was doing this in a while loop and checking if I am still hitting the very first data right after adding more data, and it always hit, even when accessing 700,000 bytes of data. But if in a loop I accessed 70,000 bytes of data (just more than the cache_65536c_2e_16k.o test) then tried to access the starting data it would miss, which means the idea is correct.

From my understanding what it should be doing is every time I access the starting address after adding new data it should look in the first block and see that the data is there and return a hit, and continue to do so until the cache is full and I add more data, which then would replace the first block, making accessing the start address miss, but it doesn't do this, it almost seems to "reserve" that first block no matter how much more data I add.

Trevor Bonas

unread,
Nov 9, 2020, 4:31:08 PM11/9/20
to cmpt-295-sfu

Just incorporated block size and now it's really fast. Though above mentioned issue with access_cache refusing to replace the first block still persists.
Reply all
Reply to author
Forward
0 new messages