Are there CPUs that perform this possible L1 cache write optimization?

Question

When the CPU with an L1 cache does a write, what normally happens is that (assuming that the cache line that it is writing to is already in the L1 cache) the cache (in addition to updating the data) marks that cache line as dirty, and will write the line out with the updated data at some later time.

One possible optimization would be to have the cache compare the contents of the write and the previous contents of the cache, and if they're the same, don't mark the line as dirty. Because this might allow the cache to avoid write-backs on occasion, I can see how the CPU manufacturer might see this as worth the gates needed to do this logic.

My question: are there CPUs that perform this optimization?

Background as to why I'm asking: I'm writing some code that needs to have constant memory accesses; that is, someone who is able to listen into the behavior of the cache should not be able to deduce what I'm doing. Some of my accesses are writes, and in the obvious way to implement this code, a lot of the writes will be writing the same data that's already there. I need to do the writes because, depending on the data, the data I'm writing may or may not be the same, and it's important to perform the same action regardless. If the CPU optimizes by not actually writing a 'no-change-write', that would mean that the behavior of the cache would vary depending on what I'm doing, which would subvert my goal.

So, is there a CPU that tries to optimize writes in this way?

Answer 1

From hours of searching, I wasn't able to find a CPU that uses this specific optimization. Most of the optimizations mentioned usually related to hit/miss with read/write operations and data access:

(pages 7 and ) https://cseweb.ucsd.edu/classes/fa14/cse240A-a/pdf/08/CSE240A-MBT-L15-Cache.ppt.pdf

However, that doesn't mean that this optimization can't be performed. In general, it is possible to programmatically access the size of a CPU cache line. It is also possible to access current values in cache registers - but it's somewhat dangerous to do so. If you access the wrong registers at a bad time, you could be tampering with ones related to a running program. Or you could inadvertently modify the contents of the lines you're trying to read.

Obtaining current value in register's cache

Furthermore, all of the theoretical solutions require some form of software implementation (assembler). The closest I've found relates to the ARM architecture, which appears to allow for cache manipulation. In addition to this, you would also need to know the size of a cache line for your desired CPU. You could carefully read the cache contents to a secondary location in memory, in line-sized increments, and compare it to data that is about to be written to the registers (or L1 cache lines, in this case).

Read CPU cache contents

From there, you could devise a software-based system that prevents identical rewrites. While this is a bit simplified, it is so because the solution has to be applicable for any CPU that exists.

Another possibility that I found related to Cache coherence:

Relevant passage from a Wikipedia article about acche coherence

The main point that caught my attention, in relation to this issue, was the Snarfing description:

It is a mechanism where a cache controller watches both address and data in an attempt to update its own copy of a memory location when a second master modifies a location in main memory. When a write operation is observed to a location that a cache has a copy of, the cache controller updates its own copy of the snarfed memory location with the new data.

In other words, there are possibly mechanisms already in place. It's just that they might not be used for the optimization you have suggested. You would have to implement software that performed the read/write comparison.

Answer 2

Writing to L1 cache is a very, very time critical operation.

Writing the exact same data back seems to be rather rare. An optimisation that speeds things up in this particular case isn't going to get a lot of speedup in total.

On the other hand, this optimisation requires a comparison of old data and new data on every single write to cache memory. What makes this worse, is that it requires that the data to be written has to be actually available at the time of the write!

That is usually not the case on a modern CPU. The data to be written may still be being calculated for example. The cache can still go ahead, load the cache line if needed, mark the cache line as modified and so on, even before the calculation is finished. All the book keeping can already be performed except for the actual modification of the cache line. If you want to compare newly written result and old cache line data, that isn't possible.

As an example, if you have C code a [i] = x / y; the division x / y takes an extraordinary long time to perform on most CPUs. However, most of the work needed to handle storing the result to a [i] has happened long before the division finishes; the only thing missing is the move of eight result bytes to the cache line. An operation flushing the cache line will automatically wait until the division is finished. An operation reading a [i] will likely be redirected to get the result straight from the divider.

Answer 3

One possible optimization would be to have the cache compare the contents of the write and the previous contents of the cache, and if they're the same, don't mark the line as dirty

Won't such optimization double the time CPU needs to write something into cache? Because each cache line write will now be accompanied with a compare operation, which is not free.

So, actually the optimization now will depend on the very vague factor: how many times an average software rewrites its cacheable memory with the same data.

Answer 4

Note: A more comprehensive version of this answer is on StackOverflow and I recommend you read that one for the most up-to-date information.

I found evidence that some modern x86 CPUs from Intel, including Skylake and Ice Lake client chips, can make this optimization, but at the L2 <-> L3 boundary, not at the L1¹, in at least one specific case:

An all zero cache line is written to with additional zeroes, so that it remains fully zero.

That is, a "zeros over zeros" scenario.

For example, this plot shows the performance (the circles, measured on the left axis) and relevant performance counters for a scenario where a region of varying size is filed with 32-bit values of either zero or one, on Skylake client:

Filling with zeroes both performs better and shows about half of the write bandwidth to DRAM. On Ice Lake, the optimzation takes effect more often and the write bandwidth drops close to zero.

You can find more detail on the above-mentioned StackOverflow answer, and in this blog post where I cover it in more detail. There is an addendum for Ice Lake, which as mentioned exhibits this effect more strongly here.

---

¹ Of course, it is possible that the "is all zero" state is detected at the L1 and propagated outwards for ultimate use at the L2 <-> L3 boundary.