LockerGnomeTech news and nostalgia for today's technology professionals
Subscribe

Search

Retrotech-history

Maurice Wilkes’s two-page cache paper already worried about copying the wrong memory

The Cambridge researcher’s 1965 proposal reads surprisingly well beside today’s performance claims, including the warning that speed depends on what a program actually reuses.

Chris reading a two-page paper next to a tiny fast box, abacus
Illustration: LockerGnome

Maurice Wilkes put a very familiar performance problem into two pages in 1965. Copying a whole program into fast memory could waste time when the program would touch only a small part of it. The expensive memory needed better judgment about what to keep close.

His paper, “Slave Memories and Dynamic Storage Allocation,” used the period’s terminology for the smaller store. It was meant to accumulate words brought from main memory, keeping them available for another access. The supermarket comparison practically writes itself: keeping the milk near the front saves a trip only if somebody keeps asking for milk.

The important qualifier is reuse. Wilkes wrote, “The actual gain depends on the statistics of the particular situation.” That warning deserves a chair beside every impressive speedup slide. A smaller, faster store cannot help much when the next request keeps asking for something it does not contain.

Cambridge’s account of Wilkes’s career identifies the 1965 publication as his first paper on cache memories. The original gives a concrete larger-memory example, with roughly 32K words in the working store and a million words behind it. Capacity and access time get discussed together; simply adding more of something never gets a free pass.

A cache has two jobs that can pull in different directions. It should make repeated work cheaper, and it must still return the right result. Keeping a convenient old copy is easy. Knowing whether that copy is still the one the application needs takes actual bookkeeping, the sort of detail that disappears when the sales pitch reaches “faster.”

For a person evaluating a modern system, the paper offers a useful way to challenge a benchmark. What was already nearby before the timer started? What changed between requests? Was the measurement allowed to include fetching the missing data? Those questions do not require pretending a 1965 memory design is identical to a web cache. They require keeping the work being measured visible.

The acknowledgment also makes the origin less convenient for a trivia card. Wilkes thanked Cambridge colleagues and recorded that G. Scarrot had suggested the earlier memory idea to them. The document itself points outward. A sentence declaring that one person invented the entire modern hierarchy would erase the evidence sitting on its final page.

The same caution belongs with any prediction about faster machines. More local storage could improve repeated work while leaving an unpredictable workload waiting on the slower store. The unresolved part is what the next request asks for. That is something a benchmark can measure, provided it has resisted the temptation to pick only friendly requests.

Cache only goes so far.

More Retro

Every Retro story →