Write-through cache does not require a dirty bit because the memory is always updated as soon as a write happens.
cwchang
Here are some points discussed in the class:
Tag helps us verify whether this line is the one we are looking for
Int takes four bytes (so four "blocks" are highlighted)
The byte ordering in this slide is little endian
Dirty bit indicates whether or not we need to write data back to memory (in write-back cache)
Dirty bit is not necessary for write-through cache
planteurJMTLG
Write allocate: if there is a cache miss when writing, load the data from memory to the cache, then write in the cache
Write-no-allocate: if there is a cache miss when writing, write directly to memory, don't update the cache
jocelynh
A few more points to add onto what cwchang said:
Each cache line contains 64 (= 2^6) bytes of memory, so there are 6 bits for the index bits.
Since x is located at 0x12345604, the index bits would be 000100 = 4. The four "blocks" that are highlighted are the ones of index 4-7 (the four bytes of the int) in the cache line.
apk
Important detail about write-back: it defers write to memory until replacement of line.
Clarification on jocelynh's comment: 000100 = 4 determined the offset to which we wrote the value 1 in little endian.
RomanArena
recall from 213:
Write-through:write immediately to memory
Write-back:defer write to memory until replacement of line
Write-allocate: load into cache, update line in cache
No-write-allocate: writes straight to memory, does not load into cache
rsvaidya
What other information is generally stored in the "line state" of the cache other than the dirty bit?
khans
Wouldn't a no-write-allocate cache have poor temporal locality?
shpeefps
@rsvaidya We could also store things like when was the memory from that cache line last read etc. so that we would know where to overwrite the cache when it gets full. I'm sure there is also other metadata that could be useful to improve locality in the cache.
M12
@khans In response to: "Wouldn't a no-write-allocate cache have poor temporal locality?"
Why do you think it specifically hinders temporal locality? I agree that it would in general reduce cache performance in a way. No-write-allocate caches just cache reads.
An example that may demonstrate why I do not think no-write-allocate caches have poor temporal locality: Say we write to a location X not in the cache, this value gets placed in main memory (without being put into the cache). Then we read from this location X (a miss because we didn't cache the write). Then we read/write from this location again, and again, and again..., within a short duration, so that we hit the cache each time. So we only had one extra miss and also had high temporal locality.
jedi
Would it be fair to say that write-back caches are more likely to be write-allocate as well (since they work better if there are subsequent writes), whereas write-through caches are more likely to also be no-write-allocate (since each write must hit memory)?
apr
@jedi, I agree with your point about which write-miss policy would be better for each of the write policies. To expand a bit more, to be clear, since in write-back, writes to that cache line update the cache block (along with setting the dirty bit) and it is written to main memory only upon replacement, allowing a cache miss (during a write) to load the data into the cache (write-allocate) will be better for reducing latency of subsequent writes to that cache line. This is because only if the data has been brought into the cache, can further writes cause that cache line to become dirty instead of the writes being made to memory directly which would be the case when it comes to write-back.
On the other hand, with a write-back policy, there is advantage for future writes, in using up a cache line when there is a write miss since future writes will have to write to memory anyway (write-back.)
fxffx
(1) Write back: write to cache, and only flush to memory when evicted. Write through: write directly to memory
(2) Write allocate: when writes, get the corresponding line from memory to cache, then writes to cache line. Write-no-allocate: write directly to memory.
Write-through cache does not require a dirty bit because the memory is always updated as soon as a write happens.
Here are some points discussed in the class:
Tag helps us verify whether this line is the one we are looking for
Int takes four bytes (so four "blocks" are highlighted)
The byte ordering in this slide is little endian
Dirty bit indicates whether or not we need to write data back to memory (in write-back cache)
Dirty bit is not necessary for write-through cache
A few more points to add onto what cwchang said:
Important detail about write-back: it defers write to memory until replacement of line. Clarification on jocelynh's comment: 000100 = 4 determined the offset to which we wrote the value 1 in little endian.
recall from 213:
Write-back:defer write to memory until replacement of line
Write-allocate: load into cache, update line in cache
What other information is generally stored in the "line state" of the cache other than the dirty bit?
Wouldn't a no-write-allocate cache have poor temporal locality?
@rsvaidya We could also store things like when was the memory from that cache line last read etc. so that we would know where to overwrite the cache when it gets full. I'm sure there is also other metadata that could be useful to improve locality in the cache.
@khans In response to: "Wouldn't a no-write-allocate cache have poor temporal locality?"
Why do you think it specifically hinders temporal locality? I agree that it would in general reduce cache performance in a way. No-write-allocate caches just cache reads.
An example that may demonstrate why I do not think no-write-allocate caches have poor temporal locality: Say we write to a location X not in the cache, this value gets placed in main memory (without being put into the cache). Then we read from this location X (a miss because we didn't cache the write). Then we read/write from this location again, and again, and again..., within a short duration, so that we hit the cache each time. So we only had one extra miss and also had high temporal locality.
Would it be fair to say that write-back caches are more likely to be write-allocate as well (since they work better if there are subsequent writes), whereas write-through caches are more likely to also be no-write-allocate (since each write must hit memory)?
@jedi, I agree with your point about which write-miss policy would be better for each of the write policies. To expand a bit more, to be clear, since in write-back, writes to that cache line update the cache block (along with setting the dirty bit) and it is written to main memory only upon replacement, allowing a cache miss (during a write) to load the data into the cache (write-allocate) will be better for reducing latency of subsequent writes to that cache line. This is because only if the data has been brought into the cache, can further writes cause that cache line to become dirty instead of the writes being made to memory directly which would be the case when it comes to write-back.
On the other hand, with a write-back policy, there is advantage for future writes, in using up a cache line when there is a write miss since future writes will have to write to memory anyway (write-back.)
(1) Write back: write to cache, and only flush to memory when evicted. Write through: write directly to memory (2) Write allocate: when writes, get the corresponding line from memory to cache, then writes to cache line. Write-no-allocate: write directly to memory.