Question: describe a programming scenario that would create this pattern of values in memory.
dumbo_
A linked list, each node has 1 address and 2 int values.
Kapteyn
It seems like the cache could benefit from having information on the data type being stored in the cache line. For example, if the cache line held an array of chars and not ints, then we should expect to see a pattern on the granularity of 8 bits, not 32, so trying to compress the cache line by looking for patterns over 32 bit chunks would be efficient than looking for patterns over 8 bit chunks.
However, the added complexity/system overhead of obtaining this information might be a preventative factor. Do most compressors just assume patterns exist at some fixed number of bits of granularity?
sanchuah
It is vary similar to the decoding homework in 213, a linked list. The first 4 bytes is a integer of node value, the second 4 bytes is the pointer to the next node.
msebek
It seems like hardware support for detecting common patterns in the data would be similar to the fancy branch predictor conundrum; if this could be done, how much hardware would it take to make it happen? Do the performance gains justify adding this hardware/not performing another optimization?
Faust
@dumbo_, I agree that it is a linked list struct with an address and an int. I'm a bit confused about how you got 2 int values though. Could anyone explain?
plymouth
@Faust Each blocked off section is 4 bytes (one word). Following a 0x09A4xxxx word (which could be an address), there are two words that could be ints, and then another 0x09A4xxxx word.
Question: describe a programming scenario that would create this pattern of values in memory.
A linked list, each node has 1 address and 2 int values.
It seems like the cache could benefit from having information on the data type being stored in the cache line. For example, if the cache line held an array of chars and not ints, then we should expect to see a pattern on the granularity of 8 bits, not 32, so trying to compress the cache line by looking for patterns over 32 bit chunks would be efficient than looking for patterns over 8 bit chunks.
However, the added complexity/system overhead of obtaining this information might be a preventative factor. Do most compressors just assume patterns exist at some fixed number of bits of granularity?
It is vary similar to the decoding homework in 213, a linked list. The first 4 bytes is a integer of node value, the second 4 bytes is the pointer to the next node.
It seems like hardware support for detecting common patterns in the data would be similar to the fancy branch predictor conundrum; if this could be done, how much hardware would it take to make it happen? Do the performance gains justify adding this hardware/not performing another optimization?
@dumbo_, I agree that it is a linked list struct with an address and an int. I'm a bit confused about how you got 2 int values though. Could anyone explain?
@Faust Each blocked off section is 4 bytes (one word). Following a 0x09A4xxxx word (which could be an address), there are two words that could be ints, and then another 0x09A4xxxx word.