The Idea Once Called a Devolution Now Powers Almost Every New Chip

David Patterson is a Turing Award winner and professor of computer science at Berkeley, known for RISC processor architecture, now used by about 99 percent of new chips, and for RAID storage. Lex Fridman learned the inner workings of machines from Patterson and John Hennessy's textbook and opens with a 50-year question. The biggest change, Patterson says, was the microprocessor. Machines that filled several rooms now fit in a phone. They also got about a million times faster, much cheaper, and ubiquitous: more microprocessors on Earth than people, maybe ten to one.

A computer has classically had five pieces. Input and output are what they sound like: speech or typing in, displays out. Memory is an integrated circuit that stores information and gives it back when asked. The processor splits into control, the brain, and the arithmetic unit, the brawn. Think of a body: number-crunching is the muscle, control is the mind. A microprocessor is simply a processor that fits on a microchip, an invention of about 40 years before this conversation.

Most of what the processor does is the same work as a calculator: add, subtract, multiply, divide. The brilliance of the computer is that it performs very trivial operations billions of times per second, and people write software that turns those instructions into tasks better than humans can do. The one extra power is judgment. Conditional branch instructions ask whether a value is less than zero or bigger than another value. Those branches, run billions of times per second, are what give computers their force. Bring back the commercial pioneers of 1950, Patterson later says, and they would look at today's instruction sets and say they do not look that different.

The driving force was Moore's Law, named for Gordon Moore, a Berkeley alumnus. In 1965 he looked at a few years of semiconductors and said the number of transistors would double every year for a decade; in 1975 he revised it to every two years. He did more than plot a line. In that 1965 paper he spelled out implications: computers in cars, computers in something you would buy at the grocery store. If you were in computing and believed him, you had a sketch of the next decade. Exponential cannot last forever, Moore himself said; that it lasted 50 years is the amazing part.

Knowing the prediction did not remove the shock when it hit daily life. Patterson remembers driving across the San Francisco Bay, seeing a URL on a civic-center bulletin board, those www characters that looked like alien writing to lay people. To the nerd it meant the opposite: this stuff was leaking out of the small circle into the real world. Personal-computer ads in magazines produced the same jolt. You expected it. When society actually felt it, it was still shocking.

Computer science copes with that complexity by layers of abstraction: suspend disbelief, pretend you know only this layer, and honor a contract of allowed commands. A modern machine may have ten or 20 such layers, like peeling an onion. A student can start in Python, drop to C, keep going into hardware, and reach the transistor Moore talked about, then climb back to application software. For 20 years software has been open; hardware used to be a black box. Recently there has been an effort to make hardware interfaces open too. Patterson calls it a remarkable time for anyone who wants to see, in great depth, what is really going on inside the machines that power everything around us.

Software talks to hardware in a vocabulary. The words are instructions; the vocabulary is an instruction set: add, subtract, multiply, divide, store into memory, load it back. Those simple instructions go back to commercial machines of 1950. Until about ten years before this interview, the popular sets were proprietary. Intel's x86 family, named from the 8086 onward, sits in the cloud and the PC. ARM, also proprietary, powers phones, iPads, and a lot of Internet of Things devices, and licenses the set for a fee.

In the 1980s, conventional wisdom said the vocabulary should be powerful: polysyllabic words, polynomial divide, sort a list, so software would be easier. Patterson at Berkeley, John Hennessy at Stanford, and people at IBM argued the opposite. With Moore's Law moving so fast, a reduced instruction set computer, RISC, pronounced "risk," would shorten design time. Compilers would translate complex programs into more of those simple instructions. The technical objection was solid. You have to execute more of them. Maybe 50 percent more, or a third more. They ran four times faster. Factors of three or four better.

Believe it or not, this sounded like who cares, and it was violently debated at several conferences. People thought RISC was a devolution that would make software worse. Patterson and Hennessy were assistant professors who believed their ideas. Complex instructions were hard for compilers to emit: you had to find circumstances that exactly fit. Often the compiler would not even use them, while they made the hardware harder to build. Simple instructions matched a world where transistors doubled every two years and time-to-design might matter more than a fat vocabulary.

