CODEWITHSUNDEEP
c++cachingprofiling
Jiew Meng
Jiew Meng

Reputation: 88207

Determine if cache is write back or through

How do I determine by testing writes to cache the type of cache (write back/through)? I could use a similar method as I did to determine the levels and size of cache by recording the time to modify cache, but I will need to compare with something. eg. if the time is significantly shorter that a known L1 write through cache, I can say its write back. However, I will need a base line to compare with won't I?

Heres my attempt at GitHub

The main idea is:

So the time the loop for WRITES_BASE times vs time for WRITES times minus of their respective times to execute loops only (no memory access), and compare them ... this gives me the impression that my Core i3 2100 has all write through caches ... 

16, 0.03, 1.04 (31.28) 
128, 0.07, 2.31 (31.78) 
2048, 0.10, 3.19 (31.74)

The above values are: test size (KB), time for WRITES_BASE, time for WRITES (t(WRITES)/t(WRITES_BASE))

I am guessing the problem with my experiment is I haven't eliminated the time difference that I am running WRITES more times...

UPDATE

An oddity I noticed is if I keep my WRITES = 64 * WRITES_BASE, then if I have my WRITES_BASE = 4 million. 

16, 0.01, 0.13 (17.16) 
128, 0.01, 0.29 (31.60) 
2048, 0.01, 0.41 (30.53)

If I increase WRITES_BASE = 16 million

16, 0.02, 0.52 (25.53) 
128, 0.04, 1.16 (31.74) 
2048, 0.05, 1.57 (31.89)

Notice, when WRITES_BASE is smaller, the difference between the times are less, perhaps telling me L1 is a write back cache. However, since its not always true, eg. when I increase WRITES_BASE, I wonder if I am having some logic error?

Upvotes: 3

Views: 2447

Answers (1)

bdonlan
bdonlan

Reputation: 231193

You can't really distinguish between a writeback cache and a write-through cache with this procedure. Consider: If you're using a writeback cache, it takes X time to execute the instructions in the loop, and Y time to write it back. Y is not measured by your code (you don't have any timing around an explicit cache flush or similar). When you loop N times, it takes N * X time, plus Y after your code is done executing to flush the cache.

With a write-through cache, X is higher, and Y is zero. But the ratio of the single loop to many loops is the same. Thus, you can't tell the difference with this procedure.

That said, there are ways you can detect this. The key is to force the cache to flush its cache lines while you're timing. Try comparing how long it takes to write various sizes of arrays. Between writes ensure that any writeback cache is flushed by reading a lot of unrelated data (note: don't just allocate a large array and read from it without writing to it ever - write to it once at program startup, then read the whole thing between timing runs. Otherwise all the pages in the array might point to the same zeroed-out page in physical memory, depending on your OS).

You could also try seeing when writing lots of data influences the speeds of reads. In a write-through cache, reads should never take longer just because you wrote data recently. In a write-back cache, reads may have to wait for cache flushes - so timing reads on their own vs immediately after writes may give you some interesting results as well.

Upvotes: 2

Related Questions