David Patterson on CPUs, GPUs, TPUs, and 50 Years in Computing

There's a particular kind of clarity that comes from someone who was in the room when the arguments were happening — not recounting history from a textbook, but from memory. David Patterson, Turing Award winner and Berkeley professor, has that clarity in abundance. In a wide-ranging interview with Ryan Peterman, he walked through five decades of computer architecture debates with the ease of someone who helped settle them — and the candor of someone who knows which ones are still being misread.

The conversation is worth your time even if you've never thought about what an instruction set is. Maybe especially then.

The RISC vs. CISC debate was never really about instructions

The 1980s holy war between RISC (Reduced Instruction Set Computing) and CISC (Complex Instruction Set Computing) sounds, on paper, like a dry academic dispute. It wasn't. Patterson describes it as a fight conducted almost entirely in vibes — because the data didn't exist yet.

"Computer architecture in the 1970s and even 1980s — a lot of it was people designed this by using their intuition or using their gut," he said. "It was more like a philosophical debate — like how many angels on the head of a pin."

The core tension: CISC proponents (building on IBM mainframes and minicomputer traditions) believed that more sophisticated, complex instructions would raise the abstraction level and make life easier for compilers. Patterson and his Stanford collaborator John Hennessy pushed back. They thought simpler instructions — "monosyllabic words," as Patterson puts it — could actually run faster despite needing more of them to complete the same task.

When the numbers finally came in, the RISC camp's intuition held: you needed about 30–40% more simple instructions, but you could execute them four or five times faster. Net result: a 3–4x performance advantage.

The compiler angle is the part that doesn't get enough attention. One of CISC's central promises was that sophisticated instructions would make compilers' jobs easier — smaller gap between high-level code and machine code. But when researchers actually looked at what compilers were doing with those fancy instructions, the answer was: mostly ignoring them. Architects would design an elaborate instruction for, say, procedure entry — and compiler writers would say "we don't need that." You were paying the overhead of a microcode interpreter (essentially an extra translation layer inside the chip) for instructions the software never used. "A nonsensical situation," Patterson calls it, with the restraint of someone who lived through the arguments.

So did RISC win? Depends when you stop the tape

Here's where Patterson gets a little spicy. He mentions reading a recent online take claiming CISC won the architecture wars — a position he calls "pretty myopic." The x86 architecture (CISC) did dominate the PC era, but only because of a massive distribution lock-in: software shipped as x86 binaries, so switching instruction sets meant breaking the entire software ecosystem. Intel's commercial genius, not architectural superiority.

Meanwhile, in England, a company called Acorn built a chip influenced directly by Patterson's Berkeley papers — the Acorn RISC Machine, later renamed ARM (Advanced RISC Machine) when Apple came calling for a chip to power the Newton PDA. The Newton flopped. ARM survived. Nokia picked it up for early mobile phones. And from there, the trajectory is pretty well-known: 350 billion ARM processors shipped, 99% of mobile devices running RISC architecture, Apple moving its Mac lineup off x86, and cloud providers at Amazon, Microsoft, and Google all developing their own ARM chips.

"Right now I'd say the x86 architecture market is shrinking while the RISC architecture market is growing leaps and bounds," Patterson said.

The honest read here isn't that one side won — it's that the winning conditions shifted. x86/CISC won the binary distribution era. RISC won the energy efficiency era that followed. And those two eras don't overlap cleanly.

The GPU-to-TPU handoff, and what it reveals about specialization

Patterson's account of how GPUs became AI's default hardware is a useful origin story. GPUs started as graphics chips — cheap, fast at floating-point math, massively parallel. Nvidia CEO Jensen Huang saw potential beyond games and funded CUDA in 2006, a C-like programming language that made it possible to use GPUs for general computation. His original target market was teenagers and Department of Energy labs. Machine learning was not in the pitch deck.

Then 2012 happened. The AlexNet paper — a neural network entry in an image recognition competition — crushed the field. Its creator had taken a CUDA course at the University of Toronto and ran his model on a GPU. He was the only neural network entrant. He won by a distance. "Within a few years everybody switched over — and not only were they doing neural networks, but they were using GPUs."

Google's response was the TPU (Tensor Processing Unit), announced publicly in 2016. Rather than adapting graphics hardware for AI, Google started from scratch. The heart of neural networks is matrix multiplication, so they built a chip around a giant matrix multiply unit and stripped out everything else — no hardware caches (they could schedule memory access in software), a radically different floating-point format (bfloat16, which prioritizes range over precision, the opposite of scientific computing norms), and no graphics legacy to maintain.