They had a hard time convincing people until they hit upon a formula. How long a program takes factors into three pieces: how many instructions it executed, times the average clock cycles per instruction, times the clock cycle time. Critics stared at the first factor. The real gap was the second. Complex instructions were implemented with a hardware interpreter that could cost about ten cycles; RISC instructions could take two. A factor of five in cycles, against 25 or 50 percent more instructions, is where the win came from. Once they could divide benchmark time into three factors, people said they got it. Outrageously controversial in 1982; by about 1984, technically a good argument. That move from taste and hunches to numbers became the textbook *Computer Architecture: A Quantitative Approach* at the end of the 1980s. The field started grading on a curve against machines of the same era, on agreed benchmarks.

RISC only closes if programmers will let the compiler handle the details. Before the 1980s, critical software, especially operating systems, was still written in assembly because high-level languages were thought too slow or too big. Unix demonstrated that something as complicated as an OS could be written in C. Once that was true, you could hide the instruction set from the programmer. Translation happens once; every later run enjoys the simpler instructions. Patterson's analogy is monosyllables: you read them faster and say them faster, as long as you do not have to read a lot more of them.

Fridman wonders why there are not more translation steps between human code and the machine. Patterson says it is true and not true. The operating system and the application can both be written in C; applications call the OS; you still get many layers of software. Debuggers, linkers, libraries, even Python interpreters are often still in C or C++, old efficient languages that take one step down to RISC instructions, composed through interfaces into ten layers.

Then the business objection: technically right, commercially insignificant, like a better railroad gauge when the world is already paved in the old one. A bunch of system companies with CISC vocabularies gave up. Intel did not. Its instruction set lived in the PC, and software is distributed as those compiled instructions, not as source. Intel's clever move was to translate complex instructions into essentially RISC operations in hardware, on the fly, at gigahertz. Any good RISC idea, they could use, while staying compatible with a software base shipping on the order of a hundred million PCs a year. CISC won the PC era commercially. RISC ideas ended up inside the chip.

Designing a good instruction set, Patterson says, is an art: a hardware-software compromise so everything in it can be used by compilers, nothing important is missing, and it is still easy to build. It is not that hard to invent a set. Catching on takes luck, timing, or numbers people trust. In 1995 he was asked to predict the microprocessor future. He had seen too many entertaining exaggerations, so he said that by 2020 things would look very familiar. That was the outrageous prediction, given how fast machines were going. The article held up. Hennessy and Patterson later won the ACM Turing Award for RISC and for the textbook, and were surprised that 35 or 40 years on, conventional wisdom for instruction sets still looked like the 1980s work, despite a million times as many transistors.

Berkeley did four RISC research projects in the 1980s; Stanford did a couple. In 2010 the group decided to do a new set, learning from those mistakes. Patterson participated as a mentor; Krste Asanović and others drove it, including graduate students Andrew Waterman. They named it RISC-V, five, to honor the four 1980s projects. The core looks a lot like the simplest 1980s architectures. The big difference is that it is open. The specification is an interface, like a textbook. Implementations are written in hardware languages such as Verilog, analogous to C, and can be posted on the web the way Linux C++ is posted. An open instruction set enables open-source processors.

They licensed it under the Berkeley Software Distribution license so other academics would not be afraid to use it. Around 2014, industry started complaining that the instruction set changed between the fall and spring semester. The team's first reaction was, why do you care what we do with our instruction set? Talking to them, they found a thirst for an open ISA. People had been looking, stumbled on Berkeley's, and thought it looked great. Timing was good and accidental. Universities start things and do not sustain them, so they created a RISC-V Foundation on the Linux Foundation model. The first workshop, around January 2015, had 50 people. The one the previous December had 1,700. Patterson's 25-year bet: RISC-V could become the most popular ISA, because it is pretty good, open, and free, and the Linux logic of modify, improve, and collaborate can replay in hardware.

