I know why DRAM is slower to write than to read, but why is the L1 & L2 cache RAM slower to write?

Question

DRAM is slower to write than read because it takes time to either charge or discharge a DRAM memory cell. But what about the SRAM in my processor's L1 and L2 caches? It's slower to write as well but AFAIK, SRAM is latched memory based on gates.

So why the slower SRAM writing speed?

Thanks.

Answer 1

Are you really sure the caches are slower to write than to read? I suspect what you heard was the overall operation, not just the SRAM read or write time. Writing to a cache is a more expensive operation because eventually the slower memory backing the cache must be written to. It also means a cache block can't simply be reused without flushing it first if it's been written to and that write hasn't been propagated back to the main memory.

The actual write operation is probably the same speed, but the overall process of writing, and all the stuff that ultimately puts in motion, is longer.

Answer 2

The web page for this Bandwidth program which you apparently base your observation on, that you don't mention in your original question, answers your question in the Commentary section, under the Computers heading, observation 6.

If the L2 cache is in write-through mode then L2 writing will be very slow and more on par with main memory write speeds.

So, normally L2 cache is quicker, but in the case of the L2 cache being in write-through (alternative explanation from Oracle) mode, the purely write is not faster, but if that same memory is then accessed, it is quickly retrieved as it has already been cached.

If you had checked the graphs, and tables given, you would of seen that normally most computers behave as you would expect, the closer the memory is to the CPU, the faster it is (with CPU registers being the fastest).

Answer 3

In a cache memory system, the time required to physically read or write data from the cache RAM represents only part of the time required to perform a cache read or write access. Especially in a multi-processor system, it's also necessary to determine what the cache is supposed to do on any given access. Consider e.g. a set-associative cache which is four-way associative, divided among four memory banks. When the processor performs a read request, the cache controller knows instantly that if the data if it's in the cache must come from a known address in one of four banks. The cache controller could immediately initiate a read request to all four banks in parallel (without driving output-enable) before it determines which chip, if any, actually holds the data. At least three of the banks will fetch useless data, but fetching data uselessly is harmless (aside from wasting some electricity). What's important is that by the time the controller figures out which bank (if any) holds the data and drives the output-enable, the memories will have already had some time to process the access request.

With a write request, however, the cache controller can't actually start performing a memory operation until it knows which chip is supposed to be written. A useless read is harmless; one can effectively say "never mind" and discard the erroneously-fetched data. A useless write, however, cannot be undone. It is thus important that data not be written until after the controller has figured out where the write is supposed to go.

If one were only performing memory writes, one could perform them as fast as reads by pipelining the process. In cycle n, the controller would figure out where in memory byte n was supposed to go, while byte n-1 was written to the location computed in the previous cycle. Very few situations, however, involve many consecutive memory writes without intervening reads. If the actual write to memory occurs on the cycle after a write request, and the processor wants to perform a read during that cycle, the read will have to wait.

Writes are, in many cases, further delayed by the fact that many systems do not allow bytes of memory to be individually written. A system may have a 64-bit bus between the cache and main memory, and may require that main memory only be written in 64-bit chunks. If code wants to write a single byte, it will be necessary to read 64 bits from RAM, write one byte in the cache, and then at some later time write the 64 bits back to RAM. It may be possible for a cache to perform the write while the data is being fetched from main RAM, and then once the main RAM data is available, only copy the 56 unwritten bits from the main memory bus into the cache, but such logic adds complexity. It is in many cases simpler to simply delay the write until the cache line has been read from RAM.

In multi-processor systems, things are further complicated by the fact that two processors can repeatedly read the same cache line without interference, but if one processor writes a cache line the other processor must not be allowed to use that cache line until either the first processor has written it to main RAM and the second processor has read it, or the first processor has via some other means supplied the data therein to the second processor. A sequence of operations consisting entirely of reads will execute much faster than a sequence of operations consisting of a mixture of reads and writes (bearing in mind that, in many cases, operations that seem to entail just writes will in fact involve both reads and writes). The issue isn't so much that the writes themselves are slower, but rather that a write on one CPU which precedes or follows any operation by another CPU will require both CPUs to perform extra handshaking which would not be necessary if both CPUs were just reading.