Miss Ratio Monotonicity and Convexity (Part 1)

Caches are dynamically managed local memories. Their dynamic behavior can either improve performance or, in some cases, become detrimental and counterproductive. Monotonicity and convexity are two properties are most commonly used to determine whether a cache design is well‑behaved and provides predictable performance. This is the first of a series blog posts on these properties.

Miss Ratio Monotonicity

Informally:

  • If you increase the cache size, the miss ratio never increases.
  • In other words, the miss ratio is a non‑increasing function of cache size.

Formally:
Let mr(c) be the miss ratio for a cache of size c (measured in blocks). Then for c_1 < c_2, we have mr(c_1) \ge mr(c_2).

Not all caches behave this way. If a cache algorithm is not monotonic, increasing cache size could sometimes increase misses, which is counterintuitive and undesirable. This is known as the Belady’s anomaly.

Stack Algorithms and the Inclusion Property

A caching algorithm has the inclusion property (or is a stack algorithm) if:

For any memory address reference sequence and at any time, the set of blocks in a cache of size c is a subset of the set in a cache of size c+1. Cache contents are inclusive across sizes. A block present in the smaller cache is always present in any larger cache. Therefore, the miss ratio of any stack algorithm is guaranteed non-increasing when increasing the cache size.

Mattson et al. Presented the stack property as the sufficient condition for one-pass evaluation of a caching algorithm. The Stack Simulation maintains the content of all cache sizes at each moment using a stack. At each access, the stack distance is the position of the stack where the accessed data is found. The stack distance fully determines whether the data access is a cache hit or miss.

After stack simulation, the hit or miss count of any cache size can be determined from the stack distances without re‑running the trace. Hence, the paper is titled Evaluation techniques for storage hierarchies.

The classic paper in 1970 established formally that the stack property is a sufficient condition for monotonic miss ratios, and the practical solution of one-pass evaluation. This classic work has been extended later in several ways.

LRU caches are the most important and commonly studied. For example, program locality analysis usually assumes LRU caches. The LRU stack distance shows the “closeness” of data reuse and is often abbreviated as the reuse distance. Stack simulation is too slow for large traces. Much faster algorithms have been developed. See a later blog devoted to studies of reuse distance.

Caching techniques that guarantee monotonic miss ratios:

  • Mattson et al. IBM 1970: LRU, OPT, MRU, LFU, and RR (statistically equivalent to RAND)
    • OPT is optimal for all cache sizes, while the technique for a single cache size is called Belady or MIN
  • Gu and Ding, ISMM 2011: LRU-MRU, used for collaborative caching with binary hints, i.e., the evict-me bit.
  • Gu and Ding, ISMM 2012: priority hints, Priority LRU, and non-uniform inclusion.

The term “stack distance” is often used without specifying which type. All stack algorithms above have their stack distance.

Caching techniques that are not guaranteed to have monotonic miss ratios:

  • Belady, CACM 1969: FIFO
  • Mattson et al. IBM 1970: RAND

As explained in Mattson et al., non-monotonic miss ratios may happen if caching priorities depend on the capacity of the cache and differ from one capacity to another, for example, priorities depending on the frequency of reference to pages after their entering the cache. Another example is when priorities depend on total time spent in the cache.

Summary

Miss ratio monotonicity means larger cache → same or lower miss ratio
Inclusion property ensures miss ratio monotonicity and allows for single-pass evaluation, i.e., you can compute miss ratio curve (MRC) for all cache sizes from one trace run.

Programming Language Skills Are AI Skills

Because of AI, everyone needs to know programming languages


Jesen Huang in 2025

Jensen Huang famously said that with modern AI, the programming language becomes human language. Indeed, what used to take days to craft a program, AI tools can now write in seconds. Reports from the industry indicate that many senior engineers have not written a single line of code in months. However, AI coding is directed and managed by humans, and AI-generated code must be approved by humans. Code is cheap, but good code is not. In fact, more AI-generated code often means more human work. A compelling real-world example is the recent Anthropic source code leak, which highlights the risks associated with AI-assisted coding.

Fred Brooks in 1986

In his seminal article that laid the foundation for the field of software engineering, Frederick Brooks identified four essential difficulties of software development. He evaluated the solutions available at the time and concluded that while they addressed accidental difficulties, no solution could resolve the essential ones. He titled his article No Silver Bullet. The introduction begins:

Of all the monsters who fill the nightmares of our folklore, none terrify more than werewolves, because they transform unexpectedly from the familiar into horrors. For these, one seeks bullets of silver that can magically lay them to rest.

I imagine that Anthropic was probably horrified when their AI-generated system leaked over half a million lines of internal source code—a transformation from familiar tool to unexpected nightmare. Brook’s article is the required reading for the first week of the class I have been teaching. The first homework asks students to imagine talking to Jensen Huang and answering his question: “So, what are the essential difficulties of software?”

Programs Require Human Approval

Michael Scott, my colleague and the author of the popular textbook Programming Language Pragmatics, often quotes Donald Knuth: “Programming is the art of telling another human being what one wants the computer to do.” Part of this insight is that a program is a specification for a machine. In this regard, the key attribute is that a program must be precise. We should not—and must not—allow unspecified behavior by a machine. Think about programs that run laser eye surgeries, operate radiation machines, land jetliners, and control the ignition sequence to send Artemis II to the moon. We must write programs that are complete and precise.

AI has an unprecedented ability to automate programming, and its capabilities continue to improve. However, humans must be there to inspect and approve the generated code. The KPMG survey in Q3 2025 found that 63% of 130 executives said they are “putting humans in the loop due to a lack of trust, up from 45% last quarter.” In discussing the survey, one commenter explained that if people do not fully understand what a generated system does and why, they cannot defend it—not to a regulator, not to a client, and not to their leadership.

Precision is the foundation of reasoning. In mathematics, complete precision allows us to derive a result across a hundred steps while still knowing exactly what we are doing—and it enables someone to check every step along the way, a task that machines can now perform. Precision is the foundation of modern science and engineering. We can build complex systems today because we make every component fully precise.

The Conclusion: Everyone Needs to Know Programming Languages

With AI, modern programming may consist of three steps: (1) prompt AI to write code, (2) ensure the code is correct, and (3) explain to another human being what the code does and why it is correct. If Jensen Huang is correct that everyone will program using natural language, then it actually requires that everyone must know programming languages—because step (1) is fraught with risks without steps (2) and (3). Everyone needs to know programming languages enough to understand the code that they write using AI.