Whether RISC-V can move the installed base depends on three markets and who controls the software stack. The cloud, Alibaba, Amazon, Google, Microsoft, tens of thousands of servers in perhaps a hundred data centers, is almost 100 percent x86 today; those companies control their stacks and could choose RISC-V. Phones are about 1.5 billion a year against maybe 200 million dwindling PCs, and ARM dominates. Android and Apple both run marketplaces: anyone in the world compiles an app down to binary and ships it. Binary compatibility makes that ISA sticky. Internet of Things, cars, microwaves, embedded devices, does not ship software through stores. Device makers control the stack, licenses are lighter, and you can enhance the instructions. That is where everyone thinks RISC-V breaks through.

ARM itself is RISC: Advanced RISC Machine, a proprietary RISC, now the most popular instruction set in the world, billions of chips a year. The ARM people needed a set in the mid-1980s, read the Berkeley papers, and were heavily influenced. It is more energy efficient than old CISC, in part because x86 still translates complex instructions to RISC-like ops on the fly, which costs silicon area and power. Today's limit is often not how many transistors fit, but how much power you can dissipate, in the cloud as much as in a battery device.

Apple, Qualcomm, and Samsung all use ARM, and iPhones tend to be faster. ARM pioneered a business model: pay for a ready implementation written in something like Verilog, or pay on the order of tens of millions for the right to design your own while still using ARM's ISA. Apple bought the second path, acquired a strong design team, and built more efficient hardware to the same specification. The score is public; the orchestra is not. Patterson's romantic answer to what is beautiful in RISC is that small is beautiful. It is easy in engineering to make things more complicated and surprisingly harder to find a simple, elegant solution.

In RISC-V he especially likes a core of about 40 instructions on which the whole software stack can run, plus optional extensions the compiler will use if they are there. You can teach a computer with 40 instructions instead of thousands. If someone invents biological computing, implement the core and interesting programs will run. Proprietary sets, once they add an instruction, make it required forever, like people gaining weight with age. RISC-V lets you stay as slim as a teenager and add bulk only if you will use it. The deeper surprise remains: line widths narrower than the wavelength of light, and the commands software executes have not changed much in decades. Forty or fifty primitive operations, done very fast, appear sufficient to bring about artificial intelligence.

When Moore's Law was in full effect, the challenge was turning twice as many transistors into a faster computer. In the 1980s and 1990s, performance doubled about every 18 months. People threw away perfectly good machines because a friend with a year-and-a-half-newer box finished work much faster. Patterson now replaces a laptop when the disk or the display breaks. General-purpose processors have gone from doubling every 18 months to something like doubling every 20 years, a few percent a year. Society is still used to computers getting faster on a schedule. Architects now believe the path forward is accelerators that work well only for certain applications.

By coincidence, machine learning won its argument with classical AI in the last decade: infer rules from data instead of writing them top down. The key hardware kernel is matrix multiply, a godsend, because designers know how to make that fast. So general-purpose chips slow down while people add ML accelerators that do matrix multiplies far more efficiently. The danger of domain-specific hardware is that you help 5 percent of the world. Machine learning is used for image recognition, translation, games, even pieces of the software stack such as databases. Domain specific, and because it eats data, unusually broad. Fridman notes the Software 2.0 shift: you program in the space of data and hyperparameters. Patterson agrees the enthusiasm for data-driven programs is independent of the hardware story, and it increases demand for cycles right as Moore's Law is failing.

The timing is fortuitous. Future software, in his picture, still runs large pieces of the stack, user interfaces and the like, on those same basic RISC instructions. The small, computationally intensive piece, not many lines of code but many cycles, comes off onto the accelerator. Hennessy and Patterson titled their Turing lecture "A New Golden Age." They see a decade as exciting as the assistant-professor RISC years, because how software is built and how it runs is being changed again. Acceleration will sit in both compilers and hardware, as in the original RISC debate. Machine learning already uses higher-level domain-specific languages such as TensorFlow and PyTorch.

The fatal flaw for hardware people is to create really great silicon and not bring the compilers. Billions of dollars have gone into machine-learning chip startups. Some have gone belly up because they focused on hardware and skipped the software stack. Two years before this conversation, machine learning did not even have an agreed benchmark suite. Patterson helped start MLPerf. Companies that had not invested in software could not run it well; companies that had, could. Computer architecture has always spent billions in the marketplace to see who wins. It is not a perfect comparison. It sorts things out.

