---
title: "Ertl's 'memory wall fallacy' argues the wall is application-dependent, not a law of physics"
type: "claim"
status: "seedling"
audit_status: "capture-verified | 2026-07-12 cross-model audit (claude-fable-5): page re-fetched — quote confirmed verbatim ('Cache miss rates in general are very dependent on the application, and this holds even more for compulsory misses'), fixed-miss-probability critique and cache-blocking example both confirmed present. CORRECTED: source_date '2001-01-01' is not visible anywhere on the page (undated); qualifier added rather than deleting the capture's value"
writer_model: "claude-opus-4-8"
source_url: "https://www.complang.tuwien.ac.at/anton/memory-wall.html"
source_title: "The Memory Wall Fallacy"
source_author: "M. Anton Ertl (TU Wien)"
source_date: "2001-01-01 (per capture; page itself carries no date — not confirmable at 2026-07-12 audit re-fetch)"
source_quote: "cache miss rates in general are very dependent on the application"
source_tier: 2
provenance: "Promotion from 10-inbox/raw/2026-07-09-hop-memory-wall-pim-genomics.md, 2026-07-11"
origin: "hop-batch"
derived_from: ["10-inbox/raw/2026-07-09-hop-memory-wall-pim-genomics.md"]
date_created: "2026-07-11T00:00:00.000Z"
tags: ["computer-architecture","memory-bandwidth","memory-wall","caching","contrarian","hardware"]
related_notes: ["claim-memory-wall-named-1994-wulf-mckee","claim-processing-in-memory-beats-memory-wall-dna-alignment","claim-llm-inference-prefill-decode"]
drafted_in: ["2026-07-13-the-heart-was-always-a-pump","the-heart-was-always-a-pump"]
---


Computer architect **M. Anton Ertl** (TU Wien) argues, in a page titled "The Memory Wall Fallacy," that the original [[claim-memory-wall-named-1994-wulf-mckee|memory wall]] argument overstates its own inevitability. The 1994 projection that memory latency would eventually dominate all program execution rests, on his reading, on an assumption of a **fixed cache miss rate** — and that assumption does not hold in general: "cache miss rates in general are very dependent on the application."

The consequence is that "the memory wall" is not a universal law of hardware physics but a property of specific workloads. Programs with poor locality (large, irregular, streaming access patterns) do hit the wall; programs that are cache-friendly, or that can be restructured through techniques like **cache-blocking**, keep scaling with processor speed and never hit it. The wall is real for some workloads and absent for others, so "memory-bound" is a claim about an *application*, not about all computing.

This tempers the framing of the memory wall as destiny. It also sharpens the reading of the domains where the wall genuinely bites: [[claim-llm-inference-prefill-decode|transformer decode]] and [[claim-processing-in-memory-beats-memory-wall-dna-alignment|DNA sequence alignment]] are both cases of low-locality, memory-streaming workloads — precisely the class Ertl concedes *does* hit the wall. His critique does not deny those cases; it denies the generalization from them to all computation. The hardware response of putting compute inside memory, and the software response of restructuring for locality, are thus two answers to a bottleneck whose scope is workload-specific.

> [!note] Seek's commentary:
> Worth keeping as the built-in contrarian check on any memory-wall claim: it stops "the memory wall" from becoming a lazy universal explanation. Notably, it does not weaken the genomics/LLM cases — both are exactly the low-locality workloads Ertl agrees are wall-bound — but it forces those claims to be stated as *workload-specific*, which is more honest. Single-source (Ertl's own venue); a strong Tier-2 primary for his own argument, but still one voice.
> — Seek