Patterson's numbers on the first TPU's impact: 30x better at inference than the contemporary GPU, 80x better than CPU. "It just shook everybody up. Intel started buying companies. Nvidia started modifying designs for machine learning."

The underlying logic is a story about specialization under constraint. If Moore's Law and Dennard Scaling (the companion law that kept chips from overheating as transistors multiplied) had kept working, none of this domain-specific hardware would have been necessary. General-purpose CPUs would've kept getting faster, and everyone would've been fine. But Dennard Scaling collapsed around 2005, Moore's Law started visibly slowing around 2015, and architects had to find performance somewhere else. The answer was to stop trying to do everything and get really good at one thing.

On Moore's Law: Patterson is blunt about the data

Patterson has limited patience for the "Moore's Law isn't dead" crowd — a position notably held by chip designer Jim Keller. His response is characteristically direct: just look at the transistor counts. Moore's Law says transistors double every one to two years. They're not. The argument that technology is still improving is true but separate — it's not improving at the rate Moore projected. Logic gates are still getting better; SRAM (static RAM, a critical chip component) is barely improving at all. The industry has shifted to chiplets and exotic packaging to squeeze out headline transistor numbers that paper over what's happening inside individual dies.

"If you look at what's inside the chip, you know that has tapered off," he said. "I think there's an emotional side of it — if you've been sustaining Moore's Law for decades and somebody says it's over, it's like... my career is..."

He trails off, but the point is clear: there's a sociology to this debate that isn't purely technical.

What's replaced Moore's Law as the organizing principle isn't one clean law — it's a portfolio of bets. Narrower floating-point formats (down to 8-bit and 4-bit). Bigger matrix multiply units. Advanced packaging. Each piece of the technology stack improving at its own rate, requiring architects to track them individually and assemble their bets from the pieces that are actually moving.

The Nvidia moat is software, not silicon

One of the most practically useful parts of the conversation is Patterson's breakdown of why ML Perf benchmarks — designed to create neutral hardware comparisons — don't function as neutrally as intended. The benchmark measures architecture plus libraries, and Nvidia's libraries are a significant independent advantage. When Nvidia ships a new chip generation, it ships tuned libraries alongside it. Startups lack the engineering headcount to match that. So when Nvidia scores well on ML Perf, it's scoring the whole stack, not just the hardware.

"It's not a neutral evaluation," Patterson said plainly. "It's the architecture plus the libraries that go with it."

This is what people mean by the "CUDA moat" — it's not just that CUDA is the programming language, it's that Nvidia has built years of optimized libraries on top of it. Google has its own libraries for TPUs but they've historically been internal-only. Startups are essentially competing against a company that ships both the track and the running shoes.

The half-century stuff

The interview shifts gears into Patterson's career philosophy, and it doesn't feel like a pivot — it feels like the same sensibility applied to a different domain. His "Life Lessons from the First Half-Century of My Career" piece at the ACM gets referenced throughout. The advice is less inspirational poster and more pattern recognition from long observation.

On focus: "It's not how many things you start, it's how many things you finish." He describes this realization hitting him like a thunderclap — he'd been running many things in parallel, spread thin. After that moment, he committed to one main thing at a time. His textbook with Hennessy. His department chairship. The RISC research. He cites Hennessy's observation that you're remembered for five or six things in a career, not the hundreds of smaller efforts.

On courage: Patterson connects it directly to his wrestling background — the physical confidence translated to an intellectual willingness to challenge weak arguments regardless of who's making them. He's clear-eyed about the cost: "Friends come and go but enemies accumulate." He's not recommending recklessness. He's recommending precision — stand up when the argument actually matters, and be aware that making enemies is a permanent condition.

The moment that lands hardest is his one genuine regret. As chair of SIGARCH (the computer architecture community's main professional body) in the 1990s, he was unaware that men at the annual conference were harassing young women attendees. He wishes someone had told him. He believes he would've stopped it. Whether that counterfactual is accurate is unknowable — but the fact that a man with decades of institutional authority frames his biggest professional regret around what he failed to protect rather than what he failed to achieve is worth sitting with.

Fifty years of computers, and that's the thing he'd go back and fix first.

---

— Yuki Okonkwo, AI & ML Correspondent, Buzzrag