Intel had acquired Nervana a couple of years earlier and did not reveal MLPerf scores, which was suspicious. About a month before the interview, Intel cancelled the Nervana product line and bought Habana, an Israeli accelerator company with good scores, for $2 billion. Intel would ship Habana chips, hardware and software together, as the product line of the future. Peter Mattson at Google helped get MLPerf off the ground by reaching out to competitors. In the RISC days, rival microprocessor teams had attacked one another's numbers until they sat down on SPEC. The market grew instead of freezing. Engineers, Patterson says, can live with not coming in first if the comparison is fair. They hate marketing claims that move sales.

Social media raised the cost of misleading slides: a violent reaction can spread the flaws. Open source, once a dirty word at Microsoft, now shows who is actually committing good code. That culture is not everywhere. Autonomous vehicles, where Fridman works, still run a strong hype machine and less willingness to open and benchmark. Computer vision was not always religious about numbers either. Patterson's student David Martin, working with Jitendra Malik, had graduate students label images and compared algorithms; as far as Patterson knows, that was among the first vision benchmarks, before the line that led to ImageNet. Then the community got religion. ImageNet let the Toronto group win, and the world changed. Entering benchmarks is a scary step: you have to be good to participate, instead of believing you are the best. Patterson does not understand how a field without benchmarks figures out that it is making progress. Ten universities and 50 companies were already in MLPerf, the de facto way to measure ML performance, and it had not existed two years earlier.

Patterson had hoped to retire before he had to teach quantum computing. Every talk on Moore slowing and domain-specific accelerators draws the same question, because it is in the news. Two frank national reports, one from the National Academy of Engineering and one from a computing consortium, said error-corrected quantum computing was a decade away. He thinks of nuclear fusion: exciting, fantastic if it works, not around the corner. He would put a commercially relevant machine in the 20-to-30-year range, big science, microkelvin, wrecked if a truck vibrates the building, in a data center, never a quantum phone. It will be a set of applications, not general-purpose computation. He admires 30-year projects and does not think he is good enough to see the problem that far out. Ten years is hard enough. Do not bet this decade's missing cycles on it.

Jim Keller has quoted Patterson as wrong and argued Moore's Law is not dead. Patterson calls that marketing. Gordon Moore made a quantitative prediction: double the transistors every two years. Check DRAM from six years ago, three two-year periods, for eight times as many transistors. Check Intel microprocessors the same way. The answer in both cases is no. Because the industry spent capital to make the law come true, many people treat Moore's Law and "semiconductors are still improving" as the same sentence. Say the law no longer holds, and they hear that technology has frozen. Keller is fighting the impression that chips stopped in 2019. Patterson never said that. He said the doubling stopped.

To ease the perception problem he now says Moore's Law is slowing down, which is another way of saying the two-year doubling does not hold. As an educator he dislikes everyone getting their own facts. Carver Mead put Moore's plots on a log scale and got a straight line; that is the definition. Intel, before Keller joined, tried rewriting it as transistor cost halving every two years. That is not what Moore said, and people in industry have told Patterson that recent, more complicated processes raised the actual cost of a transistor. The beauty of the original was E=mc² simplicity. Reinterpretation is revisionist history. A lot of computer science, he warns, still does not know the era has changed at the bottom of the stack. If next year's cloud server is only a little faster, and your software roadmap still assumes free speed, the assumption is already false. Clock rates are more or less what they were five years ago. People buy new phones for cameras, which is domain-specific hardware, not a twice-as-fast ARM core.

In 1988 Patterson, colleague Randy Katz, and graduate student Garth Gibson wrote "A Case for Redundant Arrays of Inexpensive Disks." They had just finished the fourth-generation RISC project; processors were faster and storage was the bottleneck. Katz had an early Macintosh. Work still meant shuffling floppy disks. Then Apple put a book-sized hard drive next to the Mac, while mainframe disks were washing-machine sized. Katz asked what you could do with the small new things. The idea was to put many PC disks together in place of one washing machine: 40 little drives, cheaper because of PC volumes, potentially faster because they could work in parallel.

They sent a draft to a former Berkeley student at IBM. Fine, the reply said, but what about reliability? Forty PC-quality disks versus IBM's machines, which then dominated storage. The calculation was ugly: instead of breaking about once a year, the array would break every two weeks. So they added redundancy. Extra copies, so if one disk failed you would not lose everything. With a modest number of extra disks the array could be faster, cheaper, and more reliable than the washing machine, because it could survive a couple of failures while a single mainframe-disk failure knocked the whole thing out. The R in RAID is that extra.

Did they foresee it taking over? Patterson is an optimist, but the argument was a trend, not a vibe. Disks had been shrinking, eight inches, five, three, and volume followed the small end because that is where PCs were. Technological forces were on their side. Whether the business side, with IBM pushing large drives, would convert was unclear. As academics they believed technology should win, and it did. The later shift is from spinning magnetic disks, 60 revolutions per second, a needle on something like vinyl, to semiconductor flash. Phones, most laptops, and embedded devices use flash; the cloud still mixes in disks because they remain more economical at scale. RAID ideas still apply. Computation errors are a hassle; you rerun the program. Lost storage makes people go nuts. Reliability for storage has always mattered more than for compute, which is why redundancy stays popular even as flash gets more reliable. Skip backup and you are taking a great risk.

Patterson taught at Berkeley for 40 years and does not buy the campus myth that a terrible lecturer must be a great researcher, or why else would he be there. At his retirement party he looked at a photograph of five people in the department who had won the campus Distinguished Teaching Award, a high honor. All five were in the National Academy of Engineering. Three of them, Manuel Blum, Richard Karp, and Patterson, held Turing Awards. Randy Katz and John Ousterhout were in the same frame. Teaching and research, in his experience, are highly correlated. People who are successful tend to be successful at more than one thing.

Richard Feynman, invited to the Institute for Advanced Study, thought a university without teaching was a terrible idea. Standing in a classroom, explaining, and getting asked "why is that true?" forces you to stop and think. Bright students asking hard questions are synergistic with research. Patterson's favorite thing to teach is not a particular concept. It is watching the lights turn on when someone suddenly understands something important and difficult. A lot of people who think they dislike teaching give one guest lecture and get hooked on that moment.

He also wrestled, at UCLA and at El Camino Community College, which won a California state championship and once beat UCLA with a roster of freshmen and sophomores. He had been admitted to UCLA and went to the community college first; his mother said it was the girlfriend and because he thought the wrestling team was really good. Born December 1, he was almost always the youngest and smallest in class, late to mature, taking nerdy courses and wrestling anyway. The sport gave him physical self-confidence that later translated into research confidence. In his seventies he still will not stand by if something bad is happening in the street, and he treats false claims in the field the same way. His coaches believed an individual sport still wins if the team bonds. He picked up those skills and is often described as someone who can pull large groups of faculty and graduate students toward a common goal. Contact sports, he thinks, also made him willing to enjoy the RISC-era arguments instead of shying away.

If you put metrics on a life well lived, Patterson starts with a line from Randy Katz: when it is time to sign off, the measure is not the zeros in the bank account, it is the inches in the *New York Times* obituary. The cliché is that people do not die wishing they had spent more time in the office. Reflecting on his career, he can name a half dozen or a dozen things he is proud of, and a lot of them are not papers. Family: more than 50 years married, kids, grandkids. Education, books and courses. Help for underrepresented groups that was actually effective. He has hundreds of papers; RISC and RAID he is proud of, and many others, looking back, are not what you will be remembered for. Chasing dollars or paper count is probably not the afterward.

Before he showed up at Berkeley he read a book of interviews across walks of life. The people who felt good about what they did were the people who had affected other people, not the ones chasing transitory things. He came into the job assuming it would be relationships over time, not the papers, that he would value. That assessment was correct. The people you work with, influence, and help are what you feel good about at the end of a career.

When you tell people you have been married 50 years, they want to know how. He offers nine magic words: I was wrong, you were right, I love you. You have to say all nine. You cannot stop at "I was wrong, you were right, you jerk." Freely acknowledging the mistake, that the other person was right, and that you love them, gets over a lot of bumps in the road. The man whose instruction-set ideas sit under most new chips leaves that as the methodology that actually scales.